Git 15©2ch.net

2017/02/05(日) 05:22:15.65

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 13
http://echo.2ch.net/test/read.cgi/tech/1439563364/
Git 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/

VIPQ2_EXTDAT: default:vvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/05(日) 06:30:39.79

<　｀∀´>ﾆﾀﾞｰ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/05(日) 14:05:34.08

Git v2.12.0-rc0
https://github.com/git/git/blob/master/Documentation/RelNotes/2.12.0.txt

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/05(日) 15:38:55.62

rebaseを使いこなして初めて
gitを使えるようになったと言える

**デフォルトの名無しさん** (ｴﾑｿﾞﾈ) · 2017/02/05(日) 15:39:17.20

>1 乙py

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/07(火) 10:05:09.07

gitlab復旧作業8時間実況すげ
https://www.youtube.com/watch?v=nc0hPGerSd4

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/07(火) 11:25:57.76

rebaseの使い途がそんなにないんじゃね
コミットが何百もあったときにrebaseで綺麗にできると思えん
squashはresetでできる
使えるのは過去のコメントを編集するときくらいか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 03:26:19.24

>>7
コミットが何百もあるブランチを
マージするってのがそもそも間違いだよね？

そのどでかいブランチから、小さく機能を抜き取って
小さなブランチにしてマージするべきだよ。

そのときにcherry-pickを使うのは当然ながら
抜き取ったあとの整理でrebaseも行う

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 03:53:20.12

エスパーすると
>>7は"git rebase -i [コミット]"くらいしか使ったことないんじゃなかろうか
違ったらごめーんね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 11:32:37.78

何かそういう、ブランチを整理するときのワークフローで分かりやすいドキュメントってないですか？

いつもいろんなgit操作を試行錯誤してしまって、本題がコミットすることからブランチ整理することにずれていってしまうので。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 11:38:22.96

>>8
なるほどと思ったが
cherry-pickは操作後の動作が保証できない
mergeなら操作後の動作が保証できる。完全ではないがcherry-pickよりまし
なのでmergeのほうが優れている

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 15:36:17.78

>>10
masterブランチにcommitしまくるからそうなる
最初に開発ブランチ作れ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 17:10:20.00

>>12
あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 19:40:31.54

最強の整理整頓術はそもそもモノを増やさないことだってのは全く間違ってないと思う
ブランチ整理って何がしたいのか分からんけど、successful git branching modelでも参考にしたらええんちゃうの

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 22:22:54.22

>>11
> cherry-pickは操作後の動作が保証できない

何を言ってるんだ？
cherry-pickはあるコミットを持ってくるというだけの機能で
cherry-pickしたあとの動作なんて最初から何も保証してないんだが

保証できないんじゃなくて、保証してない
だからrebaseして、そのcherry-pickしたコミットが正しく動くようにするんだよ

ちなみに、そもそもなんでcherry-pickして動かなくなるのかといえば
こまめなrebaseをしてないから。例えばコミットに対する修正を別コミットに
していたりするとそうなる。こまめにrebaseして意味のある単位にコミットを
修正していれば他人が読んだときのレビューも楽になるし、再利用もしやすくなる

> mergeなら操作後の動作が保証できる

mergeはブランチ全てをマージするものであってそもそも使うべきところが違う。
ブランチの中の1コミットだけを抜き取りたいときにmergeではできない
（できないからmergeの方が劣ってるとでも？ｗ）

使い方が違うだけの話でどちらかが優れているとか劣っているとかいう話じゃない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 22:48:05.72

>>13
> あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

簡単に言えば、こまめなコミット、こまめなrebaseだよ
有名なオープンソースソフト（例git）のコミットログを眺めてみればいい
あれが目標とすべきコミット

眺めてみればいいといったが、コミットログっていうのは読むものなんだよ。
後から読むこともあるしレビューのときに読むこともある。だから可読性が必要

じゃあコミットの可読性はどうやればあげられるかというと
意味がある単位で小さくまとまめること

例えば試行錯誤した形跡を表しているようなコミットを持ってこられたって
ここバグってる？すぐあとのコミットで修正されてるやーんとなって時間を無駄に費やするだけ
かと言って複数のコミットを全部まとめてしまったら量が多くなりすぎる

では意味がある単位で小さくまとめる（＝ワークフロー）にはどうするかとうと
まず開発中は小さくコミットしていく。大きな単位でコミットしてしまうと後で分けるのが大変になるから。
そして開発中はこまめにrebaseする。他の人にとって知りたいのは結果であって過程じゃない。
プルリク出すときには、最初から間違いなく作業しましたよっていう状態にして置かなければいけない。

rebaseが下手な人はコミットも大きくなって、いろんな修正を混ぜてしまう。
そういうことをするからrebaseするとコンフリクトまで起きてしまう。
コミットを小さくしていれば驚くほど簡単にrebaseができてしまう。
だからこまめなrebaseも苦にならない