新しい開発者はブランチのマージについていくことができません

私は新しい開発者です-これが私の最初のプログラミング職です。

私の問題はこれです：私たちは使用しますgit-私はブランチからブランチを切り取り、develop割り当てられたマイナータスクの作業を開始します。私は経験が浅いので、とても遅いです。ブランチをdevelop他のブランチにマージする準備が整うまでに、多くの変更を行って競合を解決するのは圧倒的です（実際、作業を破棄してタスクをやり直すのは簡単なようですが、もちろん持続可能なソリューションではありません） ）。

どうすればこれを克服できますか？「コーディングが上手」以外の方法を使用できますか？私は来週、これを上司に報告するつもりです。

ブランチで行った変更がdevelopその間にブランチで行った変更に近い場合、つまり、あなたとあなたの同僚が同じコードの同じ行または隣接する行を同じファイルで変更した場合、マージの競合が発生します。

そのため、マージの競合の可能性を減らすために、その間に同僚が変更する行を少なくするように、以前にマージを試みるか、自分で変更する行を減らすことができます。

自分で変更する行を減らすには、必ずタスクに関連する変更のみを行ってください。

目標を達成するためにさまざまな方法で実験する必要がある場合、実験によっては実際に変更する必要のない行を変更した可能性がありますか？マージする前にこれらの変更を元に戻します。

できるだけ少ない行を変更するのに役立ついくつかのGitコマンドもあります。

• git diffそしてgit diff --staged、あなたが変更された行を確認します。
• git add -p 変更をファイルに追加するだけです。
• git commit --amendそしてgit rebase -iあなたは既に他のGitリポジトリにそれらをプッシュする前に、ローカル機能ブランチで行われたコミットを微調整します。

（できるだけ数行を変更すると、それが簡単にあなたの作業を確認するかのようなコミットの間の違いに取り組むツールを使用することができますgit cherry-pick、git rebase、git bisect、とgit blame。）

ただし、マージの競合の可能性を減らしても、マージの競合が発生する場合があります。ですから、彼らを恐れずに、対立を解決する方法を学んでください。

gitを使用していると思います。もしそうなら、git rebase -i（-iインタラクティブを意味する）を利用してください。開発ブランチに対してブランチをリベースするために、毎日のタスク（必要に応じてさらに頻繁に）を行います。これにより、機能のブランチを最新の状態に保つために、毎日（少なくとも）徐々に変更が行われます。毎日のリベース中に競合が発生した場合は、チームで誰が何に取り組んでいるかについて話し合う必要があります。

毎日実行する場合、おそらくインタラクティブな部分は必要ないでしょう。ただやらせてください。

私はかなり経験豊富な開発者であり、新しいプロジェクトを理解するのにかなりの時間がかかります。あなたの場合、同じプロジェクトで同時に複数の人が作業しているように聞こえます。そのため、非常に大きなプロジェクトか、急速に進化している新しいプロジェクトのどちらかです。どちらの場合でも、フローに入るのに数ヶ月かかる場合でも心配しないでください。プロジェクトを2週間または3週間切り替えてから切り替えた場合、100％自分で書いたプロジェクトに完全に「戻る」には数時間（または1〜2日）かかります。

要するに、今は遅くなることを心配しないでください。良くなる方法は練習を続けることです。理解できないプロジェクトの側面について他の開発者に尋ねることを恐れないでください。

編集：

またはを使用しますmerge。それもオプションです。したがって、上記は次のようになります。「git rebase -i（-iインタラクティブを意味する）またはgit merge」を使用します。どちらを使用するかは、チームの他のメンバーと話し合ってください。彼らはどちらの方法でも強い好みを持っているかもしれません（持っていないかもしれません）。一部の人々が強い好みを持っていることは明らかです。

これは、会社側の悪いソフトウェアエンジニアリングの兆候かもしれません。相互依存関係が多すぎる、機能が重複する別の問題、間違った順序で問題に対処しようとすると、説明している状況が発生する可能性があります。develop開発中に定期的にブランチにマージすることをお勧めします

受け入れられた答えは、技術的な「Gitをより良く使用する方法」の性質であり、これはエンジニアリングやツールの問題というよりもチームの問題だと思います。

多くのマージ競合が発生している場合、それはあなたとチームの他の誰かがお互いのつま先を踏んでいることを意味します。
あなたまたは彼らは、コーディング中に個人的なスペースを開発し、すでに忙しいエリアでの作業を避けることを目指してください。

私のチームでは、高度なタスク所有権を目指しています。
私は通常、一度に2つまたは3つのファイルの完全かつ完全な所有権を取得し、せいぜい1〜2日間、ブランチでそれらに取り組みます。
通常、他の誰かがそれらのファイルに触れた場合、それは自分のタスクに絶対に必要な場合のみです。通常、同じタスクブロックでは一緒に作業しません。

大量にマージする必要があることがわかった場合は、すべてのチームコードが1か所にあるか（それ自体は避けるべきことです）、またはすべてのタスクがあります。

とはいえ、新しい開発者としては、おそらく、あらゆる種類の再構築を実施、要求、または実際に提案する立場にないでしょう。
私が期待しているのは、あなたのタスクが、チームへの参加を容易にするためにあなたのスキルレベルで合理的に近づきやすい「ロープを学ぶ」ものとして割り当てられていることです。それらはおそらく、同じエリアでまだ働いている同僚のタスクからされているため、マージの競合が発生します。
これに対する解決策は、それをプラグインして問題を解決し、可能な限りマージの競合に対処し、あなたが最善を尽くしている限り、心配することはマネージャーにあるあなたの進歩。
あなたが行くと、より速く、より自信がつきます。

マージについて最も重要なことは、長く待つほど痛みが増すことです。そして、問題は線形以上に大きくなります。3倍の紛争は9倍の仕事です。いくつかの戦略があります：

開発ブランチが変更されるたびにマージするので、常に近くにいて、多くの競合が発生することはありません。

時間がかかる場合は、ほとんどの時間を変更内容の把握に費やしてから、変更の実装に少し時間を費やしていることが原因の可能性があります。その場合は、実際のコード変更を開始する前に開発ブランチとマージしてください。

競合を避けるための戦略について同僚と話します。2人が同じコードを編集すると、競合が発生します。同じファイルだけでなく、同じコード。したがって、新しい関数functionAが必要であり、新しい関数functionBが必要です。また、同じファイルの最後にそれを追加すると、競合が発生します。別の場所に追加しても、競合はありません。論理的に属するファイル内の場所に両方を追加した場合、競合しない可能性があります。

競合がある場合は、優れた差分ツールを入手して、マージ前の開発ブランチ、マージ前のコード、元のコード、およびマージされたコードを比較し、手作業でマージできるようにします。

最悪の場合：作業を捨てるのではなく、適切なdiffツールを使用して、行った変更を正確に見つけ、開発から再度分岐し、再入力する代わりに手動で行ったすべての変更を適用します。

ブランチを開発にマージする準備が整うまでに（エンファシスマイニング）

での競合の処理git mergeは、多くの場合よりも簡単ですgit rebase。Gitマージでは、一度に変更されたファイルのリスト全体を見ることができます。他の同僚によっていくつコミットが行われたとしても、一度マージする必要があります。リベースワークフローを使用すると、同じ競合が何度も発生する可能性があり、手動で確認する必要があります。13番目のコミットを修正して、トンネルから光が見えないように感じることができます。

私の経験では、繰り返されるリベースの競合を単純に解決しようとしたときに、誰かの変更を失うか、コンパイルさえもしないアプリケーションを使用してしまいました。多くの場合、私と同僚は多くの作業を行いましたが、競合を繰り返す複雑さに圧倒され、リベースコミットを数回行った後、以前の作業を中止して失わなければなりませんでした。

いくつかのテクニックをお勧めしますが、それらはタスクを自動化するよりもマージを簡単にするのに役立ちます。

• リソース/言語ファイル。あなたが持っている場合は、添加剤のリソースファイルへの変更を、あなたは簡単に思い出すことができるようにあなたが常にファイルの末尾に移動することを確認してください、あなたに対する変更他人 "変更を。変更を下部にコピーして貼り付けるか、競合マーカーを削除することができます
• 行う。そうではありません。絶対に。RE-フォーマット。あなたもあなたの仲間の開発者も、毎日の作業中に「大規模なコードの再フォーマット」を実行してはなりません。コードの再フォーマットにより、競合管理に過剰な数の誤検知が追加されます。コードの再フォーマットが可能
  • 自動ツールを使用するとすぐに、たとえばすべての開発者がすべてのコミットで増分的に（たとえば、Eclipseには保存時に再フォーマットするオプションがありますが、vanilla Visual Studioにはありません）。絶対にすべての開発者は、IDEで使用されるフォーマットファイルにコード化された同じコードフォーマット標準を使用する必要があります。あなたにアイデアを与えるために、それが4つのスペースまたは2つのタブである場合、それは重要ではありませんが、誰もが同じものを使用する場合、それは本当に重要です。
  • リリース直前、チームリーダー。人々がブランチで作業していないとき、つまりブランチする前に「コード再フォーマット」コミットが発生すると、物事が簡単になります
• 同僚間の仕事の分割を確認します。これはほとんどのエンジニアリングが来る部分です。他の回答で指摘されているように、異なるタスクを行う複数の開発者が同じリソースに触れる必要がある場合、それは設計臭です。並行開発者ごとにどの部分を変更するかについて、チームリーダーと話し合う必要がある場合があります。

また、私のチームのGitワークフローにはいくつかの悪い習慣があります。多くの場合、人々は自分のブランチに過剰にコミットしています。個人的に、開発者が「修正」というラベルの付いた10〜20のコミットを追加し、それぞれが1行または2行をコミットしているのを目撃しました。私たちのポリシーでは、コミットにはアイデアを伝えるためにJIRAチケットのラベルが付けられています。

@JacobRobbinsはgit rebase、毎日のタスクを作成することを提案しています。彼のアプローチを前進させたいと思います。

まず、コミットの数を少数に減らすために、rebaseを1回使用します。そして、元の開発ブランチのみにリベースします。これは、分岐元のコミットです。一握りと言えば、3または4（たとえば、すべてのフロントエンド、すべてのバックエンド、すべてのデータベースパッチ）または人間が理解できる数字を意味します。それらを統合したらfetch、アップストリームブランチ上でリベースを使用して作業します。これにより、チームが独自のアプローチを検討しない限り、競合からあなたを救うことはできませんが、あなたの人生の痛みは軽減されます。

特定のタスクについて追加の質問がある場合は、Stackoverflowで検索して質問してください。

[編集]ノーフォーマットおよびボーイスカウトルールについて。私が意味しているのは、あなたが触れていないコードを含むソースファイル全体をゼロからフォーマットする作業であることを強調するために、RE- フォーマットを少し言い換えました。常に独自のコードをフォーマットするのとは反対に（完全に少年のように）、IDEの機能を使用してファイル全体を再フォーマットするために、私を含む多くの開発者が使用されます。他の人がファイルに触れると、影響を受ける行の内容とセマンティクスが変更されていなくても、Gitはそれを競合と見なします。非常に強力な言語認識エディタのみが、競合がフォーマットにのみ関連していることを示唆し、最適なフォーマットのフラグメントを自動マージします。しかし、私はそのようなツールの証拠を持っていません。

結局のところ、ボーイスカウトルールは、他の人の混乱をきれいにすることを義務付けているわけではありません。ただあなたのもの。

まず、変更を破棄することを考えないでください。マージプロセスを学習する機会が失われます。

第二に、競合の原因となっているファイルで作業した人を見つけます。履歴を見ることができます。その人と話し、それらのファイルの競合を解決します。他の競合についても同じことを行います。

競合が多すぎる場合、あなたのタスクはマイナーなものかもしれませんが、反復的です。パターンを見つけてください。これは、Git UIクライアントツールによる競合の解決に役立ちます。TortoiseGitを使用します。マージに役立ちます。

そして、将来的に回避するために、

• 開発ブランチを機能ブランチに定期的にマージすることは非常に良い習慣です。

• CIを有効にしている場合は、CIツールがブランチビルドを提供するかどうかを確認してください。これは、機能ブランチで行うすべてのチェックでビルドする必要がありますが、マージ開発ブランチの後です。

開発ブランチから定期的に（毎日）コマンド 'git fetch'（git pullではなく）を実行する必要があります。これにより、他の人が変更をコミットし、変更をブランチに統合しようとせずに機能ブランチに持ち込みます。

これは、あなたの会社が独自の基準を持っているか、この問題を処理する方法を推奨している可能性があるためです。それは非常に一般的です。来週まで待たずに-今すぐプロセスを見つけて、プロセスをテストできるように、些細な作業（コードのフォーマットやコメントの追加など）をコミットできるかどうかを尋ねます。

明らかに最初にすべきことは、少なくとも困難な競合につながるような方法で、複数の人が最初に同じファイルで作業することを避けることです。適切なコード形式が使用されている限り、列挙に物事を追加しても問題ありません。さまざまな方法で制御フローを変更し、コードを移動することは非常に難しいです。それでも、これは避けられない場合があります。本当に複雑な競合を解決するときは、質問する必要があります。

とはいえ、定期的に開発にマージ/リベースすることを推奨する多くの回答があります。私はそのようなアドバイスについてはあまり熱心ではありません。この時点での目標は、紛争解決プロセスをできるだけ簡単かつ安全にすることです。そのプロセスで非常に役立つことの1つは、新しい機能の一部である新しいテストを含め、できるだけ多くの回帰テストをすぐに利用できるようにすることです。ブランチを開発と非常に定期的に同期すると、実際に機能の実装が半分完了している間、必ず競合を解決しなければなりません。そして、それは、あなたがそれをやっていなかったので、コードが何をすべきかを理解しようとすることははるかに困難になることを意味します。マージを試みる前に、ブランチが一貫した変更単位であることを確認してください。さらに良いことに、

私は、おそらく別の質問のために、マージよりもリベースのメリットに入らないようにしました。この文脈では、ツールは実際には重要ではありません。

ブランチをマージして開発を再開する準備が整うまでに、他のブランチが非常に多くの変更を行っているため、競合を解決するのは圧倒的です

これはペアプログラミングの理想的なシナリオのようです！

利点と基本的なアプローチに関する詳細情報：https :
//gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

自力で作業することで、時間の経過とともに自然にスピードアップしますが、その時が来るまで気が遠くなることがあり、時には長引くこともあります。また、人々は常に追いつくように圧力をかけられたストレスの多い環境にいるとすぐに学ぶことができますが、一定の圧力の下でよく学ばない人は妨げられます。

自分でブランチに取り組んで、明らかにあなたよりもはるかに速い他の開発者に遅れを取ろうとする代わりに、代わりに別の開発者と直接（同じPCで）作業します。これにより、すぐにアドバイスが得られ、おそらく高速化する方法などのヒントが得られます。

ペアプログラミングは一部のプロジェクトでは常に意味をなさないため、プロジェクト内の特定のコードに最適なアプローチを考え出すことができます。 （優れた開発者である限り、経験は必ずしも優れた実践方法を使用することを意味しません）。

より速く、より経験豊富な開発者と一緒に座っていると、次の方法で支援できる可能性があります。

• 経験豊富な誰かと作業すると、単独で作業するのではなく完了時間が長くなるため、マージの競合が減少する可能性があります
• 彼らはあなたに教えているので、彼らは一人で働くよりも遅くなる可能性が高いので、まだいくつかのマージ競合があり、経験豊富な誰かと一緒に作業することができるので、おそらく時間を節約するなどのヒントを拾います
• 潜在的なトリックと高速化の方法を確認するのに役立ちます（ただし、遅いとは、単に優れたプラクティスではなく単に経験が不足することもあります）
• 意味がわからない場合や100％明確でない場合にすぐに質問できる
• 1対1で作業することは学習に役立ちます。なぜなら、助けを求める人は作業中の正確なコードとシナリオを既に理解しているからです。そのため、実際に多くの必要なアドバイスを得ることに時間/注意を失います
• より経験豊富で経験豊富な人の思考プロセスを理解し、コミュニケーションがうまくいけば、間違いなく新しいことを学ぶことができます

「コーディングが上手」以外の方法を使用できますか？私は来週、これを上司に報告するつもりです。

私のアドバイスは、ペアプログラミングを他の開発者と話し合ってから、スーパーバイザーにアプローチすることです。彼らがきちんとしているなら、ペアプログラミングのプロを売り込むチャンスがあなたのイニシアチブに感謝します（必要なら、ほとんどの人はそれを知っており、それが役立つ理由は一般的な知識です）。

ここにはいくつかの根本的な問題があります。あなたの問題のマージはあなたのせいではない可能性が非常に高く、より一般的には悪い習慣の症状です。

1）理想的には、毎日開発にブランチをマージします。開発にマージできるように、すべてのテストに合格する作業コードを少なくとも1日1回用意してください。

2）普段の勤務日のどの時点でも作業コードがない場合は、作業するコードが大きすぎる可能性があります。マージできるように、タスクをより速く（理想的には互いに独立して）終了できる小さなタスクに分割する必要があります。

3）プロジェクトファイルが大きすぎる可能性があります。ファイルに対して多くのマージ競合がある場合、1つのファイルで作業する人が多すぎます。理想的には、ある人が取り組んでいる何かは、他の人が取り組んでいるものとは別のものである必要があります。

4）チームが大きすぎる可能性があります。機能全体を捨てて最初からやり直す方が簡単な場合は、同じリポジトリにコードをコミットしている人が多すぎる可能性があります。

5）一貫したコードフォーマット標準がない場合があります。すべてが一貫して同じコードフォーマットを使用しない場合、同じコードに対して多くの異なる競合が発生します。gitの設定方法によっては、これらは空白の競合（行末、インデント、タブとスペース）に至ることもあります。

6）人々は開発ブランチに変更を直接プッシュしている可能性があります。

ここでは、何あなたが行うことができます：1）あなたは毎日あなたの枝に発展する（またはより頻繁に）リベース/マージ、日々開発にマージすることができない場合。
2）コードを他のすべてのコードから分離するようにしてください。
3）より小さな機能、一貫したコーディング標準、より優れたコード編成（より小さなファイル、より小さな機能）について、チームの他のメンバーに相談してください。

実際に私の仕事を捨ててタスクからやり直すのは簡単なようですが、もちろん持続可能な解決策ではありません）

ほとんどの場合、これは私がしていることです。初めてバグを修正したり、システムに変更を加えたりしたとき、その方法を学んでいます。次回同じバグを修正するとき、問題を理解しているので時間の1％しかかかりません。

また、少し作業をやり直すと、より良いコードを書くことになります。

したがって、マスターから新しいブランチを作成して作業をやり直し、「プライベートブランチ」を使用して何をする必要があるかを思い出させても問題はありません。

また、変更を論理的で正しい部分に分割する方法を発見した可能性もあります。各部分は、完了後にmasterブランチにマージされます。たとえば、ユニットテストとバックエンドコードの変更を行って結合することができます。その後、別の操作で、それらを使用するUIの変更を行うことができます。

開発ブランチを頻繁にブランチにマージしたくない場合は、を使用してsvnに似たワークフローを取得できますgit pull --rebase。これにより、新しいコミットがプルされ、コミットがリベースされます。つまり、ブランチを開発にマージすると、早送りマージ（過去のすべてのコミットを次々に追加した場合のように）になり、マージの競合は発生しません。git pull --rebase。

しかし、ブランチを開発またはブランチに開発する前にコミットを行うと、次のリベースがより複雑になり、ブランチはマージされていない限り存在するため、機能ブランチの感覚を少し覆します。

共通ファイルで作業する場合、どちらの方法でも、あなたまたはあなたのチームメイトは、マージが完了する前にすべての競合を解決する必要があります。したがって、最初は動揺しないでください。あなたはまだプロジェクトの仕事をしていて、あなたの仕事を誇りに思っています。よりスマートな動きをするために、以下のいくつかの提案に従うことができます。

1. タスクを独立して分割する：

   作業を開始する前に、各チームメンバーに割り当てられたタスクが可能な限り独立してモジュール式になるように、タスク全体を計画および分割します（開発中の潜在的な競合を回避するため）。スクラムリーダーにアプローチして、初心者のときにいくつかの独立したタスクを割り当てることができます。

2. きめ細かい頻繁なコミットをマージします。

   最終マージの前に完全なタスクが完了するのを待たないでください。もちろん、より大きなタスクは複数のサブタスクに分割できます。したがって、より良いアプローチは、小さなサブタスクの小さなコミットを頻繁に同時にマージして、大きな競合解決を回避することです。

3. ブランチを頻繁にリベースします。

   ローカルブランチにリモートブランチを頻繁にリベースする練習をしてください。以下のコマンドを使用して、ローカルブランチをリモートブランチに頻繁にリベースできます。

   git pull --rebase #or
   git pull --rebase origin dev #when dev is remote branch
   

   これは、これまでの私の開発人生で最も便利な gitコマンドです。

4. チームメイトと緊密に連携する：

   一般的なタスクでチームメイトと並行して作業する必要がある場合は、協力して作業してください。あなたが初心者であり、彼女が専門家であるので、彼女はあなたの便宜のために複雑な紛争解決を避けるためにいつか待つことができます。

5. gitオプションで慣れる：

   gitマージツールのパワーを使用します。マージ中に競合を解決するには、多くの便利な方法があります。戦略を統合することは時々非常に役立つかもしれません。gitコマンドに慣れて、大胆不敵です。