gitを運用する上の問題
俺はgitを完全に理解している。だが俺以外のメンバーはgitを理解していない。
理由は単純、gitは難解だからだ。
そういうときに「勉強しろ！」というのはプロとしての「怠慢」なのである。
どうするか
gitは諦めて前時代的な管理方法 (RCSやSVN) を使うか？それはあり得ない。1
極めて単純化した運用を練っておくことでgitという難解なツールを使ってもらうのである。
運用としてはGitHub-Flowに近いものを使います。git-flowなぞ高度なことさせられません。
ブランチの種類
- featureやfix: トピックブランチ
- develop: デプロイ可能な開発用ブランチ
- master: 製品となったコードの格納先
各ブランチは複数持つことを許容します。feature/new-buttonやdevelop/開発1、master/お客さんA みたいな。
開発中の作業として頼むサイクル
- ソースコードの修正作業が発生する（機能追加やバグ修正）
git checkout developgit pull-
git checkout -b feature/hogeまたはgit switch -c feature/hoge - いろいろソースをいじってもらう
git add .git commit -m "hogehoge"-
git push -u origin feature/hogeまたは事前にgit config push.default currentを仕込んでおいてgit push - GitLabやGitHubとかでMR、PRしてもらう。
- MRやPRを承認してもらう。
改めて見ると長いですね。大変だ。これを無意識にやっている方々は偉大ですね。
あきらめたこと
- 作業単位にコミットを分けること
- やるに越したことはないが分けるために頭や時間を使うくらいなら分けなくてよい。
問題
もし、自分の作業中に他人の変更がdevelopに発生した場合、適宜リベースするか？
それともdevelopを作業ブランチにmergeしてもらうか？という問題がある。
作業内容を見た感じほぼ同じじゃね？となるが、作業者が何をどこにマージするのかによって難易度が変わる。
developへリベースする場合
作業のフローとしてはこんな感じ。
この場合、developの最新版に対して自分の差分をマージすることになる。
git pull origin developgit rebase origin/develop- 「自分の変更に対して」コンフリクトがあったら解決し、
git rebase --continue git push -f
developを作業ブランチにmergeしてもらう場合
developのmergeは他人の変更を取り込む必要が発生する。他人の作業は理解し難い（したくない）。
この場合、古いバージョンのdevelopに対して自分の変更がある状態に加え、developの最新版をマージすることになる。
作業者の負担が多くなると思われる。
git pull origin developgit merge origin/develop- 「他人の変更に対して」コンフリクトがあったら解決し、
git merge --continue git push
つまり
手順書を書いて、rebaseさせよう！ということ。おわり。
-
SVN派の皆さんすいません。 ↩