gitのワークフロー(簡易版)の手順書


はじめに

git-flowみたいな本格的なワークフローをやりたいけど、
でもその学習コストは時間がないし、かといって、gitもちゃんと運用したいし…
みたいな、 簡単にチーム開発のgit運用をしたいというチーム向けの手法です。

僕自身は別に経験があるエンジニアではないので、これが適切かどうかは判断しかねますが、
短期間でとりあえずリリースするだけみたいなチームには向いていると思います。
(数週間とかの単発プロジェクトとか)

全体像

手順

元になるプロジェクトファイルをリモート上に作成

チーム開発の起点になる元のファイルを最初に作成し、

リモートレポジトリに予めpushしておきます。

自分の開発用リモートブランチを切る

リモート上にプッシュするブランチは、masterではなく、自分専用のブランチです。

ここでは、masterからdev_omoriを作成しておきます。

ローカルをgit管理する

後ろのステップでgit cloneコマンドを最初に使うので、git管理を先立ってしておく必要があります。

自分の作業ディレクトリに進んで、

git init

をしてください。

git pullで元になるプロジェクトファイルをローカルにコピー

元になるファイルをリモートレポジトリ(GitHub, bitbucketなど)に置いている前提です。

git remote add origin url
git pull origin master

でそのレポジトリをローカル(のmasterブランチ)にコピーしてきます。

※訂正171226
当初、pullではなくcolneで書いていましたが、cloneすると別プロジェクトということになってしまうので、pullに訂正しました。

ローカルでもmasterから自分の開発用ブランチを切る

リモートと同様、自分の開発用ブランチを別で作ります。

cd testApp # クローンしたプロジェクトのフォルダに移動
git checkout -b dev_omori

以上で、リモートのmasterと同じファイルが、

  • リモートのdev_omoriブランチ
  • ローカルのmasterブランチ
  • ローカルのdev_omoriブランチ

の三箇所に作成されている状況になります。

自分の開発用ブランチで開発を進める

キリの良いところまで開発したら、できるだけこまめにコミットします。

git status # 変更されたファイルを確認。必要ならgit diffも
git add .
git commit -m "コミットメッセージ"

皆と共有出来るまで開発が進めば、次に進みます。

自分のリモート開発用ブランチにpushする

ローカルで開発を進めた内容は、一旦リモートの自分の開発用ブランチにpushします。

git push origin dev_omori # 誤ってmasterにpushする恐れがあるので、追跡ブランチの設定をオススメします。

プルリクエストを投げる

チーム開発の体制にもよりますが、通常はコードレビューをしてもらうため、

masterへのマージの前に、誰かにプルリクエストを投げて校閲をします。

bitbucketでは、以下の通りです。

レビュワーがプルリクエストを承認

レビュワーに指定された人は、サイドバーでプルリクエストを選択した画面で、

リクエストの一覧が見られます。

クリックして詳細を確認し、内容に問題がなければ、承認の上、マージを行います。

(詳細は割愛)

ローカルのmasterブランチに最新状態をpull

プルリクエストの承認が降りれば、自分の開発した部分および、他のチームメンバーの開発部分も含めた最新の状態がリモートのmasterに反映されています。

この最新状態から開発を進めるため、自分のローカルのmasterブランチに反映させます。

git checkout master # マージ先はmasterブランチです。
git fetch origin master
git merge origin/master # git pull origin masterでfetchとmergeを同時に実行できますが、一般的には分ける方が良いみたいです。

開発ブランチにも最新状態を反映する

masterに反映された最新の状態を、開発用ブランチにも反映します。

git checkout dev_omori
git merge master

問題がなければ、これで完了です。

後は、開発して、リモート開発用ブランチにpushして…と繰り返しになります。