[過去ﾛｸﾞ]
Git 15©2ch.net (1002ﾚｽ)
Git 15©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1486239735/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
13: デフォルトの名無しさん (ﾜｯﾁｮｲ) [sage] 2017/02/08(水) 17:10:20.00 ID:glAhqeU30 >>12 あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい http://mevius.5ch.net/test/read.cgi/tech/1486239735/13
16: デフォルトの名無しさん (ﾜｯﾁｮｲ) [sage] 2017/02/08(水) 22:48:05.72 ID:EqksEKaR0 >>13 > あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい 簡単に言えば、こまめなコミット、こまめなrebaseだよ 有名なオープンソースソフト（例git）のコミットログを眺めてみればいい あれが目標とすべきコミット 眺めてみればいいといったが、コミットログっていうのは読むものなんだよ。 後から読むこともあるしレビューのときに読むこともある。だから可読性が必要 じゃあコミットの可読性はどうやればあげられるかというと 意味がある単位で小さくまとまめること 例えば試行錯誤した形跡を表しているようなコミットを持ってこられたって ここバグってる？すぐあとのコミットで修正されてるやーんとなって時間を無駄に費やするだけ かと言って複数のコミットを全部まとめてしまったら量が多くなりすぎる では意味がある単位で小さくまとめる（＝ワークフロー）にはどうするかとうと まず開発中は小さくコミットしていく。大きな単位でコミットしてしまうと後で分けるのが大変になるから。 そして開発中はこまめにrebaseする。他の人にとって知りたいのは結果であって過程じゃない。 プルリク出すときには、最初から間違いなく作業しましたよっていう状態にして置かなければいけない。 rebaseが下手な人はコミットも大きくなって、いろんな修正を混ぜてしまう。 そういうことをするからrebaseするとコンフリクトまで起きてしまう。 コミットを小さくしていれば驚くほど簡単にrebaseができてしまう。 だからこまめなrebaseも苦にならない http://mevius.5ch.net/test/read.cgi/tech/1486239735/16
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.042s