59

私はWeb開発会社のチームリーダーであり、Gitワークフローをチームに実装したいと考えています。ドキュメントと記事を読んで、次の構造が私たちに適していることがわかりました。

Bitbucketにリポジトリがあります。マスターブランチには、安定したコードのみが含まれていると見なされます。すべての開発者は、独自のブランチを作成し、独自のブランチに機能/バグ修正を実装する必要があります。コードの準備ができていると判断したら、（リベース、修正、チェリーピックなどを使用して）優れたブランチ履歴を作成し、それをBitbucketにプッシュして、マスターブランチへのプルリクエストを作成します。QAは機能を検証し、それを承認（または不承認）します。次に、コードを検証し、問題がない場合は、彼の作業をマスターにマージします（早送りまたはリベースしてコミット履歴を改善します）。

ただし、このスキームは、1人の開発者がブランチで作業する場合にのみ有効です。私たちの場合、1人の開発者がサーバー側（PHP）で作業し、もう1人がクライアント側（HTML / CSS / JS）で作業しているため、ほとんどの場合、1つのブランチに2人の開発者がいます。マスターのコミット履歴をクリーンに保つために、これら2つをどのように連携させる必要がありますか？

サーバー開発者はHTMLファイルの基本構造を作成し、クライアント開発者はこの構造を取得する必要があります。論理的には、サーバー開発者がブランチを作成し、クライアント開発者がサーバー開発者ブランチに基づいて独自のブランチを作成することになります。ただし、これは、サーバー開発者が自分のブランチをBitbucketで公開する必要があることを意味します。これにより、既に公開されているコミットをリベースまたは変更することができなくなります。

もう1つのオプションは、サーバー開発者が作業を終了し、適切なコミット履歴を含むブランチを公開してそれを忘れるまで待つことです。その後、クライアント開発者はこのブランチで作業を開始しますが、これにより時間遅延が発生し、さらに悪化します。

ワークフローでこのようなコラボレーションをどのように処理しますか？

4

8 に答える 8

87

あなたの投稿で説明されている方法のメリットについては実際には言えませんが、私たちが仕事で使用しているワークフローでコラボレーションコーディングをどのように解決したかについては説明できます。

私たちが使用するワークフローは、多くのブランチの1つです。したがって、私たちの構造は次のとおりです。

マスターは金色です。マージマスターのみがそれに触れます（これについては後で詳しく説明します）。

最初はマスターから取得した開発ブランチがあり、すべての開発者が機能します。開発者ごとにブランチを作成する代わりに、開発者から機能またはチケットのブランチを作成します。

目立たない機能（バグ、拡張機能など）ごとに、devから新しいローカルブランチが作成されます。各機能ブランチは、その1人の開発者が作業しているものだけにスコープされているため、開発者は同じブランチで作業する必要はありません。これは、gitの安価な分岐が役立つところです。

機能の準備が整うと、ローカルでdevにマージされ、クラウド（Bitbucket、Githubなど）にプッシュされます。devを頻繁に使用することで、全員が同期を維持します。

毎週のリリーススケジュールになっているため、毎週、QAがdevブランチを承認した後、名前に日付が含まれるリリースブランチが作成されます。これは、先週のリリースブランチに代わる、本番環境で使用されるブランチです。

リリースブランチが本番環境でQAによって検証されると、リリースブランチはマスター（および安全のために開発）にマージされます。マスターに触れるのはこれが唯一の時間であり、可能な限りクリーンであることを確認します。

これは、12人のチームでうまく機能します。お役に立てば幸いです。幸運を！

于 2013-02-14T07:04:56.227 に答える
7

きれいな歴史を維持しながら、トピックブランチでどのようにコラボレーションするかという当初の質問に実際に答えた人はまだいないと思います。

正解は申し訳ありませんが、すべてを一緒にすることはできません。あなたはあなたのプライベートな地元の歴史を手入れすることができるだけです、あなたが他の人のために何かを公開した後、あなたはその上で働くべきです。

サーバー開発者がクライアント開発者の変更を気にしない特定の場合にできる最善のことは、開発者/機能のブランチからクライアントブランチをローカルにフォークし、機能を終了する直前にサーバー作業の上にその部分をリベースするか、制約を緩和することです。そして、あなたがしたように、別のワークフローに切り替えます;）

于 2014-04-29T15:38:41.630 に答える
7

プリンシパルリポジトリがあり、各開発者にはそのフォークがあります。

ブランチはprincipal/some_projectに作成され、同じブランチ名が各開発者のフォーク、fork/some_projectに作成されます。

（私たちはsmartgitを使用しており、リモートは「origin」と「upstream」ではなく「principal」と「fork」という名前で、新しいユーザーを混乱させるというポリシーもあります）。

各開発者には、some_projectという名前のローカルブランチもあります。

開発者のローカルブランチsome_projectは、リモートブランチprincipal/some_projectを追跡します。

開発者はブランチsome_projectでローカル作業を行い、fork / some_projectにプッシュします。プルリクエストを作成することがあります。これにより、各開発者の作業がprincipal/some_projectにマージされます。

このようにして、開発者はローカルで自由にプル/リベースしてフォークにプッシュできます。これは、ほぼ標準のフォークワークフローです。このようにして、彼らは他の開発者のコ​​ミットを取得し、時々奇妙な競合を解決しなければならない場合があります。

これは問題なく、現在必要なのは、プリンシパル/マスターに表示される進行中の更新をマージする方法です（たとえば、some_projectが終了する前に提供される緊急の修正やその他のプロジェクト）。

これを実現するために、「ブランチリード」を指定します。その役割は、SmartGitのマージ（プル、リベースではない）を使用して、マスターからの更新をsome_projectにローカルにマージすることです。これも競合を引き起こすことがあり、これらを解決する必要があります。これが完了すると、開発者（ブランチリード）がfork / some_projectブランチにプッシュし、principal/some_projectにマージするプルリクエストを作成します。

そのプルリクエストがマージされると、principal /masterにあったすべての新しいコミットがprincipal/some_projectブランチに存在するようになります（リベースされたものはありません）。

したがって、次に各開発者がsome_projectに参加し、プルするとき（追跡されたブランチはprincipal / some_projectであることを思い出してください）、principal/masterからマージされたものを含むすべての更新を取得します。

これは長蛇の列に聞こえるかもしれませんが、実際にはかなりシンプルで堅牢です（すべての開発者はプリンシパル/マスターからローカルにマージすることもできますが、1人がそれを行うと、チームの他のメンバーは単一の開発者ワークフローのようにシンプルな世界に住んでいます） 。

于 2017-01-19T23:00:03.190 に答える
3

これにより、すでに公開されているコミットをリベースまたは変更することができなくなります。

これはあなたの聴衆に依存します。「サーバー開発者」は「基本構造」をBitbucketにプッシュして、「クライアント開発者」がそれにアクセスできるようにすることができます。はい、これは、他の人がこれらの「一時的な」コミットにアクセスできることを意味する可能性があります。

ただし、これは、リベースされる前に別のユーザーがこれらのコミットの1つから分岐した場合にのみ問題になります。小規模なプロジェクト/小規模なユーザーベースでは、リベースが発生する前であっても、これらの一時的なコミットに気付かない可能性があるため、リスクがなくなります。

これらの一時的なコミットから誰かが分岐するリスクが大きすぎるかどうかは、あなた次第です。もしそうなら、おそらくこれらのプライベートな変更のために2番目のプライベートBitbucketリポジトリを作成する必要があります。別のオプションは、リベースの代わりにマージコミットを実行することですが 、これも理想的ではありません。

于 2013-02-14T04:38:21.667 に答える
3

覚えておくべきルールは次のとおりです。

  • 1つと1masterつのdevelopブランチがあります
  • develop機能ブランチをブランチからスポーンさせます
  • QAでテストする準備ができているバージョンがあるたびに、develop
  • developリリースブランチをブランチからスポーンさせます
  • バグ修正をリリースブランチに作成する
  • QAでテストするためのバージョンの準備ができたら、develop
  • PRODUCTIONのバージョンの準備ができたら、にマージしてmaster、そのタグを作成します

次の図は、世界中のチームで行われているブルズアイ戦略です（クレジット：ここから取得）：

ここに画像の説明を入力してください

于 2018-08-17T07:31:10.460 に答える
2

複数の開発者が同じプロジェクトに取り組んでいる間（同じコントローラー/モデル/ビューに取り組んでいる場合もあります）、ここで何をしているのかをお話ししましょう。

まず、チームリーダーが2つのブランチを持つgit-projectを作成しました

  1. マスター（保護されているので、チームリーダー以外はここにプッシュできません）
  2. 開発（すべての開発者はここにプッシュできます）

彼らは、割り当てられたタスクの1つを完了するたびに、ローカル環境で作業し、コミットを作成するように指示しました。

今、夕方の時間（または閉店時間-出発）に、これを行います：

  1. Gitプル

同じプロジェクトに取り組んでいるすべての開発者は、現在の開発ブランチをローカルにプルします（午前中に同じことを行います-日中から開始します）。

次に、チームリーダーは開発者に、すべてのコードをコミットし、1つずつプッシュしてから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

コミットとプッシュを作成します。

再び朝に私たちは引っ張ります（前日から何かを逃していないことを確認するためだけに）、これが私たちがここで働く方法です。

于 2016-06-04T18:09:34.203 に答える
2

正確な質問については、同じタスクに複数の開発者がいます。簡単な答えは、タスクがそのタスクの統合ブランチで実行されるということです。その「タスク」ブランチは、通常のGitワークフローの「マスター」または「開発」ブランチと同じように扱われます（ここで提供されるほとんどの回答として）。この統合ブランチは、他の場所で詳しく説明されている「Git機能ブランチワークフロー」で処理されます。

このタスクブランチは、そのタスクに取り組んでいる開発者が通常の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リポジトリサーバーの機能スプラッシュでのマージに向けたプルリクエストを作成します。神聖な「マスター」ブランチで行われるのと同じように。

機能が完了すると、機能スプラッシュがマスターにマージされます。もちろん、この機能スプラッシュは、マスターの新しいコードで最新の状態に保つ必要があります。機能スプラッシュはマスターに基づいてリベースを使用できますか？

これは私の最初の考えではありません。私はこれについていろいろな場所で読んだ。多くのワークフロー記事では、このタスク固有のブランチは実際には概念ではないことに注意してください。たとえば、ある記事には、「機能ブランチは通常、開発者リポジトリにのみ存在し、元には存在しない」というものがあります。おそらく、複数の開発者を必要とするタスクは、常にサブタスクに分割されますか？あなたが未来を知っていて、何が必要かを知っているなら、私は推測します。

于 2019-04-07T04:09:53.113 に答える
1

あなたはGit-flowを見るかもしれませんこれはあなたを助けるかもしれません

http://nvie.com/posts/a-successful-git-branching-model/

于 2013-02-14T07:19:28.223 に答える