BitbucketとSourceTreeを使った弊社のGit運用指針

こんにちは。オガリア開発チームの粂です。

弊社ではBitbucketとSourceTreeを使ってGitリポジトリを運用しています。他社の取り組みを参考にしつつ、日々試行錯誤しながらではあるのですが、ある程度運用指針のようなものができてきたので、2013年11月時点での弊社のGit運用指針を本記事でまとめておこうと思います。

前提:フロントエンドツールとしてSourceTree、リモートリポジトリはBitbucketを利用する

GitHub Flowを採用する

基本的にはGitHub Flowに則ってmasterブランチとtopicブランチのみで運用しています。

masterブランチに直接pushしない

過去に本ブログでも書きましたが、Bitbucketでは任意のブランチにpushできるユーザ・グループを制御できます(AdministrationのBranch managementから)。
http://tech.oga-ria.com/branch-management-in-bitbucket/

SourceTreeでリモートログインする開発者ユーザはmasterブランチに直接pushできないように設定することで誤ってpushする事故を防ぐようにしています。

masterブランチの削除を禁止する

Bitbucketでは任意のブランチの削除を禁止することができます(AdministrationのBranch managementから)。弊社ではmasterブランチのみ削除できないよう設定しています。

現状masterブランチとtopicブランチのみなので上記のような設定にしていますが、developやstaging/master等のブランチを今後作成することがあればそれらも削除禁止にする予定です。

すべてのブランチのrebaseを禁止する

Bitbucketでは任意のブランチのrebaseを禁止することができます(AdministrationのBranch managementから)。弊社ではすべてのブランチをrebaseできないよう設定しています。

topicブランチを切ったら即pull requestする

こちらを参考にしました。
https://speakerdeck.com/onishi/hatena-blog-development-flow

後述するように、pull request上でコメントのやりとりをしたいので、すぐにpull requestを作成するようにしています。

上記のはてなブログの開発フローに書かれているmaster, staging/master, topic branchを使ったブランチ戦略は弊社でも取り入れてみたいと思いました。

修正に対するコメントはなるべく口頭のみは避けて、pull requestのコメント機能を使う

こちらを参考にしました。
https://speakerdeck.com/ken_c_lo/pull-request-4-designers-githubwoshi-tutapuroguramatodezainafalseitereteibunakai-fa-huro

pull requestのコメント機能を使って、レビューのやりとりをなるべく履歴に残すようにしています。

mergeし終えたtopicブランチは即削除

Bitbucketではpull requestを作成するタイミングでmerge後にブランチを削除するかどうかを選択できます。存在するブランチはActiveなブランチのみである状態にしたいので、mergeと同時に削除するにしています。

pull requestで履歴は確認できるので削除しても特に問題はありません。

topicブランチへcommitしたら即remoteにpushする

SourceTreeを使えば、commitダイアログ画面でPush commits immediately to:xxx というチェックボックスがあるので、基本的にはこれにチェックを入れてcommitするようにしています。

即pushすることで、pull request上で開発の状況が常にupdateされた状態になるよう意識しています。

rebaseは使わない

commitしたら即pushするので、リポジトリの不整合が発生する原因になりかねません。開発チーム内では使わないようにしています。

commit -amendも使わない

commitしたら即pushするので、リポジトリの不整合が発生する原因になりかねません。開発チーム内では使わないようにしています。

その他コミット履歴を書き換えるようなコマンドは使わない

rebaseやcommit -amend以外でもコミット履歴を書き換えるようなコマンドは原則禁止しています。

topicブランチへmasterブランチの変更を取り込む場合はrebaseではなくmergeを使う

こちらを参考にしました。
http://blog.inouetakuya.info/entry/20130602/1370173582

gitのpush.defaultはcurrentにする

SourceTreeであればTools→Options→Gitから設定できます。

こちらを参考にしました。
http://qiita.com/awakia/items/6aaea1ffecba725be601

README.mdもあわせてcommit & pushするように心がける

リポジトリ全体、機能単位でREADME.mdを作成してpushするようにしています。

rebaseを使わないとか、commit -amendを使わないとか、賛否両論あるとは思いますが、現状の弊社チーム内のGitのスキルを考慮に入れつつ、コミットグラフを綺麗に保つことよりも運用のしやすさや事故の発生率を下げることをより重視した結果、このような形になっています。

最後までお読みいただきありがとうございました!

Pocket