- 1 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:23:08.66 ID:5CuOmznL.net]
- gitのコミットをより意味があるようにするためのガイドライン作成スレです。
なぜコミットはあるのか？ コミットが残っていることで
何の役に立つのかをよく考えましょう。
そしてガイドラインを言う時は、ちゃんと理由も書きましょう。
上司が言ったから絶対なんだ！今までそれでやってきたからそれでいいんだ！
みたいなのは理由ではありません。
- 52 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 22:43:28.86 ID:2XvJk2DZ.net]
- >>49
もう一つgitよりの話をすると、gitは誰が何故作ったのかを考えればわかると思うよ。
リーナスがソフトウェアを開発するために作ったよね？
そう、開発者のものなんだ。
開発の進捗を知るためのマネージャーのツールでもないし
ソフトウェアのロストを怖がる管理者のツールでもない。
ソフトウェアの開発、しかもそれを多くの人が関係するってことは
正しい修正であるかどうかを判断するには、ソースコードを読まないといけない。
頭数を揃えてテストしたって、正しい修正であるかなんてわからない。
どっかの金もってる大会社じゃないんだから、頭数自体揃えられないけどｗ
そういう文化にとって「テスト」とは誰でも（一人でも）テストの実行を再現可能な
テストコードであり、そのテストコードが正しいかどうかは、読んで判断するもの。
それ以外できっこないんだから。これは現実。
そこまでわかれば、あとは何が必要かがわかる。必要なのはコードが読みやすい
コミットであり、必要なツールは読みやすいコミットを作ることが出来るもの
そういう考えでgitが必要とされ生み出された。あとはそのgitの正しい使い方を理解していくだけだよ。
ただ一つだけ俺がラッキーだったのは、gitを知る以前から、読みやすいコミットの重要性を理解していたことかな。
完成されたソースコードだけじゃなくて、修正の内容とその過程自体もわかりやすいことが重要であると。
だから俺にとっては、gitは俺が考えた理想を実現するツールだったね。
- 53 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 09:57:57.81 ID:wRqn8b2I.net]
- 後からコミットログは簡単にまとめられて、逆に分割は困難なことを考えると
上書き保存するたびに即コミットぐらいでやるほうがいいのかなあ
- 54 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 10:12:42.73 ID:d62hq9+6.net]
- 休憩や今日の終わりの度にコミット？
動かないコミットは嫌だな
- 55 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 11:12:44.05 ID:gLTCEjdN.net]
- git って ID:2XvJk2DZ みたいな信者が沸くところが嫌なんだよね
理想に最も近いとか言うならまだわかるけど、理想を実現したとかちょっと気持ち悪い
- 56 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 11:38:15.57 ID:M4xMa8us.net]
- >>53
それでもいいぐらいだよ。ただコミットを整理せずに
放置しておくと何したのか忘れるので整理しながら作業した方がいい。
分割は面倒だけど困難というわけでもない。
やり方は色々あるけど、rebase -iの途中で分割作業をするから
（つまりある作業中に別の作業をするようなもん）
少し慣れが必要だけどね。
>>54
masterに入れるのは動くコミットに決まってるでしょｗ
トピックブランチなどは最終的に消すものなのだからどうでもいい。
誰が作ったそのルール？ コミットはどんなものでも
動くようにしろとか、変な自己ルールに縛られすぎだよｗ
理由があるからルールができる。理由を説明できないような
ルールを作らない方がいいね。
>>55
うん。それで？
なにか間違っているとか、もっといい案があるなら
どんどん言っていいんだよ？
- 57 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 11:58:20.38 ID:d62hq9+6.net]
- >>56
ならあんたのルールをここで公開してくれよ
採用考えるわ
- 58 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:02:28.86 ID:M4xMa8us.net]
- >>57
1からずーっと書いてきてる。
読みなおしてくれ。
- 59 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:08:41.21 ID:d62hq9+6.net]
- >>58
ずーっとってお前の発言は識別出来んわ
コミットしてくれー
だとコミットの使い方が違うか
- 60 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:10:30.52 ID:M4xMa8us.net]
- >>59
既に>>2で具体的に書いてるじゃないか？
- 61 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:11:32.71 ID:M4xMa8us.net]
- >>59
「コミットを意味があるように綺麗にしておけ」とは言っているが
その中で「コミット」という単語しか見えないのか？
- 62 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:14:40.91 ID:d62hq9+6.net]
- >>60
おいおい1からずっと書いてるから読めって
2がまとめかよ
しかもあれで具体的だなんて
ちゃんと仕事で複数人で活用してる人？
一人とか小さなものでやってるだけ？
なら、お前が書けと言われても作れていないから書けない、悪いがな
- 63 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:18:45.44 ID:d62hq9+6.net]
- もしかして、このスレって
自称優秀なPG様が作っているスレ集の１つだったか？
- 64 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:18:58.06 ID:mvvCE6hZ.net]
- 長文自分語り
しかも中身はオレオレ規約
きめぇ
- 65 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:26:04.87 ID:M4xMa8us.net]
- >>62
2がまとめじゃなくて、2が基本てな原則だよｗ
その後は>>2の補足をしたり、もっと具体的に踏み込んだ説明をしている。
あれで具体的って、お前やっぱり>>2しか見てないじゃないかｗ
だからちゃんと1から読めって言ってるんだが。
> ちゃんと仕事で複数人で活用してる人？
当たり前だろｗ 逆に一人でやるなら適当にやればいいだろ。
自分の書いたコードだったらコミットが汚くてもわかるんだよ。
でも他人の書いたコードのコミットが汚かったらわからないだろ？
レビューしてくださいって来たコードが、何百行もある大作1コミットだったら
レビューなんてできるわけないし、小さく分かれていても複数のコミットで
同じ行を修正していたりしたら、無駄なレビューをすることになる。
レビューするためには、ソースコードを綺麗にするだけじゃなく
コミットの内容も綺麗である必要がある
俺の話は複数人だからこそ必要な話をしてるんだが。
多くの人、それぞれスキルは違うし、悪意がある人迄いる可能性がある
オープンソースを見てみなさいよ。
適当なコミットはレビューできないから、そういうのはマージされないよ。
知った人間ばかりの会社内のやり方とはわけが違う。
会社内だとコードのが意味不明でも上司だからとか、あの人なら大丈夫だからとか
よくわからないけど、動いてるみたいだからいいんじゃね？
コミットが汚くてもろくにレビューもせずに適当マージしてるでしょ？
俺の意見は最初から一貫して、レビューが可能なように綺麗なコミットにしろって話をしてる。
- 66 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:27:55.94 ID:d62hq9+6.net]
- >>65
59へ戻る
- 67 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:29:08.27 ID:M4xMa8us.net]
- >>64
それで？
そんなものよりもっといい案が有るなら
それを言ってくれよ。
自分の意見を言わない奴に
発言する権利はないよ。
ミーティングと一緒。
ミーティングで誰かの意見に対して
「あなたの提案の内容に関してですが、
あなたの発言がキモいです。」
とか言ったら嘲笑ｗ
- 68 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:29:28.83 ID:M4xMa8us.net]
- >>66
どうぞ戻ってくださいｗ
はい、つぎ。
- 69 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:30:36.40 ID:M4xMa8us.net]
- gitのコマンドはわかるんだけど
gitをどのように使っていけばいいか悩んでいる人
相談に乗りますよー。
- 70 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:32:34.02 ID:d62hq9+6.net]
- やっぱりよく見るパターンだったな
自分語りのために無駄スレ作ってないで
ちゃんと会社の人とルール共有しろよ
- 71 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:34:05.28 ID:M4xMa8us.net]
- >>70
会社に人と共有しているルールというか
考え方を書いているだけですが？
それであなたの考え方は？
それがないとあんたはただの荒らしでしかないよ。
- 72 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:36:23.99 ID:d62hq9+6.net]
- 話し合いにも討論にも雑談にさえならないのは目に見えてるから遠慮しとく
- 73 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:37:48.19 ID:ByqCHqi5.net]
- そういやうちの会社にはいないけど、
よく聞くじゃん？
上の立場の人が、でてきた意見を何の理由もなく否定する人。
きっと自分の考えを書かずに否定する人って
上の立場になったら、そういう人になるんだろうなって思った。
ドラマや小説で悪役として描かれる
そういう上司。
- 74 名前：書込しすぎたからID変えたって書くの忘れた mailto:sage [2015/06/14(日) 12:39:12.98 ID:ByqCHqi5.net]
- >>72
バイバイｗ
俺にしてみれば、お前をあぼーんしたのと同じだから
それがお互いにいい結果。
意見がないならもう来ないでね。
意見があるのなら来ていいですよ〜ｗ
- 75 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:43:40.24 ID:jf78czBd.net]
- >>67
すごく良い発言があるよ
「あなたの提案の内容に関してですが、
あなたの発言がキモいです。」
とか言ったら嘲笑ｗ
だよなー
でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」
だな
- 76 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:45:15.73 ID:ByqCHqi5.net]
- >>75
> でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」
わろたｗ
２ちゃんねるだからいいとして、
そんなの会社でやったら即刻クビだろｗ
ホントこいつ発現する意味ないわーｗ
- 77 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:55:28.35 ID:d62hq9+6.net]
- >>74
おまえだれ？
少し前に指摘したことさえ忘れたの？
- 78 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:01:59.00 ID:ByqCHqi5.net]
- 少し前に指摘した人だってことをわかってるのに、
誰って聞いてるのはなんなんだろうなｗ
そんなのどうでもいいだろう？
ここにはgitに関する意見を書けよ。
- 79 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:03:37.00 ID:l6qAkUnh.net]
- >>54
>動かないコミット
開発ブランチは分けろω
- 80 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:08:29.35 ID:d62hq9+6.net]
- >>79
こまめなコミットって意見あったけら言ったんだが
開発ブランチなら、動かないコミットも許す？
開発ブランチは個人ごと？ローカルコミットだから人に迷惑はかけない？
マージしたら凄いゴミコミットの山では？
など疑問は多い
- 81 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:13:55.53 ID:ByqCHqi5.net]
- >>80
少しは考えたほうがいいよ。
なぜブランチはあるのか？
なぜ動く必要があるのか？
開発ブランチは個人ごとである必要があるかないか
何をしたら人に迷惑で何が迷惑でないか
疑問があるのなら、他の人はどうやっているかを考えればいい。
世の中にサンプルはいくらでもある。
前にも答えたけどgit自体のリポジトリを見るとか。
有名プロジェクトであれば、そこがやっているやり方には
何かしらの理由がある。
疑問が多いってことは、その疑問に対して
自分で何も考えてない証拠だよ
- 82 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:15:57.16 ID:d62hq9+6.net]
- >>81
お前は黙っててくれるかな
- 83 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:16:43.89 ID:ByqCHqi5.net]
- >>82
いやです♪
- 84 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:17:27.34 ID:ByqCHqi5.net]
- ちなみに>>80の疑問に関して言えば
俺は既に答えが出てる。
- 85 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:44:31.97 ID:ByqCHqi5.net]
- d62hq9+6はどうやら俺にレスして欲しくないようだし、
他の人の意見も聞きたいから>>80に答えるのは
明日ぐらいにしようかな。IDが変わってからｗ
- 86 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 15:53:01.11 ID:kgtEwFOS.net]
- >>34
githubの画面からはよく分からなかったから、ようやくcloneしたけど、mergeコミットと単なるコミットってどういう意味で呼び分けてるの？
- 87 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 16:10:14.38 ID:eC56/Xbq.net]
- > mergeコミットと単なるコミットってどういう意味で呼び分けてるの？
呼び分けるも何も、
マージコミットと単なるコミットは別物だけど？
https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A8%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%AE%E5%9F%BA%E6%9C%AC
> 単にブランチのポインタを先に進めるのではなく、Git はこの三方向のマージ結果から
> 新たなスナップショットを作成し、それを指す新しいコミットを自動作成します (図 3-17 を参照ください)。
> これはマージコミットと呼ばれ、複数の親を持つ特別なコミットとなります。
- 88 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 16:12:36.55 ID:eC56/Xbq.net]
- >>86
明らかに違うものとしてgitで管理されていることを示すために
te2u.hatenablog.jp/entry/2015/03/24/233447
> この状態でrebaseを行うときに-iオプションだけでは
> マージコミットは含まれない。マージコミットがあるときは
> -pオプションをつけて実行すると
> 指定した範囲のマージコミットが含まれる。
このように、rebase -iコマンドには
マージコミットという特別なコミットを
含めるか含めないかのオプションが有る
- 89 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 20:28:40.57 ID:2Vz7+5/W.net]
- >>30で単なるコミットではなくマージコミットを見ろって言ってるじゃん。
普通の使い方なら、そもそもマージコミットで個別の修正はあり得ないよね？
単なるコミット同士をマージしたものなんだから。
- 90 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 21:12:29.91 ID:eC56/Xbq.net]
- >>89
あぁ、その話か。
マージコミットには、どのコミットとどのコミットを
マージしたのかって情報が含まれるんだよ。
「単なるコミット同士をマージしたもの」という言い方が、
何か意味を勘違いしている気がするが、コミットには歴史の情報も含まれている。
（つまりAとBコミット番号が同じなら、過去も同じであるということ）
つまり、masterにbranch（のHEADのコミット）をマージするってことは、
マージコミットの中にはbranchの複数のコミット情報が含まれてることを意味する
>>30で言ってる「マージコミットの中」というのは、
マージコミットでマージしたブランチの複数のコミットを見ろって話。
それはブランチのコミット内容を意味する。
人によってはmasterに直接コミットを追加することもあって
マージコミットを使ってないコミットにはtypo修正とかあり得る。
（typo修正だけのブランチをffマージするのと同じ）
だからこのコミットを見てもブランチが綺麗に整理されてマージしているってことに気がつかない。
マージコミットの中の複数のコミットを見ることで、ブランチに含まれる
コミットは綺麗に整理してからマージされているってことがわかるって話。
- 91 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 12:22:13.27 ID:QV1BHlUK.net]
- やっぱり、マージコミットにはマージしたブランチの複数のコミットが含まれる、っていい方が分からんな。
githubは確かにそう見えるが、実際にはマージコミットは二つの親コミットをもつコミットだろう？
githubはpull request形式だから、マージ先ブランチとマージ元ブランチを明確に区別出来て、マージコミットをマージ元ブランチの複数のコミット、という意味に出来るのかな？
- 92 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 12:25:00.72 ID:QV1BHlUK.net]
- まあ、要するに、単なるコミットっていうのは、githubのmasterブランチ上で表示されるマージコミットでないコミットってことね。
- 93 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 18:51:40.59 ID:Vn1MoMzT.net]
- >>91
今masterブランチの話をしてるんだよ？
マージ先ブランチはmasterで
マージ元ブランチはmasterから枝分かれした
ブランチであることは明らかでしょう？
master
↓
A
│＼ branchA
↓ ↓
B a
↓ ↓
C b
↓ ↓
D c
│／
★
↓
：
★のマージコミットには、Dとcのコミットが記録されているだけだが、
cはbからの修正、bはaからの修正、aはAから枝分かれしたものって
ことははっきりわかるんだから、★はmasterにbranchAを
マージした結果できたものであると考えるのは自然でしょう？
多分君がわかってないのは、★にはDとcというコミットが記録されているが、
それだけだ。cの前がbであるかどうかはわからないし、いつ枝分かれしたかも
わからないって考えてるんじゃない？ そういうことはありえないよ。
- 94 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 19:09:32.17 ID:QV1BHlUK.net]
- ブランチ AのHEADがコミットcで、masterのHEADがコミットDのときに、ブランチAにmasterをマージする。マージコミット☆が出来る。
そのあと、masterがブランチAをマージすると、ffになってmasterのHEADが☆になる。
さて、このときマージコミットに含まれるコミットはa,b,cなのか？それともB,C,Dなのか？
- 95 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 19:29:30.20 ID:Vn1MoMzT.net]
- ffになったらマージコミットはないよ？
確実にマージコミットを作りたいなら
（通常masterへのマージではマージコミットを作る。
なぜならマージしたという情報を残すため）
--no-ffオプションを付ける
- 96 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 20:40:45.17 ID:QV1BHlUK.net]
- masterのHEADの☆はマージコミットだよ
- 97 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 20:46:14.81 ID:TKCLtNo1.net]
- >>95
+1
- 98 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 22:48:37.43 ID:Vn1MoMzT.net]
- >>96
言ったでしょう？
masterへのマージでは通常
--no-ffをつけるって。
だから>>94のような状態には通常ならないんだよ。
- 99 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 23:07:27.61 ID:tRPgSWCN.net]
- 相変わらずウルセーバカがいるな
- 100 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 23:27:33.58 ID:Vn1MoMzT.net]
- 運用ガイドラインの一つとして、masterへのマージは原則として
--no-ffをつけるってのも必要かな。
- 101 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 23:43:18.36 ID:QV1BHlUK.net]
- >>98
--no-ffすればマージコミットになるのは当たり前だし、
>>95ではffになったらって前提でマージコミットにはならないって言ってるし、
>>90ではffマージもあり得る話としているから、イマイチgitの仕組みを理解してない人なのか、github前提で話をしている人なのかの区別が付かなかったんだ。
今さら--no-ffをルールにすべきか？なんて言ってるけど、git自体は--no-ffが原則なの？
それともgithubのpull requestの運用だと--no-ffを原則にしなくても問題ないの？
- 102 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 02:44:17.56 ID:In84evFv.net]
- githubのpull requestの運用だと--no-ff勝手につけてくれるな
- 103 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 12:14:12.79 ID:tnRZvA/G.net]
- >>101
> 今さら--no-ffをルールにすべきか？なんて言ってるけど、git自体は--no-ffが原則なの？
いつも思うんだけど、単純なルールを欲しがるよね。
関係ないけど、ちょうどこんな記事を読んだんだよ。
アジャイルの破綻―原因、そして新たな提案
postd.cc/the-failure-of-agile/
> あなたが新しいプログラミング言語や技術、または開発手法などの新しいスキルを初めて学ぼうとする時、
> 経験やメンタルモデル、”調査と順応”といった抽象概念に対応する能力を持ち合わせていません。
> これらの能力は、より経験を重ねた熟練者だけが持ち合わせているものです
>
> 初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。
> 例えば、「これが起こったら、あれをする」といったようなルールです。
> ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提供されているため、
> 初めてアジャイルを取り入れるチームは、これら全てもしくは一部に固執してしまい、
> 凝り固まったやり方になってしまいます。
何も考えたくないから、簡単なルールを求める。
そうじゃなくてちゃんと考えようよ。
俺は「マージするときは必ず--no-ffをつける」なんて言ってないからね？
まず一つ「masterへのマージ」と言った。そして「原則として」と言った。
原則として
www.weblio.jp/content/%E5%8E%9F%E5%89%87%E3%81%A8%E3%81%97%E3%81%A6
> 例外が許容される場合があるという意味合いを含むことがある。
殆どの場合masterのへのマージは--no-ffになっており、それを参考にしろという話
何にでも例外はあって>>94はその例外。その例外を持って来られても
大半のmasterへの、”masterへの” マージは--no-ffになってるんだから、それ見ればわかるでしょ。
- 104 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 12:19:15.57 ID:tnRZvA/G.net]
- >>102
> githubのpull requestの運用だと--no-ff勝手につけてくれるな
そうなんだよね。基本的にmasterへのマージは--no-ffになるから
そんなの基本的な話だと思っていた。
そしたら、masterへのマージでffになる例を持って来られたから、
今さら（masterへのマージに）--no-ffをルールにすべきか？
って話をせざるを得なくなったんだよ。>>101
俺としては当たり前すぎの話だったので省略してしまった部分。
- 105 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 14:47:21.91 ID:pO7+dMQJ.net]
- うん、やっぱりgithub前提なんだね。
masterへのマージは--no-ffが基本だと思ってるってことは、masterへはrebase+ffで変更を取り込まない方が良いって思ってるってことだ。
それは何でだ？
- 106 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 14:58:19.81 ID:pO7+dMQJ.net]
- githubを前提にしないでコマンドラインだけで運用した場合は、マージコミットが増えることはログの煩雑化を進める気がする。
やっぱり、運用ガイドラインにはgitをサポートするツールに何を使用するか、というのも条件に含めないといけないと思う。
- 107 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 17:28:49.04 ID:rhusAjzF.net]
- >>105
github前提でもなんでもなくて、一般的な話だよ。
理由もそこに書いてあるとおり。
どうやら俺が説明すると、それは変なやり方だって思い込んでるのか
いちいち調べもせずに絡んできてるようだから、他人が説明した理由を紹介することにする
keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html
> --no-ff フラグは、たとえマージがfast-forwardで実行できるとしても、
> 新しいコミットオブジェクトを作成する。これは、履歴にフィーチャーブランチが
> 存在したという情報を失うのを避けるのと、機能の追加に使った全ての
> コミットをひとまとめにしておける。比べてみよう：
> 右の場合、ある機能を実装したコミットオブジェクトをGitの履歴から見つけられない
> ――あなたは全てのコミットログメッセージを手動で見なければならなくなるだろう。
> 機能の全て（例えば、一連のコミット）を revert しなきゃいけないなら、右の状況では
> 本当に頭を痛くさせる。だがもし --no-ff フラグを使用したなら、簡単に終わるのだ。
>
> 確かに、これだとより多くの（空の）コミットオブジェクトを作成するはめになるが、
> そこから得られるものはコストよりずっと大きい。
- 108 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 17:37:06.02 ID:pO7+dMQJ.net]
- これは、git flowモデル前提だね
- 109 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 17:58:50.29 ID:pO7+dMQJ.net]
- で、マージコミットでコミットを纏めるって考えは、コミットを意味のある単位で纏めるって話と繋がっていて、
githubなどのオープンソース開発モデルだと、マージコミットをpull request単位に出来て相性が良いと思うんだよね。
じゃあ、常にこのモデルが優れてるかという点については議論の価値があると思う。
4、5人の少人数開発で一つの意味あるコミットの大きさが小さい開発の場合は、コミット一つにつき一つのマージコミットが出来てそのログに書かれた内容が同じってことになる。
だったら、せっかく一つ一つのコミットを読み易く分割してるんだから、rebaseモデルで、masterを出来るだけ一本線に保つという考え方の方が、bisectが有効に働きやすいというようなことがあるかもしれない。
- 110 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 19:45:56.09 ID:2dhAz4DT.net]
- gitのgitを見ると、ブランチをマージしたってコミットはたくさんあるけど
普通のマージコミットみたいに、ブランチの中にあったはずのコミットはログに出てないね
すっきりしてていいから真似したいんだけど、--no-ff使って作ったもんなのかな
- 111 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 20:02:32.79 ID:rhusAjzF.net]
- >>108
> これは、git flowモデル前提だね
どこに書いてるのさｗ
「git flowモデル前提と知っている」ということなら
「git flowモデル以外では違うと知っている」はず。
ならば、違うフローでは、--no-ffをつけていないということを
具体例を上げて示すべきでは？
- 112 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 23:17:41.64 ID:pO7+dMQJ.net]
- >>110
これがgithubの機能として当たり前なのかどうかが分からないんだよね。
例えば、gitのコミットログをsourcetreeで見ると、とんでもなく並行してブランチが存在するように見える。
もし、sourcetreeのようにしかログを参照してなかッタトしたら、もっとブランチの分岐点を制御する運用にしようと考えるんじゃないかな？
- 113 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 23:52:06.93 ID:pO7+dMQJ.net]
- >>111
A successful Git branching modelのことを、git flowモデルとも言うんじゃないの？
danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html
このモデルでも--no-ffを原則にしてるから一般的なんだということをしめしたかったのかと思ったんだけど。
--no-ffを使わない、というgit運用モデルがあるかどうかは知らないなあ。
と、いうより、githubとgit flowのモデル以外に明文化されたgit運用モデルを知らない。
rebaseを主体としてmasterを出来るだけシンプルに保つ運用モデルがあっても良いとは思うんだけど、ちょっと調べた限りでは見つからなかった。
他にも知っているモデルがあったら、>>107のように紹介してくれたら有り難いんだけど。
- 114 名前：デフォルトの名無しさん mailto:sage [2015/06/17(水) 10:55:14.55 ID:l25RfAPf.net]
- 勘違いしてたんだけど、git自体が使用しているワークフローとgithubが想定しているワークフローとgithub flowというワークフローは全部違うみたいだね。
・git開発のワークフロー
daretoku-unix.blogspot.jp/2014/01/git-flowgithub-flowgit.html?m=1
・github flow
https://gist.github.com/Gab-km/3705015
githubがどんなワークフローを想定しているかは見つかってないんだけど、github flowがgithubの機能をシンプルに使って、みたいな感じで書いているから、github自体はgit自体と同様に特にワークフローを定義せずに利用者に任せるスタンスなのかもしれない。
- 115 名前：デフォルトの名無しさん mailto:sage [2015/06/17(水) 12:35:00.39 ID:Y0tcUgcD.net]
- masterへのマージで--no-ffをつけるって、githubフローの話だっただろ？
>>113
それをgit flowというのなら、githubフローとgit flowの
両方共、masterへのマージで--no-ffをつけるってことだ。
補足すると、gitlabでもmasterへのマージで--no-ffをつける
これで、git flow、github flow、gitlab flowの三つとも
masterへのマージで--no-ffをつけるということがわかった。
つけないものはあるのか？
- 116 名前：デフォルトの名無しさん mailto:sage [2015/06/17(水) 13:44:56.64 ID:l25RfAPf.net]
- >>115
>>114で貼ったgit自身の開発モデルでは--no-ffは付けないみたいだね。
gitworkflowにも書いてないし、gitのmasterブランチにもmergeコミットではないコミットも含まれている。
例えば、0e8771fなんてffされたmergeに見えないか？
そもそもpatchで取り込むことも想定されてるから、mergeの時だけ--no-ffを前提にすることは無意味だと思う。
- 117 名前：デフォルトの名無しさん mailto:sage [2015/06/19(金) 19:05:48.16 ID:RaZQIMSq.net]
- gitをより良くするのは諦めたのか
- 118 名前：デフォルトの名無しさん mailto:sage [2015/06/19(金) 19:10:42.34 ID:FzphauAa.net]
- スレタイは
Gitをより良く使うための〜
にするべきだったな
- 119 名前：デフォルトの名無しさん mailto:sage [2015/06/19(金) 23:37:29.06 ID:RaZQIMSq.net]
- >>11で終わってたな
- 120 名前：デフォルトの名無しさん mailto:sage [2015/06/20(土) 12:58:37.97 ID:Z2ENSL80.net]
- ぶっちゃけコミットログを綺麗にするのって
綺麗にするために払う時間コストに比べたらどうでもよくね？
- 121 名前：デフォルトの名無しさん mailto:sage [2015/06/21(日) 21:45:19.09 ID:1BopKhVm.net]
- コミットログメッセージの書き方についての話題が無いけど、>>1的にはどうなの？
ルールや提案、アドバイスなんか無いの？
- 122 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 06:34:11.93 ID:hmqK9V2H.net]
- そういえばコミットログは暗黙の了解な書き方があったね。
1行目：題名
2行目：空行
3行目以降：詳細説明
format-patchすると1行目から空行までを切り取られてSubjectにされるので
空行を入れずにたくさん書くと、なかなか面倒な事になった。
- 123 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 07:56:37.13 ID:Jo3Uu3lv.net]
- x 暗黙の了解
o プロトコル
- 124 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 21:37:10.67 ID:aUxHdKYd.net]
- 問題となるのはタイトル文。
アプリを作っているのなら、開発者ではなくそのアプリを主語にした文を書くという流儀があるね。
（ただし、主語そのものは省略する）
開発者がやったことではなく、アプリができるようになったこと、とか。
- 125 名前：デフォルトの名無しさん [2015/06/30(火) 06:51:11.57 ID:vdY22gQv.net]
- 運用のスレができたのはいいことだがわしには難しすぎる
とりあえず、テストのことを考えてみた。
こういうガイドラインはどうかな？
・どのコミットもコンパイル & 実行可能であることが好ましい
- 126 名前：デフォルトの名無しさん mailto:sage [2015/06/30(火) 08:12:45.77 ID:SNIIX8MT.net]
- どのコミットもコンパイル可能であることを保つと、rebaseやcherry-pickに制限が発生する気がするな。
あと、コミットを分かりやすい単位で分割する、とい指針と矛盾するときもあると思う。
・コンパイルが通らなくても構わないコミットを他と区別つくようにする
例えば、コミットA〜Dは変更内容の分かりやすさのために分割しているが、順序入れ替えや途中適用が出来ないことを示す記法を使用するとか。
- 127 名前：デフォルトの名無しさん [2015/07/01(水) 11:32:57.36 ID:5x1pwjnr.net]
- >>126
なるほどにゃぁ
- 128 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 12:47:28.53 ID:osw3K43k.net]
- >>126
それはコミット同士の依存関係であってコンパイル可能かどうかとは関係ない。
A>B>Cという歴史があってBで実装された関数をCで使っているのなら
コンパイル不能なコミットを許可したとしても問題は解決できない。
コンパイル可能なコミットにする事というのは
A
A>B
A>B>C
各歴史のHEADでコンパイルできる状態になっていますという事だよ。
- 129 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 13:50:55.44 ID:E0yPgYN2.net]
- ごめん、何を言いたいかわからない。
各コミットをコンパイル可能にしておくのも、結構難しいって問題を出したつもりだけど、そっちが問題と考えてるのは何？
- 130 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 15:32:42.97 ID:ok9JQHnv.net]
- コンパイルが通らないバージョンがコミットされてるなんて、気持ち悪くて嫌だ。
- 131 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 16:33:20.96 ID:WrSpGcQO.net]
- 気持ち悪いのは主観
作業用ブランチなら好きにしなはれ
- 132 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 18:11:07.44 ID:ok9JQHnv.net]
- そっか、ビルド可能（あるいはテストパス）を区切りにしない人もいるんだ。
- 133 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 18:15:48.22 ID:ok9JQHnv.net]
- というか、前回コンパイル可能から再びコンパイル可能までに書くコード量が違うのかな？
あるいは、ビルドにめっちゃ時間がかかるから、頻繁にビルドできないとかなのかな。
- 134 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 20:55:57.02 ID:osw3K43k.net]
- >>129
コンパイル、実行可能にしておくのは当たり前で、そういうのは理由にならないって事
全てのコミットがコンパイル可能になっていなければgit bisectが使えない
実際gitのソースコードでもv2.4.5からHEAD~1500くらいまで
全部コンパイルしてもコンパイルエラーになることはない。
git bisectみたいにgitの機能として実装されているのだから
gitを使う人にとっては全てのコミットをコンパイル、実行可能にしておくのは
当たり前で、難しいことではないという認識なんだよ。
- 135 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 21:01:43.98 ID:uCElgjag.net]
- developmentブランチ的な共有品に、ビルドすらコケるようなのを上げるのは
人の仕事を止めるから考えるまでもなく当然ダメだろう
- 136 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 22:49:22.90 ID:E0yPgYN2.net]
- >>134
だから、何の理由にならないかって所を聞いてるんだけど？
共有ブランチ上のどのコミットに着目してもコンパイル可能であるべきで、それは分かりやすいコミット分割に優先するって話かな？
つまり、コンパイル不能な途中経過をコミットするぐらいならsquashした方がマシ、と。
- 137 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 23:06:27.57 ID:E0yPgYN2.net]
- >>135
例えば、mater→A→B→Cというコミットのあるブランチをpull request受けた場合、マージする側はA,Bのそれぞれでコンパイル確認をしてからマージするべきだと思うかい？
それともCまでか？または、マージコミットに対してだけで良いと思うか？
自動実行テストがある場合はどうだ、それぞれで実施すべきか？
- 138 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 00:32:21.77 ID:BOecX6fF.net]
- >>136
だから履歴を遡っての問題分析を難しくしてしまうのと
git bisectが使えなくなるのが問題。
コンパイル実行可能なのもコミットのわかり易さもどっちも必須条件
コンパイル出来ないけど分かりやすいって具体的にどんな例？
オープンソースのリポジトリにそんな例ある？
- 139 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 03:31:37.55 ID:hbh5BBnI.net]
- SVNかなんかと勘違いしてないか
- 140 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 06:44:16.55 ID:H40fLBlj.net]
- 日時ビルドでコケましたってのが事故としてはありえても
それを理由に、開き直って機能しないってわかってるブランチpull requestしていいことにはならんだろ
発覚した時点で最優先でに修正することになるだろうし
- 141 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 18:30:32.56 ID:eJl3FSc8.net]
- revertでもresetでもなんでもいいんだけど、変更を破棄したくなったときに、どのcommitが
コンパイル可能なものなのかわからんという状況は困らないのかな。
- 142 名前：デフォルトの名無しさん [2015/07/02(木) 19:13:17.37 ID:bMzAU0w9.net]
- commitにコンパイル禁止と書いて桶
- 143 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 20:35:15.89 ID:E2OQ2sTs.net]
- >>138
オープンソースの例ではないが、業務上でありそうなものとしてはモジュール毎に担当者が決まっていて
1) 共通APIに機能を追加するために引数追加
2) それを使用している他のモジュールで引数追加に対応
で、1と2で担当者が違うから別々のコミットにしたい場合とか。
- 144 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 20:48:20.71 ID:E2OQ2sTs.net]
- merge --no-ff必須にしておけば、mergeコミットは必ずコンパイルもテストも通る、って運用は可能だと思う。
pushする前にはコンパイル確認必須、とした場合も、masterブランチにコンパイル不可なコミットが混ざる可能性があるが、動作保証を自動テストで担保している場合はそれほど困らないんじゃないかな？
テストの方は全コミットで動作保証できることを期待してないだろうし、コンパイルに通らない事はテストに失敗したとみなせば同じ事だし。
- 145 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 21:08:43.42 ID:BOecX6fF.net]
- >>143
ないな。新しいAPIを追加して前のものは残す。
新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。
そんなガチガチの縦割り組織ならリポジトリも別にするべきだ。
>>144
そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。
過去バージョンのアップデートリリースが作りにくくなる。
- 146 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 21:57:29.71 ID:E2OQ2sTs.net]
- >>145
>>>143
>ないな。新しいAPIを追加して前のものは残す。
>新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。
各コミットのコンパイル可能を保証するために、その手順を踏むことが望ましいという主張だね。
俺だったら引数追加するたびにAPI名を変更するぐらいなら、squashでまとめるか、常にコンパイル可能を諦める方を選ぶな。
- 147 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 22:01:33.42 ID:E2OQ2sTs.net]
- >>144
>そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。
cherry-pickが完全に取り込めるかは、そのときのHEADがコンパイル可能かどうかとは関係ないよね。
新APIを追加するコミット無しに、新APIを使うコミットは適用しても、コンパイル出来ないよ。
- 148 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 00:27:07.02 ID:9/hHKZ1h.net]
- >>147
cherry-pickの結果コンパイルは出来なくても意味のない単位で分割するよりは
必要な修正がまとまっている分、不完全なものになる可能性はずっと低くなる
例えば、Aに前処理とBに本処理がコミットが分かれていて
Bのみを拾った場合、理解不能な挙動をを起こすことになる。
コンパイルエラーになるならまだ良いほうで、
偶然コンパイルが通った場合は余計なデバッグに時間を費やすことになる。
- 149 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 08:59:41.32 ID:DfE7bDzR.net]
- いやだから、cherry-pickの結果、コンパイル通らなくても構わないのであれば、そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても、意味のある単位で分割されてれば阻害要因にならないよね。
>>143の例のようなモジュール単位でコミットを分ける、というのも意味のある分かりやすい単位だけど、複数のコミットの一部しか適用していない状態だと全体のコンパイルが通らないという弊害がある。
ガイドラインとして、それを許容するか否か、ということが論点のつもりだけど。
また、それを許容しない場合は、rebaseしたときに、手を入れた各コミットの段階ごとにコンパイル確認が必要になる。
全コミットでコンパイル保証をするというのは、その手間を払う価値があるか否か、というのも論点になる。
- 150 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 09:11:49.14 ID:OZHQEleK.net]
- >>146
+1
- 151 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 09:33:38.89 ID:AYyF2a3j.net]
- Gitではコミットって、見せる前にちぎってくっつけて書き換えるもんだから
粒度小さければ後はどうでもいいよな
SVN時代のコミットの話は、動かないブランチをメインにマージしていいか？のほうが近そう
- 152 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 10:45:33.74 ID:DfE7bDzR.net]
- >>149
>そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても
誤解を招く表現な気がしたので訂正。
>そのコミットを指定してcheckoutしたときにコンパイルが通らないとしても
|
 |
