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の方が劣ってるとでも？ｗ）

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