- 1 名前：デフォルトの名無しさん mailto:sage [2020/09/02(水) 12:18:30 ID:XN0SxNMq.net]
- ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆関連サイト
Pro Git - Table of Contents
git-scm.com/book/ja
Git入門
www8.atwiki.jp/git_jp/
◆前スレ
Git 15
mevius.2ch.net/test/read.cgi/tech/1486239735/
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
-
VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured
- 577 名前：デフォルトの名無しさん mailto:sage [2021/02/27(土) 21:05:27.89 ID:GbyYV3Ad.net]
- >>559
コミットしたほうがいいよ
このリポジトリをクローンしたひとが最初に読むことを書いとくといいよ
- 578 名前：デフォルトの名無しさん mailto:sage [2021/02/27(土) 22:38:58.24 ID:OecrqISI.net]
- そのリポジトリはGitHubとかにホスティングするの？
- 579 名前：デフォルトの名無しさん mailto:sage [2021/02/27(土) 22:42:38.12 ID:2Z5Xe6zl.net]
- >>564
GitHub等のホスティングサービスでもいいしオンプレにgitサーバー建ててもいいしお好きにどうぞ
- 580 名前：554 mailto:sage [2021/02/27(土) 23:13:08.51 ID:5c6DxbzC.net]
- >>563
>>564
ありがとうございます
>>563
分かりました
>>564
はい、GitHubのリモートリポジトリにコードを挙げようと思っています
コードも練習用で秘匿性はありません
- 581 名前：デフォルトの名無しさん mailto:sage [2021/03/03(水) 15:03:41.70 ID:z/MOpsDf.net]
- git svn使っててSVNサーバーが移動すると
対処法(svn switch --relocate相当)が微妙でちょっとドキドキしたわ
いろいろやり方あんのな
テスト用のリポジトリ作っていじり倒していると
半日ぐらいすぐに吹っ飛ぶのでヤバい
- 582 名前：デフォルトの名無しさん [2021/03/03(水) 20:49:37.84 ID:sncyHuZV.net]
- gitの使い方について質問させて下さい
なんちゃってgit-flowっぽい運用をしています（開発中のブランチはdevelop）
ウォーターフォール型？のプロジェクトを複数人で開発しているんですが、担当範囲の
単体試験が終わるまで一切pushしないメンバーがいます。
そのメンバーいわく「UTが終わってない時点で正常に動く保証が無いのだから、そんな
コードはdevelopにpushしない」との事なんですが、これが一般的な考え方なんでしょうか？
結果、ものすごい量の修正がなされたソースが開発フェーズの最後にどかんとpushされて
プルリクがくるのでとてもレビューしきれないし、確実にコンフリクトも起きます
開発の最中って、各人のコードをどのくらいの頻度でプロジェクト共有のdevelopに
取り込むのが普通なんでしょうか？
- 583 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 01:24:39.84 ID:jld/rbVo.net]
- >>568
コミュニケーションとfeatureの規模の問題でないだろうか。
・コミュニケーション：
一人はfeatureが固まるまではdevelopにマージしないのが普通と考えている。もう一人はdevelopが壊れてもいいから（そういうことでしょ？）マージしてほしい。
これは会話をしたり規約を決めて解決する問題だと思うね。
表面だけ見れば、個人的にはdevelopは壊したくないので同僚に一票。
理由としてはfeatureは担当者の私物に近いが、developは共有だ。参照されるライブラリを書いているような状況では、利用する機能を壊しかねない。他人に迷惑をかけるコードをマージしたくない考えには賛同できる。
文字通り（devへのマージでなくてfeatのまま）pushしてくれないということだとしたら、その必要性を伝えてみたらどうかな。
- 584 名前：あなたが進捗を把握するためにpushしてほしいのか、レビューを先に細かくしておきたいからしてほしいのかは知らないけど。
あなたが熱心に説得しても、もし同僚が聞き入れないのであれば、それは柔軟性や協調性の問題であるから、上司に相談してみるといいかもね。（性格がPJに合わなかっただけなので、個人批判はしないこと） [] - [ここ壊れてます]
- 585 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 01:25:15.34 ID:jld/rbVo.net]
- >>569
・featの規模の問題：
頻度はわからないが、どかんとコードがpushされるというのは、featに切り出した問題が大きすぎるのではないか？
開発方法が詳しくわからないが、アジャイル開発でやるようなプランニングポーカーでもやってみたらどう？
あなたが思っているよりも複雑で大きな機能なのかも。
レビューが大変なら、簡単になるようなサイズまで切り出してみたらいいんじゃないかな。
・あとは考えたくないけど、能力不足：
担当者か、レビュアーの能力が足りていないために、苦労している。
担当者目線では難しい機能で、時間がかかってしまい、フェーズの終盤までかかってしまう。
レビュアー目線では、担当者のコードを読み解くことができず、平均以上に難しさを感じている。
- 586 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 01:26:06.16 ID:jld/rbVo.net]
- >>570
・最後に：
プルリクのコンフリクトは、feat担当者にマージできるように作らせるのがオススメ。（「develを壊さないようにfeatを作ってください」）
プルリク出す前に再度develからfeatにマージさせるようにすれば解決できる。（これ自体はgit flow標準ではない）
また、一定以上のコンフリクトが発生するものはacceptしないなど。
平和的に解決するように頑張ってください。
- 587 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 01:48:02.33 ID:jld/rbVo.net]
- もう一点だけ補足。
説教になって申し訳ないです。
業界の普通を知ることは当然大事で、普通のことを普通にできるようにするのは大切なことなのですが、実際はチームの数だけやり方があります。
なので普通に合わせるよりも、うまく行かない現状がうまく行くような方法を適宜考えていくのが最もうまく行く方法だと考えます。
Gitと関係ないことを連々と失礼しました。
- 588 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 02:34:30.70 ID:pxppk7Pi.net]
- >>571
同感
コンフリクトが多くて実質マージ不能なプルリクは却下でいいだろ
- 589 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 09:35:56.38 ID:OhT1wEZp.net]
- ここは開発者に優しいスレですね
- 590 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 15:56:47.53 ID:Ep7EXP13.net]
- >>568
なんとなく問題は、本流以外だと動作確認しづらい何かがあるんじゃないかという気がする。
つまりgit以外の問題なんじゃないかと。
- 591 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 17:31:50.50 ID:D7YR+KaN.net]
- Git v2.31.0-rc1
- 592 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 18:38:18.06 ID:D7YR+KaN.net]
- >>576
masterからmainへの名称変更は前回のv2.30で一段落付いて、
今回は普通のリリースになりそうです。
- 593 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 19:13:26.59 ID:k8593Rs+.net]
- >>571
>>573
ローカルで最新devをマージしてコンフリクトを解決するのがgit flow標準になっていないのは、何か理由あるのかしらん？
後のリクエストに修正義務を課すのはわかりやすいルールだと思うけど、問題あるのかな？
- 594 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 21:37:38.82 ID:miLZRrxO.net]
- 標準にしてないだけじゃないかな
プルリクとは限らないから、自分でマージしたっていいし
- 595 名前：デフォルトの名無しさん mailto:sage [2021/03/04(木) 21:44:50.30 ID:miLZRrxO.net]
- 自分でっいうか
devで自分でって言いたかった。
- 596 名前：デフォルトの名無しさん mailto:sage [2021/03/08(月) 01:16:16.76 ID:gjklcTJPY]
- 無料&かんたん！ ロゴ作成ツールおすすめ12選【商用OKも】
https://mag.app-liv.jp/archive/119964/
デザイナー泣かせ？ ロゴ自動生成サービス「Hatchfulロゴメーカー」がすごい
https://forbesjapan.com/articles/detail/40021
無料で使える！簡単にロゴを作成できるおすすめサイト8選
https://liskul.com/logomaker-29137
無料素材：ヴィンテージ感がおしゃれ！デザインソフトのツールアイコン49個セット
switch-box.net/free-resources-vintage-design-icons.html
無料素材：魔法陣の文様が描けるユニークな英語フリーフォント「MagicRing」
switch-box.net/free-font-magic-ring.html
マップ作成ツール2種：InkarnateとFlowScape
chanagame.hateblo.jp/entry/2019/09/14/081333
ファンタジー世界地図を簡単に作れる「Inkarnate Worlds」をゲーム制作に活用しよう
www.moguragames.com/entry/inkarnate-worlds-indiegame-dev/
ファンタジー世界の地図をマウス操作のみで作る（Inkarnate Worlds）
https://note.com/freudnishi/n/nb30c3ce75950
架空のファンタジー世界地図の作成を補助してくれる「Wonderdraft」発売中。TRPGファンにも愛用されているツール
https://automaton-media.com/articles/newsjp/20190430-91035/
- 597 名前：デフォルトの名無しさん mailto:sage [2021/03/10(水) 09:01:05.42 ID:aXqmchiP.net]
- Git v2.30.2
- 598 名前：デフォルトの名無しさん mailto:sage [2021/03/10(水) 14:21:53.36 ID:LF8mKXsJ.net]
- 「Git」v2.15以降に任意コード実行の脆弱性 〜v2.30.2へのアップデートを
https://forest.watch.impress.co.jp/docs/news/1311031.html
「Git LFS」が“git clone”を実行する際使われる遅延チェックアウトの仕組みに脆弱性があり、細工が施されたリポジトリから任意のコードを実行できてしまう問題(CVE-2021-21300)が修正されている。
この脆弱性は「Git」v2.15以降に影響し、最新版へ更新することで解決できる。何らかの理由でアップデートが難しい場合は、以下の緩和策が推奨されている。
・“git config --global core.symlinks false”を実行して「Git」のシンボリックリンク対応を無効にする
・プロセスフィルタのサポートを無効にする
・信頼されていないリポジトリのクローンを避ける
- 599 名前：デフォルトの名無しさん mailto:sage [2021/03/16(火) 07:48:49.09 ID:2J50stIm.net]
- Git v2.31.0
- 600 名前：デフォルトの名無しさん [2021/03/17(水) 19:54:37.33 ID:kfZVZJH6.net]
- ゴミ
オープンソースを売り渡したゴミ
- 601 名前：デフォルトの名無しさん mailto:sage [2021/03/17(水) 20:20:57.14 ID:wI0GxMfw.net]
- >>585
もしかして、gitとgithubを混同してる？
- 602 名前：デフォルトの名無しさん [2021/03/17(水) 23:37:10.54 ID:YH/YYkmR.net]
- GitとGitHubを混同するのは、GitHubを使ったことのない初心者だからね。
書籍での説明もPCにGit、インターネット上にGitHubがある使い方を前提とした説明ばかりだから、一緒くたになるんだと思う。
- 603 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 01:49:39.04 ID:NJYdTHCo.net]
- そんな書籍は捨ててしまえ
- 604 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 02:31:24.73 ID:SQWqa2FJ.net]
- 知識レベルとしてはアスカの言うギフハブ=悪の組織と変わらんなw
- 605 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 09:45:31.10 ID:YVfbLseY.net]
- error: 7332 bytes of body are still expected MiB | 14.00 KiB/s
fetch-pack: unexpected disconnect while read
- 606 名前：ing sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
ゴミ
DL数稼ぎみたいなクズ [] - [ここ壊れてます]
- 607 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 09:46:18.63 ID:YVfbLseY.net]
- 共犯だから一緒くたにしなければならないんだよ
- 608 名前：デフォルトの名無しさん [2021/03/18(木) 09:51:54.96 ID:FvPGn+3+.net]
- gitのアカウント持ってるかって聞かれたことある？
- 609 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 12:24:31.07 ID:Ao1KNBsY.net]
- あるよ。もってるならそのアカウントを会社で使うし
持ってない人や会社とは別にしたい人は新しく作る
今はしらんけど無料アカウントは複数持てないので
どちらかを有料アカウントにする要津がある
- 610 名前：デフォルトの名無しさん [2021/03/18(木) 13:09:23.00 ID:7fQvPjcg.net]
- それはGitHubのアカウントだろ
- 611 名前：デフォルトの名無しさん [2021/03/18(木) 14:29:23.28 ID:QYSZQq5N.net]
- gitにアカウントなんてあるんだ
はつみみだわ
- 612 名前：デフォルトの名無しさん [2021/03/18(木) 15:06:05.43 ID:HfXxQmPX.net]
- git + sshd 最強
- 613 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 15:42:08.34 ID:dpSVUSL0.net]
- ヘミ猫信者かな
- 614 名前：デフォルトの名無しさん [2021/03/18(木) 16:07:02.18 ID:FvPGn+3+.net]
- gitのアカウント持ってるか聞かれて、bitbucketとか自前のホスティングサービスみたいなのを答えたらどうなるの？
こいつ空気読めねーなみたいな感じになるの？
- 615 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 22:01:51.13 ID:/EsE4cAE.net]
- そういうときに本当に空気読めないのは「えっ？gitにアカウントなんてないですよ」って言うやつじゃないか？
- 616 名前：デフォルトの名無しさん mailto:sage [2021/03/18(木) 22:31:26.93 ID:Rnt4uQ59.net]
- gitのアカウントも知らないんですかと馬鹿にしたように言われて
噛み合わないまま
- 617 名前：デフォルトの名無しさん [2021/03/18(木) 23:02:30.10 ID:7fQvPjcg.net]
- Gitのアカウントもあるからな。
Gitのローカルユーザー名が、OSのユーザー名だと知らないのもイタいな。
- 618 名前：デフォルトの名無しさん mailto:sage [2021/03/19(金) 01:11:18.57 ID:IHBvfpin.net]
- Gitも使えないゴミと仕事するのは疲れる
- 619 名前：デフォルトの名無しさん [2021/03/19(金) 01:29:38.99 ID:hh9Kt8XT.net]
- WebデザイナーがGitHubのGitしか、説明しないからおかしくなる。
- 620 名前：デフォルトの名無しさん mailto:sage [2021/03/19(金) 06:12:35.81 ID:ixU77Wuk.net]
- どこにでも入り込んでくる
まるで覗き趣味の変態みたいだ
- 621 名前：デフォルトの名無しさん mailto:sage [2021/03/19(金) 06:28:35.38 ID:sCdGWAs/.net]
- >>604
それはギフハブだろ
- 622 名前：デフォルトの名無しさん mailto:sage [2021/03/19(金) 07:42:24.61 ID:NI5sRH9+.net]
- git も共犯
- 623 名前：デフォルトの名無しさん mailto:sage [2021/03/19(金) 09:31:16.08 ID:oP3tYoyl.net]
- 飛鳥はこのことを予言していたのか
- 624 名前：デフォルトの名無しさん [2021/03/19(金) 10:37:37.34 ID:YNMGX1sb.net]
- ギフハブの正体
岐阜への移住応援サイト GIFU×HUB
https://docodoor.co.jp/web/gifuhub/
岐阜県への移住を応援する悪の秘密結社だった（？）
- 625 名前：デフォルトの名無しさん [2021/03/19(金) 10:50:25.30 ID:MMZWnUW+.net]
- おっかねーな
- 626 名前：デフォルトの名無しさん mailto:sage [2021/03/19(金) 11:50:29.50 ID:bqIgZIMs.net]
- 日本三名泉の心地よさに身も心も籠絡されてしまうわけか
- 627 名前：デフォルトの名無しさん mailto:sage [2021/03/19(金) 17:45:14.93 ID:eiJMVgO4.net]
- >>606
お前まだいたのか。何が犯罪的でgitが何故共犯なのか説明してくれよ
- 628 名前：デフォルトの名無しさん [2021/03/26(金) 01:42:50.92 ID:YMBMwB0G.net]
- あげ
- 629 名前：デフォルトの名無しさん mailto:sage [2021/03/27(土) 08:45:34.40 ID:EpqbRgcD.net]
- Git v2.31.1
- 630 名前：デフォルトの名無しさん mailto:sage [2021/03/28(日) 19:48:47.28 ID:Krp9vXha.net]
- kernel.orgにgitのコマンドや引数が網羅されているドキュメントがあったと思うんですが
URLをご存知の方おしえてください
- 631 名前：デフォルトの名無しさん mailto:sage [2021/03/29(月) 03:53:51.49 ID:/bgSgfa2.net]
- https://git.wiki.kernel.org/index.php/GitDocumentation
これ？
git inurl:kernel.orgでググったよ。
- 632 名前：デフォルトの名無しさん mailto:sage [2021/03/29(月) 13:04:27.67 ID:BgFmge6o.net]
- >>615
違うな
こういうレイアウトのページ
https://man7.org/linux/man-pages/man1/tmux.1.html
- 633 名前：デフォルトの名無しさん [2021/03/29(月) 15:22:33.89 ID:C
]
- [ここ壊れてます]
- 634 名前：IMAnoRE.net mailto: まさかと思ったけど、もしかしてmanページのことか？ []
- [ここ壊れてます]
- 635 名前：デフォルトの名無しさん mailto:sage [2021/03/29(月) 18:42:53.14 ID:y3naImr+.net]
- >>616
www.kernel.org/pub/software/scm/git/docs
上にマニュアルのリンクあったけど。
- 636 名前：デフォルトの名無しさん mailto:sage [2021/03/29(月) 18:48:06.84 ID:RMTcu+Or.net]
- こっちの方が見やすいかも。
https://git-scm.com/docs/git
- 637 名前：デフォルトの名無しさん mailto:sage [2021/03/29(月) 22:54:46.19 ID:/bgSgfa2.net]
- おれもそっちのほうがいいと思ったんだけどkernel.orgの方を探しているみたいだったので…
- 638 名前：デフォルトの名無しさん mailto:sage [2021/04/01(木) 19:24:56.13 ID:V5XDv8GL.net]
- コミット対象をよりわけるのをやめてみよう
https://b.hatena.ne.jp/entry/s/irof.hateblo.jp/entry/2021/03/31/230014
- 639 名前：デフォルトの名無しさん mailto:sage [2021/04/01(木) 21:33:40.53 ID:UYCd/2R+.net]
- >>621
あんまり説得力ないな
- 640 名前：デフォルトの名無しさん mailto:sage [2021/04/01(木) 22:13:59.29 ID:5yR0ePhC.net]
- これは害悪でしょ。
- 641 名前：デフォルトの名無しさん mailto:sage [2021/04/01(木) 22:17:02.72 ID:xJm323aF.net]
- git add . でいいじゃん（いいじゃん）
- 642 名前：デフォルトの名無しさん mailto:sage [2021/04/01(木) 22:34:41.40 ID:SRnc7vTe.net]
- git add . とgit add -A とgit add -A .は何が違うの？
次の認識でいい？
1つ目が、カレント以下のディレクトリのみを更新(add, modify, remove)
2つ目がレポジトリのルートから全部更新
3つ目は1つ目と同じ。
- 643 名前：デフォルトの名無しさん mailto:sage [2021/04/03(土) 08:23:34.30 ID:34TEePpI.net]
- windowsのandroid studioで、git/githubで管理してるプロジェクトがあるんですが、OSを新規インストールしてandroid studio/gitも新規インストールしました
ただ、プロジェクトは別のドライブにあるのでそのままですが、続きをやる場合は何が手っ取り早いのでしょうか?
一旦プロジェクトを削除してgithubからcloneしなおす以外に方法あったら教えてください
- 644 名前：デフォルトの名無しさん mailto:sage [2021/04/03(土) 08:26:06.69 ID:GvC+rDGr.net]
- >>626
Android Studioで別ドライブのプロジェクトをそのまま開けばいいのでは
- 645 名前：デフォルトの名無しさん [2021/04/03(土) 12:37:10.32 ID:cIOl2khA.net]
- 何故このスレで聞いてんの?
馬鹿なの?
- 646 名前：デフォルトの名無しさん mailto:sage [2021/04/03(土) 17:09:28.94 ID:34TEePpI.net]
- >>627
そうですか
githubのアカウントなどのリモートリポジトリの情報はどこに格納されてるのかなと思いまして
別のドライブのプロジェクト内に保存されてたらそのまま開けばよさげですが、その情報削除されてるならどうやって続きをと思った次第です
- 647 名前：デフォルトの名無しさん mailto:sage [2021/04/03(土) 17:51:35.48 ID:5vTcRKik.net]
- 確認されるからもう一度認証すればよし
- 648 名前：デフォルトの名無しさん mailto:sage [2021/04/03(土) 18:01:23.58 ID:34TEePpI.net]
- ありがとうございます
試してみます
- 649 名前：デフォルトの名無しさん mailto:sage [2021/04/03(土) 18:28:54.37 ID:xn142qC9.net]
- >>628
gitの話だから問題ない
- 650 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 17:58:47.10 ID:krJCqveJ.net]
- >>621読んで気になったんだけどPR出してから歴史の改ざんって出来ないかな･･･
セルフチェックせずに勢いで出してからあそこ違う、ここ、そこもとなってforce-pushのログで汚れてしまった
- 651 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 19:16:36.06 ID:UzZbaOku.net]
- 普通にできるだろ
自分のリポジトリなんだから
- 652 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 20:30:57.77 ID:krJCqveJ.net]
- もちろん他人様のリポジトリさ
- 653 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 20:33:26.96 ID:wo2ZdM5G.net]
- 他人のリポジトリに勝手にブランチ作れるわけねーだろ
- 654 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 23:06:47.08 ID:zj2MWyXX.net]
- どういうこと？
取り込まれる前なら出し直せばいいし、
取り込まれたらもうできないでしょ
- 655 名前：デフォルトの名無しさん mailto:sage [2021/04/13(火) 02:20:43.67 ID:4xD0K2WJ.net]
- 他人のリポジトリにforce-pushしてんのか
恐ろしい恐ろしい
- 656 名前：デフォルトの名無しさん mailto:sage [2021/04/13(火) 03:30:08.40 ID:tPkELVcX.net]
- プルリク
- 657 名前：後にforce pushするとGitHubの方に記録が残ってしまう話では []
- [ここ壊れてます]
- 658 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 13:17:35.49 ID:/N2qyT4U.net]
- google colabでgithubから自作パッケージクローンしてpipインストール
その後、自作パッケージを変更してpip uninstall後に再pipインストールしても更新されない
colab内でpip showで辿った自作パッケージのソースコードは変更されてるのに。。
colabの「ランタイムを出荷時にリセット」てやってからだと当たり前だけどきちんと更新される
が、地味に時間がかかる・・
gitに限ったことじゃないけど
github + google colabで開発してる人はどうやって対応してるんだろ
- 659 名前：デフォルトの名無しさん mailto:sage [2021/04/21(水) 04:02:09.41 ID:U7I+mJcY.net]
- リベースして消えたけど 0666060 というコミットIDができたｗ
- 660 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 21:50:55.54 ID:PpQLqqbV.net]
- featureブランチでの機能追加とテストが完了した後masterへのマージでコンフリクトが発生した場合、逆マージ(masterをfeatureにマージ)とリベースどっちで競合解決するのが普通なんでしょう？
身内で以下のような感じで意見割れまして
>逆マージ派
コンフリクト解消前のコミットログがそのまま残るので、コンフリクト解消後のテストで解消前には発生しなかった不具合が起きた場合に原因を追いやすい
Gitは切り戻しを担保するのも役割の一つであり、ログの見やすさのために情報を欠落させるべきではない
>リベース派
コンフリクト解消のコミットログは機能追加において本質的な修正ではなく、履歴を追う際ノイズになるので残すべきではない
コミットの単位が適切であればコンフリクト解消時にミスがあり不具合が発生したとしても原因特定に苦労することはない
- 661 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 22:03:41.43 ID:Q2nzZb5u.net]
- > コンフリクト解消前のコミットログがそのまま残るので、コンフリクト解消後のテストで解消前には発生しなかった不具合が起きた場合に原因を追いやすい
実際には追いにくい
- 662 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 22:06:45.40 ID:Q2nzZb5u.net]
- 逆マージの問題はマージが2回発生すること
featureブランチへのマージしたと
それをmasterブランチにマージしなければいけない
その仮定で二重にコンフリクトが発生することがある
ログの中に同一内容に見えるコミットが複数含まれることになる
- 663 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 22:33:21.98 ID:wdsr0BNZ.net]
- >>642
プロジェクトごとに考えは違うと思っていて、何を大事にするかで変わると思っている派の意見として聞いてください。
個人的には逆マージを採用します。
理由としては、コンフリクト解消のコミットを除けばfeatureの変更もリベース同等にわかりやすく、featureブランチの担当者に負担をかけないので、バランスがいいと思うからです。
解消のコミットが本質でないのはそうですが、避けられないものなら、feature実装と解消を分けて考えられるので、不具合があった場合の混入原因の特定のしやすさ→その後の改善にも繋げられると思います。
リベースの場合は、上に書いたことの裏返しでもありますが、場合によってはコミット集合を作り直す必要があると思います。
また、作り直している間にmasterやdevが更新されてたりすると、ああ面倒。このようなケースで、コンフリクトが起きる頻度は、PJの規模や同時に走っているtopicの関係にもよると思いますが…
逆マージでは最後に払うツケを、リベースでは毎回払う可能性がありますよね。わたしはそれが開発のスピードを損なうノイズだと思っています。もちろん規模によります。
でも後で見たときにはキレイなので、そこにはメリットがあると思います。
保守性のためにコミットをきれいにしておくのは大切だとは思いますが、経験上diffとblameでなんとかなる場合が多いと感じていて、将来必要とされないことに時間をかけるくらいなら、現状の開発速度に重きをおいた方がよい、というのがわたしの主張です。
的を外していたらすみません。
- 664 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 22:
]
- [ここ壊れてます]
- 665 名前：59:29.24 ID:yD2kOx7X.net mailto: >>643
解消前後でテストがpassかfailの二択なので追いやすいと思う。
追いにくい具体的な状況ってどういうものですか？ [] - [ここ壊れてます]
- 666 名前：デフォルトの名無しさん mailto:sage [2021/04/23(金) 23:01:37.12 ID:PpQLqqbV.net]
- ありがとうございます！
>>645はほぼ私が考えていることと合致していて安心しました
>>644のケースは作業自体はリベースの方がかえって大変ですよね
逆マージはその代わりもっとログが汚くなるのでトレードオフかなと
>feature実装と解消を分けて考えられるので、不具合があった場合の混入原因の特定のしやすさ→その後の改善にも繋げられる
特にこれが正に私が逆マージ派である理由なんですが、>>643は意見対立してますね
できれば>>643の理由が聞きたい…
- 667 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 00:29:41.30 ID:v8PWrE/P.net]
- >>642読んで逆マージ派なのかなーという気はしていましたが、
リベース派の知人の意見を整理してみるのもいいかもしれないですね。
リベース派の理由が曖昧な感じがします。
コミットの単位が適切であれば…苦労することはない、の部分が理由としては弱い気がするので。
まあここには省いて書いたのかもしれないですが。
- 668 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 00:34:27.65 ID:v8PWrE/P.net]
- あ、適切という言葉に客観性がほしいという意味です。
ここでは原因の追いやすさが、2つの立場の焦点だと思うので、
その適切さがどのようなものであれば、どう切り分けできるのか。
- 669 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 00:49:24.56 ID:6TA9BQj4.net]
- リベースで何度もコンフリクト発生するのって、単にfeatureの切り出し方が不適切だったり巨大なPRがずっと居座っていたりするように、開発のフロー自体に問題があるんじゃないの？
- 670 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 07:12:17.73 ID:lum8vFBO.net]
- > コミットの単位が適切であれば…苦労することはない、の部分が理由としては弱い気がするので。
「コミットの単位が適切であれば苦労することはない」は理由じゃなくて事実
逆マージってログを見ないでしょ？
残っていればOK。あとから頑張れるはず（希望。実際には頑張ったことはない）
見ないログはなんの役にも立たないし汚いログも見れないのでこれも役に立たない
>feature実装と解消を分けて考えられるので、
分けて考えてる時点でダメじゃん
リベースしてしまえば、実装だけしか考えなくて良くなる
バグが見つかった時、実装と解消の２つがあれば
実装のバグかも知れないし解消のバグかも知れない。
バグの可能性が２つに増えてしまっている
リベースしてしまえばそれがなくなる
> あ、適切という言葉に客観性がほしいという意味です。
いきあたりばったりで作業するなということ
どうせ、こう修正した、気分が変わってやり直した、レビューの指摘があったから変えた
バグが見つかって対応した。って同じ箇所を何度も修正したのがコミットに残ってるんでしょ？
このコミットをあとから見て役に立つとでも思ってんの？
一連のブランチである箇所のコードを修正しているコミットを一つに保つように
随時リベースしていれば何も困らない。masterが更新されるたびにリベースしていれば
何も困らない。コンフリクトがほぼ発生しない。それが適切ということ
- 671 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 10:18:40.57 ID:vKvwVCfN.net]
- コンフリクト解消のコミットでバグを作り込みやすいと考えるのか、それが重視されるほどのリスクではないと考えるのかで選択が変わるんじゃないかな
順不同で両方取り込めば済むようなほんの小さなコンフリクトであればrebaseの利点のみが優勢になるし、複雑なコンフリクトであれば逆マージの利点が優勢になる
複雑な解消作業までrebaseで混ぜてしまうともったいないし潔癖が過ぎる感じ
その辺をガイドラインにしつつ線引は各人のこだわりに任せるのがうまく回りそう
- 672 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 10:31:26.53 ID:Q6OLD2jb.net]
- >>648のおっしゃる通り友人の言うことがよく理解できてなかったんですが>>651でおおよそしっくり来ました
その上でもやはり、あるfeatureリリースによって別の機能がデグっていることが判明した場合などにおいて、逆マージコミットが残っていた方がよいのではないかと思いました
コンフリクト解消にてうっかり
- 673 名前：失敗したのか、新機能実装において意図を持って変えたのかが明確になるからです
>>652の仰るとおり複雑なコンフリクトであれば逆マージにしてそれ以外はリベースすると言うのが個人的な結論になりそうです [] - [ここ壊れてます]
- 674 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 11:47:51.81 ID:O5bj5KLh.net]
- 逆マージした後にさらにまとめコミットを作ってマージするのはダメかしらん？
（squashの手動版）
手間がかかるけど、詳細も概要も両方残るからマシな気がするけど。
- 675 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 19:46:18.78 ID:lum8vFBO.net]
- > >>652の仰るとおり複雑なコンフリクトであれば逆マージにしてそれ以外はリベースすると言うのが個人的な結論になりそうです
複雑なコンフリクト＝開発に失敗したブランチ
開発に失敗したから逆マージするしか手がなくなってる
仕事だと期日まで仕上げろと言われて、みんな諦めるが
これがきっちりとしたオープンソースの開発だと、そんなものマージできませんでリジェクトされる
- 676 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 19:50:06.67 ID:lum8vFBO.net]
- >>652
> コンフリクト解消のコミットでバグを作り込みやすいと考えるのか、
「コンフリクトの解消でバグが発生」という事自体がナンセンスだよね
だって開発自体は問題ないって認識なんでしょ？
開発自体に問題ないのに、コンフリクトでバグが発生するというのなら
それはもはや、コンフリクト解消という名の追加開発じゃんｗ
開発終わってるのに開発続けてどうするの
マージが問題なく完了できるという所までが開発でしょ？
- 677 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 19:59:19.02 ID:lum8vFBO.net]
- >>653
> その上でもやはり、あるfeatureリリースによって別の機能がデグっていることが判明した場合などにおいて、逆マージコミットが残っていた方がよいのではないかと思いました
> コンフリクト解消にてうっかり失敗したのか、新機能実装において意図を持って変えたのかが明確になるからです
いやさ、なんでコンフリクトが発生するのか理解してないの？
masterとブランチの両方でコードを修正したときなんだが
masterの修正は他の人がやってる。
コンフリクトが発生するってことは、他の人がやった開発内容を把握してないということ
コンフリクト解消時に他の人がやった開発内容を把握するなんて大変な作業をやるんか？
同じ箇所を修正してるのに、お前のコードはその他人の開発内容を踏まえた修正になってないだろ
ちゃんとテストしてるんか？してるわけないよなコンフリクト解消時に判明するぐらいなんだから
コンフリクト解消時に、ついでに一緒にって追加開発するなよ
近い場所を修正したときなど、簡単な修正が必要なコンフリクトは発生することはあるが
あとからコンフリクト解消の内容を精査するなんてことがあること自体がおかしい
|
 |
