0

Git初心者からのもう1つの初心者の質問。

私はgitリポジトリを持っており、2人の開発者が2つの異なるフォークに取り組んでいます。要件は、全員が独立して作業できる必要があり、いくつかの変更後、両方がプルリクエストを作成し、私がそれらの作業をメインリポジトリにマージすることでした。これが発生すると、両方がメインリポジトリから変更をプルし（リモートとして追加することにより）、最新のコードで作業を続行します。

私の質問-

  1. これは従うべき良いアプローチですか？
  2. 開発者ごとにブランチを作成し、独自のブランチでコミットして後でマスターにマージするように依頼する必要がありますか？（私にはオーバーヘッドのように見えます）
  3. 両方の開発者がお互いのコードにアクセスしたい場合はどうなりますか（リモートリポジトリとして他のフォークを追加し、お互いのコードで遊んで、後でメインリポジトリにプッシュしようとすることはできますか？競合が発生する可能性があり、悪い習慣だと思います。 。それですか？）
         メインリポジトリ
            / \
    sub1 <-> sub2
    sub1がサブ2をリモートリポジトリとして追加し、変更をプルして、後でメインリポジトリのプルリクエストを作成しようとすると、競合やその他の問題が発生しますよね？
  4. このような状況でコードを管理する他の方法はありますか？

ボーナス：一時的に働いている可能性のあるフリーランサー/他の開発者の完全なコードベースへのアクセスを制限するにはどうすればよいですか？（コードではなく管理の観点から）

4

1 に答える 1

1

  1. あなたの図で説明されている関係は、完全に適切で正しいアプローチです。

  2. 質問2では、gitの分散された性質のポイントが欠けています。最も単純な例を説明しようとします。各開発者は、マスター ブランチを持つリポジトリのクローンを持つ必要があります。彼らが開発する場合、好ましいアプローチは、いわゆるフィーチャーブランチまたはトピックブランチで開発することです。つまり、特定の機能やバグ修正などに特化したブランチです。これにより、さまざまな機能の並行開発が可能になります。ただし、これらのブランチはメインラインで共有する必要はありません。ローカルのままにすることができますし、必要に応じてメインラインにプッシュしても問題はありません)メインラインに影響を与えずにコードを交換したい場合は、追加できますお互いがリモートとしてリポジトリを作成し、必要に応じてお互いのブランチを追跡します。そしたらいつ」

別のアプローチは、メインラインに統合ブランチを持つことです。それはマスターである場合もあれば、その単一の目的のために維持されている別のブランチである場合もあります。開発側で一部の準備が整うと、開発者はローカル リポジトリを統合ブランチに切り替え、最新の変更をプルしてトピック ブランチをマージ/リベースし、メインラインにプッシュします。

  1. 上記のスキームでは、開発者はコミットされたコードのみにアクセスできます。しかし、もちろん、同じコードで作業している場合、競合が発生する可能性があります。そして、それらを解決する必要があります。これは、VCS の通常のワークフローです。ここでの唯一のアドバイスは、競合の大きさに圧倒されないようにすることです。したがって、次のような基本的な戦略を使用する必要があります。

a）より頻繁にコミットする b）単一の機能単位である小さなチャンクをコミットし、何百ものファイルをコミットしないでください。c) より頻繁に統合する

ボーナス：レポの一部へのアクセスを制限することはできないため、コンポーネント指向のアプローチを使用して、物事を異なるレポに分割してください。これにより、詳細なアクセス管理が可能になるだけでなく、統合の量が削減され (コードベース全体ではなく、すべてのコミットが影響を受けるため)、さらに、より良い設計が強制される可能性があります。

于 2012-10-05T16:15:19.373 に答える