共有機能ブランチのGitワークフローは正しいですか？
私はこの状況に適したワークフローを見つけようとしています：
共有リポジトリには、次のブランチがあります。
-master
-feature
featureブランチはsharedブランチです。これは、多くの開発者が一緒に新しい機能に取り組んでいるためです。彼らは積極的に変更を機能ブランチにプッシュしています。
featureが最終的にmasterにマージされる日は、「競合地獄」を回避しようとしています。現在、いくつかのオプションがあります。
1）masterをfeatureに積極的にマージし、頻繁に実行します。ただし、これはお勧めしませんgit docsで、私はその理由を理解し始めています。これを試してみると、同じ競合を何度も修正しているようです。
2）何らかの方法でリベースを使用します。これについて読みましたが、featureブランチが実際に共有されているため、機能しないようです。 1人の開発者が2回のリベースを行うだけで、他の開発者は不一致の履歴から競合する可能性があります。
3）featureブランチを統合ブランチに変えますそして開発者にリベースを使って独自の独立した機能ブランチを使用させて物事を正気に保ちます。
4）まったく違うものはありますか？
共有ブランチの場合は、＃3を使用して、作業を統合するための「統合」ブランチとして使用します。
開発者は、リベースを使用して、作業をprivateにマージする前に、featureの上にfeatureブランチを常に再生する必要があります。
- マージの競合をローカルで解決する（独自のリポジトリで）
- 最終的なマージ（
privateブランチからfeatureへ）を簡単なものにします（通常は早送り）
（ "git rebase vs. merge " 回答）
featureブランチをmasterにマージする必要があると、featureでの投稿は受け付けられなくなり（ブランチは「凍結」されます）、安全に行うことができます。最初にmasterの上にリベースするか、masterに直接マージします。
次に、新しいfeatureブランチを開始します（必要に応じて、前のfeatureブランチと並行して開始できます）。
rerere を使用して、複数回発生しているマージの競合を処理できます。
（私はオプション1、2、または3にあまり熱心ではないので、より良いワークフローを見つけようとしています。したがって、誰かがアドバイスしてくれることを期待して、問題に取り組むことをどのように考えているかを以下に説明します。私）
- Gitパッチキューツールの1つを使用して、パッチキューの機能ブランチを有効にします。
- 別のgitリポジトリを使用して、パッチキューをバージョン管理します
- 通常のgitアプローチを使用して、パッチキューで共同作業を行います。
パッチキューをローカルで機能ブランチに戻すことは賢明かもしれません。
機能ブランチのGitワークフロー
プロセスは次のとおりです。-
初回：
git pull
git checkout -b sprint-4
git pull Origin sprint-4
上記のコマンドは、gitからすべてのファイルをプルします
ローカルマシン上にsprint-4という名前のブランチを作成します。
サーバーからsprint-4ブランチにファイルをプルします。
すべての新機能について：-
git checkout -b <feature-branch>, example: git checkout -n fer-181
git Push -u Origin <local-branch>:<remote-branch>, example git Push -u
Origin fer-181:fer-181
- サーバー上にこのローカルブランチのリモートブランチを作成します。
- ローカルブランチからリモートブランチにファイルをプッシュします。
毎日:(機能ブランチ上）
git pull
git merge dev
- 競合がある場合は解決する
その日のためにあなたの仕事をしなさい
git Push Origin
機能が完了しました：
git pull
git merge dev
競合がある場合は解決する
git checkout dev
git merge <feature-branch>
git Push Origin dev
- 上記のコマンドは、機能ブランチのメインブランチのファイルをマージします。
- 機能ブランチで競合があれば解決します。
- ファイルを機能ブランチからメインブランチにマージします。