1. gitの履歴を線形に保つ
@y42sora
2013/07/07

2. 今回の発表は100%の正解では
ありません
いろんなところから
斧が飛んでくる可能性があります

3. Gitでマージを適当に使うと…

4. Gitでマージを適当に使うと…

5. わかりやすいコミットグラフ
○ ×

6. Git-flowだとわりと起きる…

7. Git-flowだとわりと起きる…

8. つ git rebase

9. git rebase
git rebase <branch name>
現在のブランチのコミットを全て、
指定したブランチに対して実行し直す

10. 図解
develop
feat/login
今ココ

11. 図解
develop
feat/login
git rebase develop
今ココ

12. 図解
develop
feat/login

13. 図解
develop
feat/login

14. 図解
develop
feat/login

15. 図解
develop
feat/login

16. 図解
develop

17. マージとrebaseの比較
• マージ
簡単操作
過去のデータは一切変更しない
コミットグラフの地下鉄路線図化
• rebase
コミットごとにコンフリクト処理
過去のデータを変更してしまう
コミットグラフは見やすくなる
pushしたやつをrebaseすると大変な事に…

18. 運用例
develop、masterに対してはマージする
マージコミットを作成してマージする
変更とそれに付随する一連のコミットがわかるように
機能３
機能２
機能１

19. 運用例
マージ前は最新版にrebase
レビュー後に自動マージすることで、
developに対してコンフリクト解決によるミスを入れてしまわないため
←マージミス
←マージミスがdevelopに

20. 運用例
マージ前は最新版にrebase
レビュー後に自動マージすることで、
developに対してコンフリクト解決によるミスを入れてしまわないため
developにマージする前に最新版のdevelopの変更を取り込む
(branchにdevelopをマージする)というのもありだけど、
できればトピックブランチに別のトピックの変更を入れるのは避けたい
開発単位を小さくしてこまめにrebaseすれば
そんなにコンフリクト解決で死んだりしない(多分

21. 運用例
作業用ブランチは作った人の自由
pushした後にrebaseしようが何でもOK
レビュー前にはレビューしてもらう人が責任もってdevelopにrebase
レビューの修正を反映する場合は履歴を書き換えるのは避けた方が良さそう

22. おまけ
SourceTree便利だよ！
リポジトリを見るならこれで