Q&A
図で表現したい箇所はずれるのでコードブロックで囲みましょう。
バッククォート(Shift+@)3個のみの行でサンドイッチです。
```
d-●-●-●-●-●-●-●-●
└t-●-●-●-●-▲-●-●
└t2-●-●-●-▲-●-●
```
こんな感じ
修正依頼欄だと冒頭のスペースがけずられちゃいますけどね
ブランチの運用？というかどういう感じに作業を進めるべきか皆様のご意見を聞きたいです。
・developブランチ（開発本流）
・feature/testA(画面Aのベース部分を開発)
・feature/testA-2(画面Aの機能を開発するブランチ)
作業手順
・developブランチから「feature/testA」ブランチを切ります。
・「feature/testA」ブランチで画面Aを開発します。
・「feature/testA」ブランチでは画面Aのベース部分のみ開発し、プルリクエストを出しました。
・「feature/testA」ブランチの内容をレビューをいただいている間、画面Aの機能を実装するため「feature/testA-2」ブランチを作成
・「feature/testA-2」ブランチで機能を作成しプルリクエストを出す。
各ブランチの関係
d : develop
t : feature/testA
t2 : feature/testA-2
d-●-●-●-●-●-●-●-● └t-●-●-●-●-▲-●-● └t2-●-●-●-▲-●-●
「feature/testA」はdevelopブランチから切り、「feature/testA-2」は「feature/testA」の内容がないと作れないものなので「feature/testA」から作成。
上記の図で「▲」のところでプルリクエストを出している。
・「feature/testA」はdevelopにマージ予定
・「feature/testA-2」は「feature/testA」にマージ予定
ここで「feature/testA」のレビューが終わり指摘され部分の修正を何個か追加コミットした後developにマージした場合、「feature/testA-2」はマージ先を「feature/testA」から「develop」に変えるべきでしょうか。
それとも、「feature/testA」のレビューが終わってもマージせず、「feature/testA-2」のレビューが終わるまで待ち、「feature/testA」に「feature/testA-2」の内容をマージして「feature/testA」ブランチをdevelopにマージするべきでしょうか？
それともほかにやり方がありますでしょうか。
ブランチ運用などにそれほど詳しくないため知見のある方に意見をいただきたい次第です。
ありがとうございます！
修正しました！
いい感じになりましたね！
ナイス！
rebase でも merge でもどちらでもいい (チームで決めてもいいし、各自に任せてもいい) と思いますが、
・「feature/testA-2」は「feature/testA」にマージ予定
というのがよく分かりません。feature/testA を develop にマージしたら feature/testA は消すのが普通だし、feature/testA-2 は (feature/testA を develop にマージした後に) develop にマージするものとしてレビューするのが普通な気が…。
hoshi-takanoriさん
おっしゃっていることは私もわかります。
「feature/testA」を作成しレビューいただいてdevelopにマージ、その後「feature/testA-2」をdevelopから作成して・・developにマージ、としたいのはやまやまなのですが、レビュー遅く先行して「feature/testA-2」の作業を行いこれも終わってしまった場合、プルリクエストが２つでることになります。この時にどのような運用方法にするのがいいのかなと思っている次第です。
（レビュー急かしたいところなのですがそれができない場合の対応って感じですかね・・・）
確かに理屈通りいかないこともありますよね。レビューは別として、ブランチのマージ方法については、
・feature/testA を develop にマージした後、feature/testA-2 のマージ先を develop に切り替えてマージ
・feature/testA を develop にマージした後、feature/testA を消さずに取っておいて、feature/testA-2 を feature/testA にマージして、feature/testA を develop にマージ
・feature/testA-2 を feature/testA にマージしてから、feature/testA を develop にマージ
の 3 種類が考えられますね。かつ、それぞれ devlop にマージする際にコンフリクトが発生しそうなら一旦 develop を feature/testA または feature/testA-2 にマージして動作確認してから develop にマージすることもありえるかと。
で、どれを採用すべきかについてはチームで決めてくださいとしか。(feature ブランチの develop へのマージがチケットシステムと連動してる場合などは、最初のやつがスッキリする気が…。)
回答1件
0
ベストアンサー
test2はtestが前提になるので、
testが最新になる度に取り込みたいですよね。
mergeはコミット作った日付の早い物勝ちなので、
変な風に混ざってしまいます、困った。
そこで、rebaseを使いましょう。
これで前提ブランチになっているtestAのコミット履歴全てを、
新しい作業ブランチのtestA-2ブランチのコミット履歴の下に滑り込ませる事が可能です。
実際にありそうなケースを想定してコマンドの実行手順としてはこんな感じ
bash
1$ git branch 2 develop 3* feature/testA 4 5# やったあtestAブランチが完成したぞ、プルリクだそう 6$ git push origin feature/testA 7 8# 手待ち時間になるから派生のfeature/testA-2ブランチ作って作業続けるか 9$ git checkout -b feature/testA-2 10$ git add src/awesome.file 11$ git commit -m "fix: testA-2" 12$ git push origin feature/testA-2 13 14# testAのレビューで追加修正依頼が来た 15$ git checkout feature/testA 16$ git add src/awesome.file 17$ git commit -m "fix: testA" 18$ git push origin feature/testA 19 20# rebase使ってfeature/testAに追加されたコミット履歴を滑り込ませる 21$ git checkout feature/testA-2 22$ git rebase feature/testA 23 24# 上にコミット履歴を重ねた≒改ざんしたことになるので、force-pushしないと通らなくなる 25$ git push -f origin feature/testA-2
他の作業者のプルリクがdevelopブランチにマージされて、
今時分が作業中だった場合は、同じようなイメージでdevelopブランチを更新して下に滑り込ませる事はよくやります。
bash
1# 上司: developブランチに他人のプルリクマージしたからrebaseで滑り込ませておいて！ 2$ git checkout develop 3$ git pull origin develop 4$ git checkout feature/testA-2 5$ git rebase develop
こんな感じ
ただし、質問文のケースだとtestAのプルリクが承認されて取り込まれるまでは
勝手にtestA-2だけrebaseで取り込むような事を避けた方が良いかとは思います。
投稿2021/10/19 14:42
編集2021/10/19 14:44総合スコア21596
回答ありがとうございます。
少し気になることがあります。
（あと、基本Sourcetreeを使用しており、Gitコマンドは使用しません。（書いてある内容はなんとなく理解はしているつもりです））
リベースは「履歴を滑り込ませる」作業という認識で良いでしょうか。
リベースという操作を深く理解しておらずあまりしたころがありません。
基本的にブランチの威容を取り込みたいときは「マージ」を使用しておりました。
ですので、回答いただいた内容は下記でも同じことでしょうか？
（コミットの順番の美しさ（見やすさ）は度外視でお願いします。）
「# testAのレビューで追加修正依頼が来た」からの作業となります。
→feature/testAで作業＆コミット
「feature/testAでの追加コミットをfeature/testA-2に反映」
→feature/testA-2にfeature/testAをマージ（追加コミットだけ反映される？）
「developブランチの更新内容も反映させたい」
→一旦「feature/testA」にdevelopブランチ内容をマージ（developの更新分のみ反映される）
そのあとまた、feature/testA-2にfeature/testAをマージ（結果的にdevelopの更新分のみ反映される）
この場合、
feature/testAのレビューが先行して終わりdevelopにマージした場合、feature/testA-2のマージ先をfeature/testAからdevelopに変えても内容的には問題ない？
また、feature/testAとfeature/testA-2がほぼ同時にレビュー終了した場合
feature/testA-2ブランチをfeature/testAにマージすることでfeature/testA-2の実装分のみ反映され、feature/testA-2の対応も入った状態であるfeature/testAをdevelopにマージする、というのも問題ないでしょうか。
コミットに「Merge hoge into hogehoge」みたいなコミットが増えることになると思いますがまあその点は今回は許容ということで。
横から失礼します。自分は、rebase は「ブランチの平行移動」だと思いますが、rebase 中の各コミットでコンフリクトが発生する可能性がある (今回のように同じ画面をいじる場合は特に) と思うので、慣れが必要だし、merge でも全然構わないと思います。(rebase に失敗しても、古い feature/testA-2 の情報は残ってるので、何度でもやり直せるのが git のいいところではありますが。)
あなたの回答
tips
プレビュー
