0
1
テーマ、知りたいこと
今まで、一人でコードを書いてきており、チーム開発に興味があって今GitHubのブランチの運用について勉強しています。
チーム開発時に、branchをfeature, dev, mainなどそれぞれの役割で区切り、リリースや製品のバージョンを管理することになるかと思いますが、その際コード自体はどのように変化するのか、ご教授いただけませんでしょうか。
例えば
簡単のため、mainは以下の1ファイルだけだったとして、
python
1<hello.py> 2print(Hello World)
開発者はmainからブランチを切って開発するとします。
feature branchで、
python
1<hello.py> 2print(Good Morning Hello World)
プルリクエストを送る
dev branchで、
python
1<hello.py> 2print(Hello World !!!!!!)
プルリクエストを送る
と開発し、Margeされれば、最終的なmainが
python
1<hello.py> 2print(Good Morning Hello World !!!!!!)
となるのでしょうか？
また、devの開発が終わる前に、featureがマージされると、devの開発者はfeatureの変更分に対してどのように対応するのでしょうか。
（実際の開発ではdevが参照したい関数をfeature branchを開発していた開発者に変更されてしまうなど想定できると思いまして。。）
基本的な質問かもしれませんが、ご経験のある先輩プログラマーの方々のお知恵をお借りできればと思っております。よろしくお願いいたします。
回答3件
#1
総合スコア14671
投稿2024/06/21 06:12
gitやgithubは魔法の杖ではありません。
最終的なmainが「print(Good Morning Hello World !!!!!!)」となるのでしょうか？
勝手にそうなることはありません。
ブランチの仕組みやワックフローなどは、1つのプロダクトに対する複数のフィーチャー(機能)の開発をやりやすくするための仕組みであり、開発者やチーム間での事前の調整が不可欠です。
先の例で、printが何を出力とすべきかは、本来であれば、修正する前の設計の段階で調整されて決定されるべきです。
また、その調整が漏れていたとしても、マージの段階でgitによりコンフリクト(衝突)が検知されて、どのように落すのかを関係者で狭義して決定することになるでしょう。
devの開発が終わる前に、featureがマージされると、devの開発者はfeatureの変更分に対してどのように対応するのでしょうか
これについても同様です。これらのブランチの運用をどのようにするのかを、開発チームで決定して運用する必要があります。
運用例としては、devブランチへの変更は直接ではなく、必ずfeatureを切って行ない、マージはそのfeatnureの正常性が確認できた上で、マージするような感じですかね。 (なので、 「devの開発が終わる前に、featureがマージされる」のはあたりまえと捉えます)
#2
総合スコア92
投稿2024/06/21 07:05
発想としては近いですが、重要なのはGitは行ごとに履歴を管理するということです。
今回のmainの初期状態、これが「コミット１」です。
python
1Hello World! // コミット１の行１ 2My name is A
featureブランチで変更しました。これをコミットヒューチャー１と呼ぶことにします。
python
1Good Morning, Hello World! // コミット１の行１を変更した 2My name is A
この後、コミット１から派生したfeatureの行1の変更をマージした時、「コミット１の行１」が変更されます。
python
1Good Morning, Hello World! // コミットヒューチャー１の行１ 2My name is A
その後、devブランチの内容をマージしようとした場合、
python
1Hello World!!!!! // コミットデベ１の行１ 2My name is A
devブランチは元のmainブランチの行1、つまり変更前の「コミット１の行1」から変更を行ったことになるので、当然「コミット１の行１」に変更をしようとします。
しかし「コミット１の行１」はfeatureをマージした時に既に変更され、現在のmainの行１は、「コミットヒューチャー１の行１」になっているはずですね。
ですので、コンフリクトが起きます。
python
1Good Morning, Hello World! // コミットヒューチャー１の行１ ← コミットデベ1の行1はコミット１に入れたいのにもう存在しない 2My name is A
このときmainブランチの心境は、
「ヒューチャーさんからもデベさんからも同じ行の変更が来ちゃった。ヒューチャーさんの方が早かったけど、デベさんはヒューチャーさんの作業内容を知ってるとは限らないよね？デベさんのコミットでヒューチャーさんの行１を上書きしてもいいのかわかんない」
です。
ですので、マージしようとした人間に、どっちが正しいか教えてくれとコンフリクトエラーを出します。
これが、featureが行1、devが行2を変更していた場合は、おそらくあなたの想像通りの動作になります。
同じ行でないので、mainの行1はfeatureを取り込み、
mainの行2はdevを取り込む形です。
python
1Good Morning, Hello World! // コミットヒューチャー１の行１ 2My name is A!!!!!! // コミットデベ１の行２
これが、gitは行ごとに履歴を管理するということです。
#3
@TakaiYさん
ご回答ありがとうございます。なるほど、コンフリクトが起きないように事前にどこをどう修正するのか設計検討済みの形で開発者が開発をを行うのですね。自分の持っている書籍では「ブランチ管理がチーム開発にとって重要」のような書き方だったので、要領を得ていなかったです。ありがとうございました。
@sk_さん
実例つきの丁寧な回答ありがとうございます。おかげさまで、なんとなく頭の中でGitHubのブランチの管理がイメージできました。コンフリクトについても理解してなかったので、混乱していた部分がすっきりとした気がします。ありがとうございました。