Q&A
develop から feature/first を切った後に develop が更新されたということだと思ったんですが、違いますか？
gitの使い方が曖昧なので質問させていただきます。
developブランチを切り、feature/firstというブランチを作ったとします。
feature/firstで作業していたら、feature/secondというブランチがdevelopにマージされました。
この場合、feature/firstはどうするべきなのでしょうか？
git pull origin develop で更新すべきですか？
回答3件
0
ベストアンサー
こんにちは。
git pull origin develop で更新すべきですか？
feature/firstをdevelopへマージする前にはタイミングを見計らってそれを行のが一般的です。
文脈的に一人開発ではなく、ベアリポジトリに対して複数の人がプッシュする流れの開発と思います。
その場合、そもそもプルしないとfeature/firstをdevelopへプッシュできません。
プル≒マージ、プッシュ≠マージなのです。
投稿2019/09/05 08:49
総合スコア23272
0
※「feature/second が develop にマージされたタイミングで、feature/first に対して行う git 操作は何ですか？」という質問だと解釈して回答します。
元のブランチとは切り離して作業するために、新しいブランチを作ったのですから、何もする必要はないと思います。
投稿2019/09/05 08:37
編集2019/09/05 23:22
総合スコア6500
はい、その認識です。
質問は「develop が更新された後に、feature/first に対して何か git の処理が必要か？」というふうに解釈しています。
だとしたら、Chironian さんのおっしゃる通り、プルしなければ変更を develop へ適用できません。
質問に「（feature/first の）変更を develop へ適用（マージ）」という前提は書かれていなかったので、そこまでは想定しておりません。
質問内容の解釈は先ほど書いた通りで、それに対する回答としています。
いや、マージしないと考える方が不自然です。
git flow ですよね？
リリースできないじゃないですか。
それ以前に、マージしないということになると、一人で全部開発しなければならなくなります。
ある社員はあるバージョンを作り、別の社員は別のバージョンを作り、それらが独立して開発され、決して交わらないということになると、大変不便です。
この場合、feature は「機能」という意味です。feature/first は一機能、feature/second は別の機能、それらを分担して開発しています。
分担したからにはマージしなければいけません。
マージしなければ、どちらか片方の機能しか持たない製品を二つ作ることになります。
機能ならまだマシで、fix つまり修正ということになると、あるバグが修正された製品と、そのバグは残っているが別のバグが修正された製品と、二つ作ることになります。
ユーザーはどのバグが一番マシか考えて選ばなければいけません。
マージするというのは、複数人数で開発する場合の不可欠な大前提です。
> feature/firstで作業していたら、feature/secondというブランチがdevelopにマージされました。
というニュアンスで書かれており、まだ feature/first は作業中なので、すぐにリリースはしないだろうと推測しました。
その上で、「現時点で feature/first に対して必要な git 操作はないでしょう」という回答をしています。
リリース時期に関係なく、プルはこまめにすべきものです。
git flow は次のような流れで開発を行います。
master ブランチから develop ブランチを切ります。
develop ブランチから開発すべき機能の一つ一つに対して feature/xxx というブランチを切ります。
(xxx は機能を表す名前)
feature ブランチは複数切られ、同時作業できます。
同時に作業するということは、同じファイルの同じ場所を複数人が同時に編集することがあるということです。
feature ブランチは完成したら develop ブランチにマージし、マージしたブランチは削除します。
このようにしてすべての feature を作り終え、develop ブランチにマージし終えたら develop ブランチから release ブランチを切り、リリース作業に入ります。
ですから、develp ブランチにマージされたコードというのは、基本的にはすでに完成し、テストを終え、レビューを通り、責任者がゴーサインを出した、確定したコードということです。
各開発者は、それをなるべく早く手元のコードに反映させなければなりません。
そうしなければ、後で修正に余計な手間と時間がかかることがあります。
たとえば、feature/second で修正された部分と同じ部分を自分も修正したとします。
プルが遅れると、同じ部分を複数人が修正しているのでコンフリクトが発生します。
しかし、自分が修正する前に、修正されたものが既に手元にあれば、それを前提に修正するので、コンフリクトは発生しません。
この回答は全面的に正しいと思います。
分岐と合流までの間に源流側に変更が加わるからこそ「マージ」という操作が存在します。常に最新の源流に合わせなければならないのであれば、そもそもブランチを切る意味が無くなります。
> 各開発者は、それをなるべく早く手元のコードに反映させなければなりません。
もしかしてですが、多数の開発者によって5分に1回程度の頻度で develop へのマージが行われている環境だとしたら、5分に1回作業を中断してローカルの develop をアップデートする必要があると言っていますか？全員の開発者が？
pull をこまめにやらないといけないということには全く同意しますが、develop が更新された場合に「feature ブランチに対して何をすればよいか？」については「何もしなくて良い」が正解です。
なるべく早くというのは、少なくとも自分が編集作業を始める前にはプルしておくべきという意味です。そして、コミットする前にはプルしなければなりません。
ブランチを切る意味が無くなるというのはどういう意味ですか？
全員で develop を直接編集しろと？
「develop から分岐した feature ブランチに対してやること」という問に対して、「develop を常に最新にしてコンフリクトを避ける」と返しているので、それは「常に feature ブランチを最新の develop に追随させる」と言っているとも読み取れませんか？それは常に develop で作業しているものと変わらないことを言っています。
feature ブランチを「切った」以上、それがマージされるまでの間は履歴が独立となるので、その間に develop に何が起きたかを感知する必要はありません。
必要ないとは言いましたが、実務的には感知しておくことでコンフリクトの事前回避などに繋がるという利点はあります。
Git の本質的には、分岐点と合流時のスナップショットに注目していれば事足りる、という主張です。
5 分に 1 回の頻繁な変更がある想定だとしたら、そんな方法で大丈夫ですか？
いくら変更があっても、自分のブランチが完成するまでプルしないんですよね？
各作業者が同じドメインに同じ改修を入れるなんてことをしていなければ大抵大丈夫ですね。
これは極端な言い方ですが、feature ブランチを切ったあとは、develop にいざマージするその瞬間まで、リモートをたった一回 pull する必要性すら存在しない、と主張しても間違いではないはずです。
逆に聞きたいのですが、「feature ブランチで作業中に、develop ブランチに更新が入った」シーンにおいて、「feature ブランチ上でやらなければならない操作」とは何を想定しているのか、具体的に教えていただけませんか？
どのような変更があってもプルする必要はないという意見ですか？
もちろん理想的なコードならそれもできるでしょう。
しかし、現実には一つの機能を追加するのにソースのあちこちに手を加えなければならないのはよくあることです。
自分の機能に影響を及ぼす部分が変更されていて、それをプルする前とした後では仕様が異なるとしてもプルしないのですか？
「どのような変更があっても」というのは一般化しすぎです。
仮に「仕様が変更された」というなら、feature ブランチへの逆方向 merge を行うために pull をします。
それは「develop ブランチに入った変更が feature に影響を及ぼす場合」という特殊な状況ですね。その状況を「確認する目的」で pull する、ということはよくありますが、その度に feature に対して何かすることはないです。
可能であれば、先の確認に対して、何らかの回答が頂けると助かります。
であれば、あなたの意見は「場合によってはプルする」に変更されたことになりますね。
「先ほどの確認」が「逆に聞きたいのですが」のことであれば、答えになっていると思います。
えーと、そうですね。develop を pull することはある。ここはよいです。
しかし、develop を pull することは「feature ブランチに対して何かする」ことには繋がっていないのです。
「feature ブランチに何をするか」については自分は「基本的には何もしなくて良い」という意見ですが、そこについてはどうでしょうか？
feature にしないのであれば、どこにプルするんですか？
ちょっと待ってください。pull の概念について合意が取れていないように思えます。
自分の言う pull は、「リモートに存在する特定の commit オブジェクトと、それに連なる不足分オブジェクトを全てローカルに取得し、リモート追跡ブランチを更新した後、upstream で追従しているブランチラベルをリモート追跡ブランチの対象に向ける」ことを指しています。
噛み砕くと、「ローカルの develop ブランチをリモートの develop ブランチに合わせる」ことだけを指しています。それ以上の操作は含んでいません。
つまり、破壊的変更があった場合には目視のみですませるということですか？
そこまでして feature にプルしてはならない理由はなんですか？
すみません、そもそもの話で申し訳ないですが、あなたの言う「feature にプルする」とは、どのような状況でどのようなコマンドを発行することを言っていますか？前提が噛み合っていないようで、正しく意図を説明できていません。
フェッチしてマージすることです。develop にプルし、develop をマージします。
ああ、理解しました。
あなたの言う「feature にプル」というのは、feature ブランチ上で `git pull origin develop` を行って、origin/develop を feature にマージする、という作業を指していたのですね (解釈が違っていたらご指摘下さい)。
自分の言っていた pull はあくまで upstream の adjustment であって、具体的には develop ブランチ上での `git pull` のことで、feature には特に手を加えないことを指していました。
その上で、自分の意見としては、feature に随時最新の develop をマージすることは必須ではないと考えています。
確かに develop を取り込み続けることでコンフリクトの事前回避や仕様変更による手戻りを減らせる利点はありますが、頻繁に更新される (と仮定) ものを、その都度手を止めて取り込む必要はないと考えます。
何故なら、Git としては最終的に develop にマージされる瞬間においてコンフリクトが存在していなければ問題ないからです。
もちろん、開発に支障が出るほど頻繁にマージする必要はありません。それは大前提です。
支障が出ない範囲なら、しなければならない仕事を後回しにする必要はないし、後回しにしなければならない理由もないはずです。
なるほど。そうですね。
feature の内容にもよるとは思いますが、「機能の追加」を行うブランチが常に最新の develop を取り込むことは「しなければならない仕事」ではないと思います。
分岐して、機能を追加して、develop にマージする。これだけで完了する仕事をしているとき、develop を feature に取り込む作業は最後まで存在しません。
同じコードを同じように変更しまくって、ちょっと目を離すとばしばしコンフリクトが起こるような開発環境を想定するなら、何より早く最新を取り込むことが必須になりますが、そういう話ではないと (勝手に) 思っていました。それはまあ、状況次第ですね。
状況次第であるなら、してはならないという積極的な理由がない以上、するのが正しいと思います。
こちらは個人的な意見ですが、頻繁な取り込みを行うと、基本的に履歴が非常に読みづらくなるため、履歴を追ったり、コードレビューの際に余計な手間が掛かるためやや否定的です。
コードベースがある程度構造化されていて、feature ブランチが文字通り「機能追加」を行っているなら、コンフリクトはそう起こるものではなく、それ単体で履歴が独立していた方が都合が良いです。
むしろ、最終的にコンフリクトが起きたときに「どうしてコンフリクトが起きるような変更が入ったのか」が追いやすくなるところが利点だと思っています。
皆さん回答ありがとうございます。
0
git pull origin develop で更新すべきですか？
git pull origin developで更新するべきだと考えています。根拠は2つあります。
1つ目の理由は, あなたのPull Request時にconflictを予防するためです。仮にdevelopの最新環境に対応しないままPull Requestすると, リモート上でconflictが発生する可能性があります。リモート上でconflictを解消するのは手間がかかる上に変なコミットが乗ってしまうので, ローカルでconflictを解消しておくことが無難でしょう。
2つ目の理由は, developブランチは開発方針として正しいコミットの集まりであるためです。
実際に, A successful Git branching modelの和訳記事では, developブランチは以下のように触れられています。
私たちは、origin/masterブランチのHEADをいつでも出荷できる状態のmainブランチとして扱うことにします。
そして、origin/developブランチのHEADは常に次のリリースに向けた最新版となるように扱うことにします。
そんな中, 仮にあなたがdevelopをマージしないままfeature/firstを編集してPull Requestしたとしましょう。そこで, 別のPull Requestで同じ部分がマージされていた場合, その部分はdevelopの指針に背いているためrejectされる可能性があります。rejectされると時間と労力が無駄になるのであまりオススメしません。(私はこれをやってduplicateのラベルを貼られ悲しくなったことがあります)
以上の理由から, 私はgit pull origin developで更新するべきだと考えています。
投稿2019/09/06 02:03
総合スコア106
回答ありがとうございます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2019/09/10 03:55