リポジトリ×2+pullの運用が良いと個人的には強く思う
gitってリポジトリを分散管理できる。
なので共有リポジトリでもcloneを作ってしまえば、branch作り放題、addし放題、commit作り放題。
それがgitの良いところだと思っている。
でもgitを使って複数人で作業をする時って、実は気をつけないとわけわからなくなる。
というのは、共有するものの単位に自由度が高いから。
相手のリポジトリにpushで押しつける事もできるし、勝手にpullしてきて自分のリポジトリをいじっちゃう事もできる。
きっちり整理しないとどのリポジトリのどのブランチが最新なのかわからなくなる。
そこで以下のようなポリシーのもとでリポジトリを運用すればうまくいくんじゃないかな？と空想した事があるので紹介する。
実際に運用しようとしてあっさり却下されたという悲しいものだけど。
- リポジトリは必ず2つ一組で運用する
- 1つは自身の開発用
- もう1つは自身の開発した内容を他者に公開する用
- 各リポジトリには必ずmerge担当者を立てる
- ま、普通は開発用のリポジトリは自分で管理するよね
- 人と人とのソースのやりとりはpullしか使わない
- 自身の管理する2つのリポジトリ間ではpushを使う
書いてみていまいちわかんない。
図で描いた方がいいんだけど書かない。
流れとしては…
というもの。
何が言いたいかというと、
オレのリポジトリで勝手にmergeしてくれるな
となる。
他者からのpushを禁止するとソースを共有する際のアカウント管理も不要で書き込み禁止すれば良いだけだし、pushする先のリポジトリは1人からしかpushされないので絶対にfast-forwardでmergeが発生しない。
これが一番いいと思う。
さらに最新ソースを集約してビルドする人もこの枠組に当てはめると…
- みんなのビルドしてくれブランチから定期的にソースを集約
- とりあえずmergeしたらcommit作っておく
- ビルドして動作確認して問題なかったらそんで良い
- 問題が起こったら誰のcommitで問題になったのか切り分ける(bisectとか使ったことないけど)
- 問題がなくなったらタグを打っておく
- タグ=HEADをもって安定化していると判断して各自が自身の開発用リポジトリにmergeする
とかいう運用ができる。
この運用にしていても、開発者同士でソースのやりとりはすればいいし、集約ビルド環境に誰がどのソースを入れるのかとかも、当人同士で自由に決められる。
この運用が絶対いいと思うんだけど、会社ではやだって言われた。
で、結局gitでソース共有なんていう運用できていない。
