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も苦にならない

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

最初から意味がある単位で小さくまとめるのが理想だけど、
後からブランチの履歴を整理する手段も色々ある。

gitでアレを元に戻す108の方法
http://labs.timedia.co.jp/2011/08/git-undo-999.html
Gitでやらかした時に使える19個の奥義
http://qiita.com/muran001/items/dea2bbbaea1260098051

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/09(木) 08:27:12.93

git(hub)-flow

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/02/13(月) 10:17:21.25

git mvしないでmvしちゃったんですけどgit addしたらrename扱いになってました
絶対にgit mvしなくてもgit画面どう見てくれるから問題ないってことですか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/13(月) 10:39:40.22

>>19
中身を書き換える前ならわりと追ってくれる
どこまで追ってくれるか試すと楽しいぞ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/13(月) 15:13:09.61

改行コード変わるだけで別ファイルになるけどな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/17(金) 09:56:23.44

毎日仕事が終わったら、その日作ったソースコードを
gitサーバーにコミットして帰宅する俺。

**デフォルトの名無しさん** (ﾜｲﾓﾏｰ) · 2017/02/18(土) 01:13:13.92

コミットして帰ると次の日休んだ時にビルドが通らないと呼び出し喰らうパターンだな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 01:21:39.27

>>22
プッシュじゃなくて？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 01:58:54.36

>>24
ごめん、プッシュね。

マネジャーの人が俺らの作業をチェックしたいらしくて、
毎日帰るときにみんなプッシュしてから帰宅する。
svn時代と変わらない。

2017/02/18(土) 02:04:19.48

細かくコミットしていくことを心掛けたいが、気付くとコミットを忘れて突っ走ってしまう
そんな馬鹿野郎におすすめのツールとか運用とかないですか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 03:06:20.95

>>26
突っ走った後にgit add -p 使って複数のコミットを作る

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 11:33:38.07

>>26
一定時間ごとに自動でコミット、プッシュするスクリプトがあったと思う

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 13:22:21.19

>>28
そんなことするぐらいなら、
一定時間ごとに「コミットしろよ」って通知出すほうが良いわなｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/19(日) 22:56:47.13

cron 書けとしか言いようがない。

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

エディタに自動保存機能なけりゃ編集内容はメモリ上にしかないからどのみち死ぬ

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

>>31
数分おきにエディタに :wq! を送るスクリプトを作ろう

**デフォルトの名無しさん** (JP) · 2017/02/22(水) 15:45:05.02

意味のある区切りじゃない自動保存などゴミ

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/22(水) 16:51:00.38

そもそもコミットは成果毎に行うのであって細かくすればいいというものではない

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

プレーンテキストとかワープロとかならともかく、ソースコードだったらコンパイルするためにどんどん保存してるんだから自動保存ってそこまで必要性高いものでもなくない？

2017/02/22(水) 19:54:40.37

コミットと保存の話が混ざって混沌としてきてる

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/22(水) 20:45:47.20

個人開発なら単なる履歴残しに使ってもいいがチームの場合はそれじゃ困るんだよね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/23(木) 01:11:00.83

ショートカットキーctrl+Sで保存は便利でよく使う
履歴残し程度なら同様にショートカットキーで保存とコミットができるようにエディタにスクリプト組み込めばＯＫ
初回ショートカットキーで一時作業用ブランチを切らせて
一通り終わったなら別のショートカットキーでsquashなりでまとめてからコミットメッセージ入力窓でも出してから本来の作業用ブランチにFFマージさせればおｋ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/23(木) 10:00:04.78

>>37
チームの場合はgitは個人で自由に使わせておいて
チーム側では集約にsvnを使うよね

2017/02/23(木) 16:27:13.03

>>39
ない

svnで運用された頭が痛くなるような履歴をgitに取り込むことはよくある

2017/02/23(木) 20:55:38.64

チーム毎にgit使って、各チームの成果をインテグした時にsvn使う事はある
個人でgit、チームでsvnって構成はgitの美味しさの大部分を潰してるように見えるけど、想定してる規模が分からんし何とも言えんか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/24(金) 14:06:29.60

SHA1の衝突がGoogleによって公開、gitにも言及
https://shattered.it/

それに対するLinusの見解
http://marc.info/?l=git&;m=148787047422954

**デフォルトの名無しさん** (JP) · 2017/02/24(金) 14:11:42.95

hashの衝突は元から想定済っしょ
そもそも5桁でちぎって管理()してるんだし