メニュー

2013年4月19日

Gitの運用ルール、ワークフローを考えてみた 2

最近は、こんな感じでやるといいかなと思っています。

outline

  • masterが中心
  • masterからbranchを作って作業する
  • 作業が終わったらmasterにmergeする

master

masterブランチは、常にデプロイ可能である。 テストされていないもの、リリース前のものはmasterにはコミットしない。 masterは他のブランチからmergeすることで更新していき、masterでは作業しない。

branch

機能の開発やバグ修正などは、branchを作成し、そこで行う。 branchはmasterから作成する。
まず、masterを最新の状態にするために、リモートからpullする。
git checkout master
git pull origin master
続いて、masterからbranchを作成する。
git checkout -b yourname/feature master
branchの名前は、担当者の名前とタスクの名前を組み合わせたものとする。 例えば、担当者が john で、タスクが blog 機能を作ることであれば、 そのブランチは john/blog となる。
もし john がバグ159の修正を行うなら john/bug159 や john/fix159 となる。
branchの名前は、各担当者が自分に分かるように自由に命名してよい。

toplevel branch

複数の担当者が共同で使うbranchの場合は、担当者の名前を含めないbranchを作成する。
git checkout -b feature master
このとき、このtoplevelのbranchは、関係する担当者の間で、準masterのように使う。 toplevel branchとmaster間の同期は、随時行っていくこと。

commit

自分のbranchで作業している場合、好きなタイミングでコミットしてよい。 この時、そのコミットがテストされた状態である必要はない。 ブランチでは、デプロイ可能な状態を常に保つ必要はなく、 あくまで、masterにマージする段階でテストされていればよい。

rebase

自分のbranchへmasterの更新を取り込む場合、rebaseを使ってよい。 もちろんmergeを使ってもよい。 自分のbranchなので、どちらを使うかは、開発者が自由に決めてよい。
バグFIXや小さい機能の修正など、 修正内容が少なく影響範囲が小さい場合はrebase、 大きな修正を行ったり共通モジュールを更新している場合など、 コンフリクトが発生しそうな場合はmergeがよい。
rebaseでのコンフリクト解決は、mergeの場合より手間がかかるため。
rebaseする場合、まずはmasterを最新の状態にするために、リモートからpullする。
git checkout master
git pull origin master
続いて、自分のブランチでrebaseする。
git checkout yourname/feature
git rebase master
rebaseでコンフリクトが発生し解決したあとは、--continueで継続できる。
git rebase --continue
コンフリクトが多くmergeに切り替えたい場合などは、--abortでrebaseを取り消す。
git rebase --abort

rebase -i

merge

merge master

自分のbranchへmasterの更新を取り込む場合、mergeを使ってよい。
まず、masterを最新の状態にするために、リモートからpullする。
git checkout master
git pull origin master
続いて、自分のブランチでmergeする。
git checkout yourname/feature
git merge master

merge branch

開発が完了したbranchはmasterにmergeしてよい。 masterにmergeする場合は、--no-ff オプションでmergeする。
git checkout master
git merge --no-ff yourname/feature
masterにmergeしたものは、デプロイ可能なはずなので、リモートにpushする。
git push origin master
なお、mergeは原則として --no-ff で行うため、あらかじめ設定によって --no-ff を標準に設定しておくとよい。
git config --global merge.ff false
masterにmergeしたブランチは不要のため、削除しておく。
git branch -d yourname/feature
masterのリモートへのpushが失敗した場合、リモートに新しい更新がpushされている。 このとき、リモートをpullしたあと、確認および必要に応じてテストする。

squash

自分のbranchでの作業をmasterにマージする前に、 コミットをひとまとめにしたい場合は、squashオプションを使う。
まず、マージ用のブランチを作成しチェックアウトする。
git checkout -b yourname/feature/merge master
続いて、開発branchからマージする。
git merge --squash yourname/feature
内容を確認、必要に応じてテストしたあと、問題なければmasterにマージする。
git checkout master
git merge --no-ff yourname/feature/merge
git push origin master
不要になったbranchは削除しておく。
git branch -d yourname/feature/merge
git branch -d yourname/feature

tag

本番にデプロイする場合など、どのバージョンをデプロイしたか管理しやすくするために、tagを使う。 デプロイを行う前に、tagを作成しておく。
git tag tagname
タグ名の他に、説明を追加したい場合は -a オプションを使う。
git tag -am "詳しい説明" tagname

0 件のコメント:

コメントを投稿