Skip to content

Instantly share code, notes, and snippets.

@najeira
Last active December 15, 2015 18:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save najeira/66f7801432b7f0223e48 to your computer and use it in GitHub Desktop.
Save najeira/66f7801432b7f0223e48 to your computer and use it in GitHub Desktop.

Git workflow

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/bug159john/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

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/bug159john/fix159 となる。

branchの名前は、各担当者が自分に分かるように自由に命名してよい。

toplevel branch

複数の担当者が共同で使うbranchの場合は、担当者の名前を含めないbranchを作成する。

git checkout -b feature master

このとき、このtoplevelのbranchは、関係する担当者の間で、準masterのように使う。 toplevel branchとmaster間の同期は、随時行っていくこと。

push

作業中のブランチは、定期的にサーバにpushする。 これは他のメンバーが確認できるようにするため、およびバックアップのため。

commit

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

rebase

自分の まだpushしていない branchへmasterの更新を取り込む場合、 rebaseを使ってよい。もちろんmergeを使ってもよい。 自分のbranchなので、どちらを使うかは、開発者が自由に決めてよい。

1度でもリモートにpushしたブランチはrebaseしてはならない!

バグ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

pull request

TODO

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

release

本番へのデプロイやアプリを申請する場合など、リリースのためのブランチを作成する。

git checkout -b release master

このブランチは Hot fix を除いて、更新されることはない。 原則としてmasterからマージして更新していく。

releaseブランチへリリースしたい内容をマージした後は、 masterブランチは次のバージョンに向けて開発を開始してよい。

tag

本番にデプロイする場合など、どのバージョンをデプロイしたか管理しやすくするために、tagを使う。 デプロイを行う前に、tagを作成しておく。

git tag tagname

タグ名の他に、説明を追加したい場合は -a オプションを使う。

git tag -am "詳しい説明" tagname

Links

cybozu.com インフラ開発チームのマニュアル

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment