gitの履歴を線形に保つ

615 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
615
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

gitの履歴を線形に保つ

  1. 1. gitの履歴を線形に保つ @y42sora 2013/07/07
  2. 2. 今回の発表は100%の正解では ありません いろんなところから 斧が飛んでくる可能性があります
  3. 3. Gitでマージを適当に使うと…
  4. 4. Gitでマージを適当に使うと…
  5. 5. わかりやすいコミットグラフ ○ ×
  6. 6. Git-flowだとわりと起きる…
  7. 7. Git-flowだとわりと起きる…
  8. 8. つ git rebase
  9. 9. git rebase git rebase <branch name> 現在のブランチのコミットを全て、 指定したブランチに対して実行し直す
  10. 10. 図解 develop feat/login 今ココ
  11. 11. 図解 develop feat/login git rebase develop 今ココ
  12. 12. 図解 develop feat/login
  13. 13. 図解 develop feat/login
  14. 14. 図解 develop feat/login
  15. 15. 図解 develop feat/login
  16. 16. 図解 develop
  17. 17. マージとrebaseの比較 • マージ 簡単操作 過去のデータは一切変更しない コミットグラフの地下鉄路線図化 • rebase コミットごとにコンフリクト処理 過去のデータを変更してしまう コミットグラフは見やすくなる pushしたやつをrebaseすると大変な事に…
  18. 18. 運用例 develop、masterに対してはマージする マージコミットを作成してマージする 変更とそれに付随する一連のコミットがわかるように 機能3 機能2 機能1
  19. 19. 運用例 マージ前は最新版にrebase レビュー後に自動マージすることで、 developに対してコンフリクト解決によるミスを入れてしまわないため ←マージミス ←マージミスがdevelopに
  20. 20. 運用例 マージ前は最新版にrebase レビュー後に自動マージすることで、 developに対してコンフリクト解決によるミスを入れてしまわないため developにマージする前に最新版のdevelopの変更を取り込む (branchにdevelopをマージする)というのもありだけど、 できればトピックブランチに別のトピックの変更を入れるのは避けたい 開発単位を小さくしてこまめにrebaseすれば そんなにコンフリクト解決で死んだりしない(多分
  21. 21. 運用例 作業用ブランチは作った人の自由 pushした後にrebaseしようが何でもOK レビュー前にはレビューしてもらう人が責任もってdevelopにrebase レビューの修正を反映する場合は履歴を書き換えるのは避けた方が良さそう
  22. 22. おまけ SourceTree便利だよ! リポジトリを見るならこれで

×