2017/10/19

[git]forkして作業するか、forkせずに作業するか (1)

githubでソース管理することを考えている。
まだ一人なので何とでもなっているのだが、そのせいでチーム開発向けのルールが考えついていないのを、なんとかしようとしているのだ。


いつもは、なるべく作業前にブランチを作って、そこで作業して、終わったらpull requestしてマージしてもらう、というやり方にしている(一人しかいないので、自作自演なんだけどね)。


まず、各作業をする人が同じリポジトリを使った方が良いのか、リポジトリを各人で作ってforkした方が良いのか、というので悩んでいる。

最初は同じリポジトリで試して、今は別アカウントでforkしている。
前者が使えるのは、リポジトリへのアクセス権をもらった場合(organizationに追加してもらうなど)だけのようだから、混ぜてやるなら後者しかないか。

前者の利点は、forkしていないから、git pullなどとすれば最新版がmergeできるというところか。
後者だと、相手のリポジトリにmergeしてもらったあと、fork先からのmergeという手段になってしまうと思うのだ。
GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita

今はそれでやっているのだが、けっこうfork先からのmergeを忘れてしまう。。
私が悪いと言えばそれまでなのだが、なまじどちらにも同じ権限を持っているだけに、どっちのリポジトリにマージしたのか忘れてしまうこともあった。

そのちょっと前までは、forkしたリポジトリでブランチを作って、fork先にpull requestしてmergeして、fork先からfork元にpull requestする、という2段階でやっていたのだが、さすがに面倒だったのでやめた。
githubでも、pull requestすると、最初にfork元が候補に出てくるから、直接やる方を推奨しているんじゃないかと思っている。


書いていて気付いたが、組織内であればforkさせる理由はあまりないか。
間違ってmainlineを直接編集してしまうという心配はあるのだが、それを避けたければREAD権限にして...forkしてpull request出すのが安全なのか?
branchにprotectをかけるということができるようだから、mainlineだけ保護してしまえばよいのかな?


しばらく、protectして使ってみて、また考えよう。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。