GITを使用してプロジェクトで作業している複数の人を管理する


32

私はGIT / GitHubを初めて使用します(昨日から新しいように)。Githubで同じプロジェクトに取り組んでいる複数の人々を管理するための最良の方法は何かを知りたいです。現在、私は4人の開発者で1つのプロジェクトを管理しています。

  1. ワークフローを実行して、すべてが同期していることを確認するにはどうすればよいですか?

    (注:すべての開発者は1つのユニバーサルアカウントを持ちます。)

  2. 各開発者は異なるブランチにいる必要がありますか?

  3. 同じファイルで作業している2人を処理できますか?

詳細な回答を投稿してください。私は恥ずかしがり屋ではありません。これをよく理解する必要があります。


7
すべての開発者に1つのアカウントですか?それはうまくいくかもしれませんが、おそらくそれは良い考えではありません。
marstato


GitFlowTrunk Based Development調べる価値があるかもしれません。個人的に私は後者で大成功を収めました
Jルイス

回答:


29

すべての開発者がリポジトリへのコミットアクセスを持っている場合、特別なことをする必要はありません。リポジトリから変更を取得し、独自の変更を行い、ローカルにコミットし、何か機能する場合はパブリックリポジトリにプッシュします。

一方、レポへのコミットを担当する開発者が1人(または数人)で、他の開発者がこれらにパッチを提供している場合。各自に自分のアカウントにレポジトリをクローンさせ、メインレポジトリに変更を加えたいときにプルリクエストを送信させます。

必要に応じて、特定の機能を実行するための特定のクローンを作成することもできます。プルリクエストで同じワークフローを使用して、機能の完了時に変更をメインリポジトリに取得します。

「すべての開発者が1つのユニバーサルアカウントを持っている」ということは、すべての開発者が1つのGitHubアカウントを共有し、レポジトリで同じコミッターとして表示されることを意味します。個別のアカウントを作成し、すべてのユーザーにコミットアクセスを許可する場合は、それらを共同編集者として設定します。

特定の質問に関して:

  1. いいえ、複数のコミットを必要とする機能、修正などのためにブランチを使用します。複数の開発者が同じブランチで作業することができます。

  2. はい、gitは競合を本当にうまく処理するので、同じファイルで作業しても問題はありません。複数のメンバーによって編集されたファイルに根本的な変更がある場合、競合の解決は必ずしも些細なことではありませんが、問題はありません。しかし、これは一緒に話すことで克服できないものではありません。バージョン管理は通信に取って代わるものではありません。

がんばろう!


そこにあなたが作ったいくつかのポイントは真の目を見張るものであり、私は一緒に異なる方向に考えさせてくれました、ありがとう!
badZoke

それがあなたを助けることができればHapy。GitとDVCSには慣れる必要がありますが、慣れると非常に柔軟になります。
ハラルド

これをありがとう。具体的な質問が1つありました。同じブランチで複数の開発者が作業している場合。開発者の1人が作業ブランチに変更を加えてプッシュするたびに、残りの開発者は変更をプルする必要がありますか(作業するために最新のコードをローカルに持っていることを確認するため)?
エズワールラジェシュピナパラ

いいえ、毎回ではなく、同期したいときにだけです。ブランチのローカルコピーをプライベートブランチとして、アップストリームブランチをマージ先として検討してください。git fetch upstreamその後に続くようなものを使用するとgit merge upstream/branch、ローカルのコミット履歴を書き換えずに同期させることができます。それが問題でない場合は、単にgit pull --rebaseプッシュされていないローカルの変更を上流ブランチの最上部に移動するだけです。
ハラルド

@badZoke .... 3番目の質問を処理するために何をしたか(同じファイルで作業する2人を処理する)...
Moumit

25

2人の開発者と協力し、このワークフローを使用します。

  • Githubにはmasterブランチとdevブランチがあります
  • マスターブランチは、運用環境と同じか、展開準備コードが含まれています
  • devブランチはmasterより先にあり、現在作業中のすべての新しいコードが含まれています
  • ローカルでは、devブランチで作業し、準備ができたらgithubにプッシュします
  • 他の開発者は、新しいコードをプッシュする前に、開発ブランチから新しい変更をフェッチします
  • devブランチが良好な場合、masterブランチとマージします
  • ローカルでは、いくつかの機能ブランチがブランチなどを発行しています。

1
素敵でシンプルな、ありがとう!複雑なものに移る前に、これから始めます;)
badZoke

他の開発者がコードをプッシュする前に新しい変更を取得したときに、新しい変更が既に変更したコードを変更した場合はどうなりますか?
wayofthefuture

+1、これは確かに最初から最も簡単で、完全に問題なく動作します。:あなたが使用していることは単純化gitflowと呼ばれるmarcgg.com/assets/blog/git-flow-before.jpg
Jelle

5

ここにはテキストのみの回答が表示されるため、最初に素敵なgitflowの写真を投稿すると思いました。写真は千語以上を説明しています:

簡略化されたGitflow

  • このフローは、継続的展開でも適切に機能します。
  • マスターブランチには、運用サーバーで現在実行されているコードが含まれています。
  • 開発ブランチには、ステージング/テストサーバーで現在実行されているコードが含まれています。

+ 1、git flow、または同様のものがおそらくこの質問に対する正しい答えです。
Maybe_Factor

0

私は他の3人の開発者と仕事をしていますが、これにはかなり苦労しています。開発者は、プライムタイムの準備がまだ整っていない本番環境にコミットをプッシュすることがあります。これは、他のコミットを変更に引き込んで本番環境にプッシュするためです。バージョンブランチは問題なく動作するようです。したがって、バージョン1.0が現在の安定バージョンである場合、v1.1-developmentのブランチを作成します。開発者はこのブランチに変更を加えます。テストサーバーはこのブランチをチェックアウトし、必要に応じて変更をプルします。v1.1のすべての機能の準備が整ってテストが完了したら、v1.1をmasterとpushにマージします。ブランチを使用すると、開発者チームAはv1.1で作業でき、開発者チームBはv1.2で作業できます。両方のチームは、互いに影響を与えることなく作業できます。チームAがBが使用できるものを開発した場合、

また、即時の変更に使用される修正プログラムブランチも使用します。

これがどのように見えるかの写真へのリンクです。 http://nvie.com/img/git-model@2x.png


ただ、各リリースではなく、独自の枝にそれぞれ独立した機能や修正を分割することです-あなたは本当にそれが意図していたようにgitのフロー実装しようとしているようにそれは私には聞こえない
ブラッド・トーマス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.