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

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

徐々にGitに移行しつつあるのですが、複数人数（チーム）でGitを使った場合の運用ルール、ワークフローというものを考えてみました。

Git使い始めということもあり、不備は多々あると思います。アイディア等あれば是非教えて下さい！



原則

• masterで作業しない。ブランチを作って作業する。
• ブランチでは1機能もしくは1バグのみ作業する。

ワークフロー

• 準備
• ローカルのmasterに移動する
• $ git checkout master
• ローカルのmasterをリモートと同期する
• $ git pull origin/master
• masterから、作業用のブランチを作成する。
• $ git checkout -b branchname master
• ブランチ名は担当者名と作業名をスラッシュで結合したものとする。
• 例： taro/featurename, taro/bugname
• コーディング
• コードを書く。
• コミットする。
• $ git status
• $ git add filename
• $ git commit -m "コメント"
• 直前のコミットを取り消す場合：
• $ git reset --soft HEAD^
• コーディングとコミットを繰り返す。
• コミットは頻繁に、どのような単位で行なっても良い。
• コーディング中の更新履歴は汚くなっても良い。
• リモートのmasterに追随する(時々 and 最終テスト前)：
• masterの更新を取得する。
• $ git fetch origin/master
• masterの更新の内容を確認する。
• $ git log --oneline--prety=medium -10 origin/master
• masterに更新に追随するためにrebaseする。
• $ git rebase origin/master
• 作業を中断して他のブランチに移動する前に：
• すべてコミットする。
• $ git commit
• もしくは、一時保存する。
• $ git stash "コメント"
• 他のブランチから戻ってきたら。
• $ git stash list
• $ git stash pop
• コーディング、テストを終え、他のメンバーに渡せる状態になったら、次の「マージ」に進む。
• マージ
• 新機能の追加など、チーム内部で機能レビューが必要な場合は、ステージング環境にマージ、デプロイ、機能レビューする。
• バグや小さな変更など、機能レビューが不要な場合は、プロダクション環境にマージする。
• ステージング（dev）
• devに移動する。
• $ git checkout dev
• devをリモートと同期する。
• $ git pull origin/dev
• masterに追随するために、rebaseする。
• $ git rebase origin/master
• 対象のブランチに移動する。
• $ git checkout branchname
• devに更新に追随するためにrebaseする。
• $ git rebase dev
• これにより、masterには未適用だがdevに適用されている更新がブランチに適用されるので、ローカルでテストする。 バグ等あれば、ローカルで修正する。
• これによる変更がなかった場合は、ステージングへのマージへそのまま進んで良い。
• devに移動する。
• $ git checkout dev
• devにブランチをマージする。
• $ git merge --squash branchname
• $ git commit -m "コメント"
• リモートにdevをpushする。
• $ git push
• ステージング環境にデプロイする。
• ステージング環境でテスト、機能レビューする。
• プロダクション（master）
• masterに移動する。
• $ git checkout master
• masterをリモートと同期する。
• $ git pull origin/master
• 対象のブランチに移動する。
• $ git checkout branchname
• masterに更新に追随するためにrebaseする。
• $ git rebase master
• ステージングで機能テストしていた場合、devのみに適用されている更新が取り除かれるので、ローカルでテストする。 バグ等あれば、ローカルで修正する。
• これによる変更がなかった場合は、マージへそのまま進んで良い。
• masterに移動する。
• $ git checkout master
• masterにブランチをマージする。
• $ git merge --squash branchname
• $ git commit -m "コメント"
• リモートにmasterをpushする。
• $ git push
• ブランチを削除する（しばらく待ったほうが良い？）。
• $ git branch -D branchname
• リリース
• プロダクションへのデプロイは、責任者が更新内容を確認してから行う。
• masterに移動する。
• $ git checkout master
• masterをリモートと同期する。
• $ git pull origin/master
• 前回のデプロイ移行の、masterの更新履歴を確認する。
• $ git log
• 必要に応じて、前回のデプロイ時との差分を確認する
• タグをつける。
• $ git tag 2012.01.26
• プロダクション環境にデプロイする。