同じタスクに取り組む複数の開発者による適切なgitワークフロースキーム
私はWeb開発会社のチームリーダーであり、Gitワークフローをチームに実装したいと考えています。ドキュメントと記事を読むと、次の構造が役に立つことがわかりました。
Bitbucketにリポジトリがあります。 マスターブランチは、安定したコードのみを含むと見なされます。すべての開発者は、独自のブランチを作成し、ownブランチに機能/バグ修正を実装する必要があります。自分のコードの準備ができたと判断すると、（リベース、修正、チェリーピックなどを使用して）Niceブランチの履歴を作成し、それをBitbucketにプッシュします。そこで、マスターブランチへのプルリクエストを作成します。 QAは機能を検証し、それを承認（または不承認）します。その後、コードを検証し、問題がなければ、彼の作業をマスターにマージします（コミット履歴を改善するために早送りまたはリベースします）。
ただし、このスキームは、1人の開発者がブランチで作業する場合にのみ有効です。私たちの場合、1人の開発者がserver-side（PHP）と別の開発者-client-side（HTML/CSS/JS）。これら2つがどのように協力して、マスターのコミット履歴がクリーンに保たれるのでしょうか？
サーバー開発者はHTMLファイルの基本構造を作成し、クライアント開発者はこの構造を取得する必要があります。論理的には、サーバーdevがブランチを作成し、クライアントdevがサーバーdevブランチに基づいて独自のブランチを作成します。ただし、これは、サーバー開発者がpublish Bitbucketのブランチを必要とすることを意味します。これにより、既に公開されているコミットのリベースまたは変更が不可能になります。
別のオプションは、サーバー開発者が作業を完了し、ニースでブランチを公開し、履歴を忘れて、それを忘れるまで待つことです。そして、クライアント開発者がこのブランチで作業を開始した後にのみ、これはさらに悪いことに時間遅延を引き起こします。
ワークフローでこのようなコラボレーションをどのように処理しますか？
私はあなたの投稿で説明されている方法のメリットについては本当に話すことはできませんが、仕事で使用するワークフローでどのようにコラボレーションコーディングを解決したかを説明できます。
使用するワークフローは、多くのブランチの1つです。したがって、私たちの構造は次のとおりです。
マスターは黄金です。マージマスターのみがそれに触れます（これについては後で詳しく説明します）。
最初にmasterから取得したdevブランチがあり、すべてのdevが機能します。開発者ごとにブランチを作成する代わりに、devから機能ブランチまたはチケットブランチを作成します。
目立たない機能（バグ、機能強化など）ごとに、devから新しいローカルブランチが作成されます。各機能ブランチは、その単一の開発者が取り組んでいるもののみにスコープされるため、開発者は同じブランチで作業する必要はありません。これは、gitの安価な分岐が役立つ場所です。
機能の準備が整うと、ローカルでdevにマージされ、クラウド（Bitbucket、Githubなど）にプッシュされます。開発者を頻繁に利用することで、誰もが同期を保ちます。
毎週のリリーススケジュールに沿っているため、毎週、QAがdevブランチを承認した後、名前に日付を付けてリリースブランチが作成されます。これは、先週のリリースブランチに代わる実稼働環境で使用されるブランチです。
本番環境でQAによってリリースブランチが検証されると、リリースブランチはマスターにマージされます（そして、念のためにdevに戻ります）。これがマスターに触れる唯一の時間であり、可能な限りクリーンであることを保証します。
これは、12人のチームでうまく機能します。うまくいけば、役立ってくれました。幸運を！
プリンシパルリポジトリがあり、各開発者はそのフォークを持っています。
ブランチがprincipal/some_projectに作成され、その後、各開発者のfork/fork/some_projectに同じブランチ名が作成されます。
（私たちはsmartgitを使用しており、新しいユーザーを混乱させる「Origin」と「upstream」ではなく、「principal」と「fork」という名前のリモートポリシーがあります）。
各開発者には、some_projectという名前のローカルブランチもあります。
開発者のローカルブランチsome_projectは、リモートブランチプリンシパル/ some_projectを追跡します。
開発者はブランチsome_projectとfork/some_projectへのプッシュでローカル作業を行い、プル要求を作成することがあります。これが、各開発者の作業がprincipal/some_projectにマージされる方法です。
このように、開発者はローカルで自由にプル/リベースし、フォークにプッシュできます-これはほとんど標準的なフォークワークフローです。このようにして、彼らは他の開発者のコミットを取得し、時々奇妙な競合を解決する必要があります。
これは問題ありません。現在必要なのは、プリンシパル/マスターに表示される進行中の更新（たとえば、緊急修正やsome_projectが完了する前に配信される他のプロジェクト）をマージする方法です。
これを実現するために、SmartGitのマージ（プルではなくリベース）を使用して、マスターからの更新をローカルでsome_projectにローカルにマージすることを「ブランチリード」に指定します。これによって競合が発生する場合があるため、これらを解決する必要があります。これが完了すると、その開発者（ブランチリード）が強制的にfork/some_projectブランチにプッシュし、プルリクエストを作成してprincipal/some_projectにマージします。
そのプル要求がマージされると、プリンシパル/マスターにあったすべての新しいコミットがプリンシパル/ some_projectブランチに存在するようになります（リベースされたものは何もありません）。
そのため、各開発者が次にsome_projectを使用してプルする（思い出してください、追跡されたブランチはprincipal/some_projectである）とき、プリンシパル/マスターからマージされたものを含むすべての更新を取得します。
これは長い風に聞こえるかもしれませんが、実際にはかなりシンプルで堅牢です（開発者はすべて、プリンシパル/マスターからローカルにマージすることもできますが、1人がそれをすれば、チームの残りは単一の開発者のワークフローのようにシンプルな世界に住んでいます） 。
トピックのブランチで協力してクリーンな履歴を維持する方法についての元の質問に実際に答えた人はまだいないと思います。
適切な答えは申し訳ありませんが、すべて一緒にすることはできませんです。他の人のために何かを公開した後は、その上で作業する必要があります。
サーバー開発者がクライアント開発者の変更を気にしない特定の場合にできる最善の方法は、開発者/機能ブランチからクライアントブランチをローカルにフォークし、機能を終了する直前にサーバー作業の上でその部分をリベースするか、制約を緩和することですそして、あなたがしたように、別のワークフローに切り替えます;）
これにより、既に公開されているコミットをリベースまたは変更することができなくなります。
これは視聴者に依存します。 「サーバー開発」は、「クライアント開発」がアクセスできるように「基本構造」をBitbucketにプッシュできます。 はい、これは潜在的に他の人がこれらの「一時的な」コミットにアクセスできることを意味します。
ただし、これは、別のユーザーがこれらのコミットのいずれかから分岐した場合beforeにリベースされた場合にのみ問題になります。小規模なプロジェクト/小規模なユーザーベースでは、これらの一時的なコミットはリベースが発生する前であっても気付かない可能性があるため、リスクがなくなります。
これらの一時的なコミットから分岐するリスクが大きすぎる場合の決定はあなた次第です。その場合、これらのプライベートな変更のために、おそらく2つ目のプライベートBitbucketリポジトリを作成する必要があります。別のオプションは、リベースの代わりに merge commits を行うことですが、これも理想的ではありません。
複数の開発者が同じプロジェクトに取り組んでいる間（ここでも同じコントローラー/モデル/ビューに取り組んでいる場合もあります）、ここで何をするかを教えてください。
まず、チームリーダーが2つのブランチを持つgit-projectを作成しました
- マスター（保護されています。チームリーダー以外は誰もプッシュできません）
- 開発（すべての開発者がここにプッシュできます）
割り当てられたタスクのいずれかを完了すると、ローカル環境で作業し、コミットを作成するように指示されました。
夕方の時間（または閉店時間-退室）で、これを行います：
- Git Pull
同じプロジェクトに取り組んでいるすべての開発者は、現在の開発ブランチをローカルにプルします（朝に同じことを-一日の始めに）。
その後、チームリーダーはすべてのコードをコミットし、1つずつプッシュしてからプルするように開発者に指示しました。
例えば.
- dev1はコミットを作成し、サーバーにプッシュします
- dev2は再びプルし、コミットとプッシュを作成します
- dev3は再びプルし、コミットとプッシュを作成します
- 等々..
今、問題は競合です：
- 開発ブランチからコードをプルしている間、gitはすべての競合を自動的にマージしたことを通知します---つまり、gitは別の開発者によって行われた新しい変更を自動的に適用しました
- しかし、いつかは同じGitが自動マージが失敗したことを伝え、いくつかのファイル名を表示します
- チームリーダーの役割が浮かび上がります。彼がしていることは次のとおりです。
手動でマージする方法：GITは、次のようなすべてのコンテンツで競合ファイルを更新するだけです：
<<< HEAD
New lines from server that you don't have is here shown
=====
Your current changes....
>>> [commit id]
これを分析した後、チームリーダーがそのファイルを更新します。
New lines from server that you don't have is here shown
Your current changes
コミットとプッシュを作成します。
再び朝にプルします（前日から何かを見逃さないようにするためです）。これがここでの作業方法です。
覚えておくべきルールは次のとおりです。
- 1つの
masterと1つのdevelopブランチがある developブランチから機能ブランチを生成します- テストするバージョン[〜＃〜] qa [〜＃〜]を用意するたびに、
developにマージします。 developブランチからリリースブランチを生成します- リリースブランチにバグ修正を行う
- テストするバージョン[〜＃〜] qa [〜＃〜]が用意できたら、
developにマージします。 - バージョンの準備ができたら[〜＃〜] production [〜＃〜]、
masterにマージし、タグを作成しますそれ
次の図は、世界中のチームが従うブルズアイ戦略です（クレジット： here から取得）：
正確な質問である同じタスクの複数の開発者にとって、短い答えは、タスクはそのタスクの統合ブランチで実行されるということです。その「タスク」ブランチは、通常のGitワークフローの「マスター」または「開発」ブランチと同様に扱われます（ほとんどの回答がここに記載されています）。この統合ブランチは、他で詳しく説明されている「Git Feature Branch Workflow」で処理されます。
このタスクブランチは、そのタスクで作業する開発者が通常のGitコマンドを使用してコードを共有する場所です。
例
新しいスプラッシュスクリーンを開発するために、リード開発者（または誰か）は
git co master
git co -b feature-splash
git Push Origin feature-splash
この機能に取り組んでいる各開発者は次のことを行います。
git co master
git pull
git co feature-splash
git co -b my-feature-splash // they can name their branch whatever
これで、各開発者はブランチで開発し、GitHubなどの中央Gitリポジトリサーバーの機能スプラッシュでマージに向けてプルリクエストを作成します。それは、神聖な「マスター」ブランチに対して行われるように。
機能が完了すると、機能のスプラッシュがマスターにマージされます。もちろん、この機能のスプラッシュは、マスター上の新しいコードで最新に保つ必要があります。機能のスプラッシュは、マスターに基づいたリベースを使用できますか？
これは私の最初のアイデアではありません。私はこれについていろいろな場所で読んだ。多くのワークフロー記事では、このタスク固有のブランチは実際には概念ではないことに注意してください。たとえば、ある記事では、「機能ブランチは通常、開発者リポジトリにのみ存在し、Originには存在しません」とあります。おそらく、複数の開発者を必要とするタスクは、常にサブタスクに分割されますか？あなたは未来を知っていて、何が必要かを知っていると思います。