git - GitHub チームの使用法

Question

こんにちは、GitHub のLearn-in-15 minutes チュートリアル を読み終えました。GitHub は非常に優れていて、簡単に入手できるようです。私が理解できないことの1つは、同じファイルを編集する可能性のある人々とチーム環境で作業することですか?

私の理解から

• originアプリケーションの最新ファイルを含む単一のリモート リポジトリ ( ) があります。
• origin各チームメンバーがマスターを引っ張る
• 各チーム メンバーは、独自のローカル ブランチを作成し、ファイルを編集し、ブランチをコミットし、ローカル とマージできますmaster。
• チーム メンバーは にプッシュできるようになりましmasterたorigin/master。

2 人のチーム メンバーが同じファイルを編集しないとどうなりますか。

オリジン V1

MemberA が V2 を作成し、Origin を V2 にプッシュ

MemberB はまだ V1 を持っていますが、V3 を作成し、それをプッシュすると、MemberA がプッシュした変更は元の V1 にロールバックされません。

それとも、ステージとプッシュするステージへのファイルの追加が機能する場所ですか?

IEは、すべてのファイルをプッシュで「置き換える」わけではありません..しかし、ステージ/コミットに追加したファイルのみ??

Answer 1

リモート (originこの例では) にプッシュしようとして、プッシュを試みる前にそのリモートのファイルが更新されている場合、プッシュは拒否されます。pullプッシュする前に、最初にリモートから競合を解決する必要があります。

それ以外の場合、競合がなければ、ファイルは にプッシュされたときに更新されmasterます。ここにはプロセス全体があることに注意してください。単にマスターにプッシュするだけではありません:-)（またはマージ）。ミームで申し訳ありませんが、私はしなければなりませんでした。

簡単に言えば、プッシュする前にリモート上のファイルが更新された場合、プッシュすることはできません。変更したファイルがリモートで変更されていない場合、プッシュは成功します。

基本的なフローでは、ブランチを頻繁にプルして master で最新の状態に保つ必要があります。

Answer 2

Git は、ワークフロー (製品所有者のアイデアから開発者の指示を経てテストを経て実稼働に至るまでの手順) を決定しないという点で優れています。むしろ、物事を追跡する方法を特定するだけです。したがって、あなたのプロセスはあなたが望むものにすることができます。この開放性は狭すぎると感じる人もいます。空白のページをどのように乗り越えますか?

Git-Flowは、さまざまな段階を通じて開発プロセスを追跡する、ブランチとブランチとマージの方法論の命名規則です。チームで作業するために必要な構造を提供するのに優れています。一般に、特定の定期的なリリースを対象としているため、一部の人にとっては多すぎる場合があります。

(Git-Flow 用の git プラグインもここにあります。)

Git-Flow が多すぎる場合は、ユーザーが master から分岐し、機能を構築し、テストし、master にマージするだけのGitHub Flowを検討することをお勧めします。

最終的に、これらはプロセスを処理するための規則に過ぎず、チームの文化にどれだけ一致しているかに応じて、すべてを採用することも、採用しないこともできます。