7

このページを優れたワークフローとして指している多くの参照を見つけたので、ここで説明するワークフローに従います。記事で述べたように、「機能」ブランチは開発者間で共有されますが、中央リポジトリには移動しません。

開発者「A」が。で新しい機能ブランチを開始するとしgit checkout -b newfeature developます。ここで、開発者「B」もこの機能に取り組む必要があるとしましょう。これが私の問題です。

私がしたこと：

  1. 開発者「B」は、開発者Aのマシンをリモートとして追加します
  2. 開発者「B」が実行しますgit branch remoteA/newfeature
  3. 開発者「B」はこのブランチで作業し、作業をコミットして、変更をremoteAにプッシュします。

現在、ステップ3は機能していません。メッセージが表示されます：

remote：error：デフォルトでは、非ベアリポジトリの現在のブランチの更新は拒否されます。これは、インデックスと作業ツリーがプッシュしたものと一致しなくなり、作業ツリーと一致するように「gitreset--hard」が必要になるためです。頭へ。

remote：error：リモートリポジトリで「receive.denyCurrentBranch」構成変数を「ignore」または「warn」に設定して、現在のブランチにプッシュできるようにすることができます。ただし、他の方法でプッシュしたものと一致するように作業ツリーを更新するように手配しない限り、これはお勧めしません。

remote：error：このメッセージをスケルチし、デフォルトの動作を維持するには、receive.denyCurrentBranchの構成変数を「refuse」に設定します。

私はすでに設定sharedRepository = trueしましたが、それは役に立ちませんでした。

2つの質問があります：

  1. 開発者間で機能ブランチを共有する正しい方法は何ですか？
  2. 開発者Bのリポジトリの変更を開発者Aの元のリポジトリにプッシュバックするにはどうすればよいですか？
4

2 に答える 2

8

機能ブランチを共有する最も簡単な方法は、それらを中央リポジトリにプッシュするだけで、誰でもそれらからプルできるようにすることです。そうすれば、メインリポジトリ用にすでに持っているインフラストラクチャを簡単に使用でき、コードを簡単に共有できます。

リモートの機能ブランチが不要になったら、次の手順を実行するだけで削除できます。

git push <server> :branch

ユーザーが異なるネットワーク上にいる（相互に接続されていない）などの問題が発生しやすいため、開発者のマシン間で直接共有することはお勧めしません。

可能であれば、サーバー上に1つの中央リポジトリ（祝福されたメインリポジトリ）があるGitHubモデルを使用することもできます。そして、そのメインリポジトリに加えて、各開発者はそのリポジトリの「フォーク」を持っており、完全なコミットアクセス権を持ち、好みに合わせてブランチをプッシュできます。

この場合、1つの集中型サーバーへの簡単なアクセスを維持しながら、同僚のフォークをリモートとしてリポジトリに追加できます（すべてのマシンでSSHキーを設定する手間を省くなど）。

GitHubモデルの説明は、次の場所にあります： http ://www.eqqon.com/index.php/Collaborative_Github_Workflow

更新：コメント投稿者が指摘したように、これは集中機能ブランチワークフローを開始するための良いリンクです：http：//nvie.com/posts/a-successful-git-branching-model/

Update2：2番目の質問を拡張するには：

あなたがやろうとしているのは、別の開発者の非ベアリポジトリにプッシュすることです。以前のバージョン（1.6程度だと思います）で導入されたGitは、ベアリポジトリの概念を導入しました。これは、チェックアウト状態がなく、通常はに入るデータベースのみを含むリポジトリです.git。

この変更の背後にある理由は、同僚のリポジトリ（現在何かに取り組んでいる）にプッシュするときはいつでも、彼のすぐ下でリポジトリを操作しているということでした。そこで彼はバージョンfeatureA-1をチェックアウトします..作業を開始します..次にfeatureA-2をレポにプッシュします。コミットしたいとき、彼がいたブランチが1回のコミットで進んだため、問題が発生します。発達。

これは非常に破壊的であるため、ほとんどの人はローカルgitリポジトリ（積極的に作業しているリポジトリ）をプライベートにする必要があるという概念を採用していますが、変更を受け取って共有するパブリックgitリポジトリ（フォーク）があります。そうすれば、作業中に他の人に邪魔されることはなく（とにかく分散型モデルの背後にある全体的な考え方です）、必要な変更のみを組み込むことができます。（誰もあなたの現在の仕事に何かをプッシュすることはできません）。

于 2011-12-13T21:31:07.530 に答える
5

非ベアリポジトリにプッシュできます。あなたができないことは、あなたがチェックアウトするためにプッシュしているブランチを持っている非裸のリポジトリにプッシュすることです。この理由は理にかなっているはずです。他の誰かが作業している可能性のあるファイルを変更するのは正しくありません。

通常、マスターまたはその他の一般的な共有ブランチにプッシュする必要があります。この競合を回避するために、リモートの非ベアリポジトリの所有者は、ローカルブランチまたは少なくとも他のブランチで作業する必要があります。次に、共有ブランチにプッシュできます。

あなたの例を使用するには：

  1. 開発者「B」は、開発者Aのマシンをリモートとして追加します
  2. 開発者「B」が実行しますgit branch remoteA/newfeature
    1. 開発者「A」はローカルブランチで動作します。git checkout -b work-newfeature
  3. 開発者「B」はこのブランチで作業し、作業をコミットして、変更をremoteAにプッシュします。
    1. 開発者「A」は、新しい作業を取得するためにリベースします。git rebase newfeature
于 2011-12-15T04:44:49.663 に答える