理想的なGitフローを目指したい -1-

サークル活動なんかでチームプロジェクトをする機会があり、そこでGitを活用したので、 Gitフローに関して会得したこととか分かったことのメモ。

はじめてのチームプロジェクト with Git

あるみに初のGitを活用してのチームプロジェクト。

まあ、燃えた。よく燃えました。

かつ、おそらく結構な迷惑をかけたかもしれないし、その割に貢献度すら薄いという感じだった気がするね……

自分が弱いのはもちろんのこと、他のチームメンバーについてもGitフローにはかなり苦しんでいた。

具体的に言えばコンクリフト地獄だった。

そんな反省を活かし、ほどなくしてGitフロールールが決められた。

失敗から学んだ「僕たちの考えた理想的なGitフロー」を自分の理解の及ぶ範囲でまとめておくという話。

お前は何も考えてねぇだろ

理想的なGitフロー

詳細な用語についても、自分の理解が怪しいのでいくつか整理してまとめたいなあ

あと、1人1ブランチということでfuture使ってないです（多分そういうことだよね？）

1.ブランチルール

プロジェクトにおけるブランチの使い分けをしっかりする。

「リモートリポジトリ」と「ローカルリポジトリ」でどんなブランチをつくって、どのように反映、統合（マージ）させるかが重要。

リモートリポジトリ

• master :もともとある。製品として完成した/リリース可能なバージョンになったときにのみ、developブランチをマージしてくる。

• develop : 開発ブランチ。masterの一つ下層。ローカルリポジトリの開発状況であるdevelopブランチがプッシュされる。

• future :作業ブランチの親？ブランチ。特定の作業を複数人で行う場合、開発ブランチの一つ下層につくる？。今回は考えていない。

ローカルリポジトリ

• develop :ローカルの開発ブランチ。各人はここから作業ブランチをはやし、作業ブランチでの作業内容が完了すればそれとマージする。マージの前にリモートリポジトリのdevelopと状態を同じにする。→コンクリフト最前線。

• ○○（作業ブランチ） :作業ブランチ。名前は任意。基本的にここにしかコミットしない。futureブランチがあればその下にできる。

2.操作手順

2-1.リモートリポジトリのクローン

SourceTreeとか黒い画面とか何とかで、リモートリポジトリをクローンし、ローカルリポジトリを作成する。

2-2.作業

developをチェックアウトし、作業ブランチを作成。名前は、作業内容に合わせて任意につける。

あとは作業に入る。

2-3-1.コミット（ローカルリポジトリ）

作業が進んだら自由にコミットしたりして作業ブランチを進めていく。

作業ブランチの作業内容が完了したら、ローカルのdevelopに反映（マージ）させるのだが…

2-3-2.マージ前の準備（ローカルリポジトリ）

コミットするその前に、ローカルのdevelopに、リモートのdevelopをフェッチして、変更等があるか確認する。

変更があれば、developをチェックアウトして、既に進んでいるリモートのdevelopをプルする。

2-3-3.マージ（ローカルリポジトリ）

リモートのdevelopとローカルのdevelopの内容が同じになったところで、今度こそ作業ブランチをマージ。

developをチェックアウトしたまま、作業ブランチを選択してマージする。

もし自分が変更した場所が、誰かによっても変更されていた場合、コンフリクトが生じるので、頑張って解決する。

2-4.プッシュ（リモートリポジトリ）

作業ブランチがマージされたローカルのdevelopをリモートのdevelopに反映（プッシュ）する。

※↑ではじめて、作業者は全体で共有されているプロジェクトに対して変更を加えたことになる。

（よほどのことがない限り、ここで問題は生じないはず、もし生じたとすれば、これまでの工程でミスをしたか……）

（不幸な偶然が生じたということになると思う。）

2-5.作業完了

というわけで、作業状態が反映されたため、一巡終わり。また2-2「作業」に戻る。

2-6.バージョンアップ

開発ブランチdevelop（リモート）がどんどん進行し、完成/リリース出来る状態になったなら、

リモートのmasterに、同じくリモートのdevelopを反映（マージ）する。

masterをチェックアウトして、developを選択し、マージ。閉廷。

ちなみに

2-3-2と2-3-3間におけるローカルのdevelopをリモートのdevelopに合わせ、マージする工程は、

フェッチした時点でプルしてこなくても見えるようになった変更後のdevelop選択してマージすれば良かったりする。

このGitフローにおけるポイント

基本的に、作業は↑の2-2～2-5を繰り返して行くことになっていく。

このフローで大事なポイントをあげると、

• ローカル内で共有の準備を全て終わらせておくこと
• 個人の作業ブランチはリモートにあげたりしない
• 初心者でも比較的統合の様子が分かりやすい？

かな？

共有の準備やコンクリフトの解決までローカルでやっておけるのはなかなか良い気がする、

なんというか、個人でやるべきことが明確化しているし、たぶんコンクリフトが減る。

個人ブランチをあげちゃうとかいう行動もこの過程ですることもないし、リモートリポジトリが下手に荒れることもない気がする。

まあ、このルールで決めておけば比較的初心者でも分かりやすい感じがする。

詳しい説明をしようと思ったけどうまく筆が進まないので一度切っていつか続きを書く。

別にそんなことしなくても？ってことだらけだったりして……？

あくまで初心者の自分は分かりやすかったしうまくいったのでとりあえずメモ。