3

クリーン コードをメイン ブランチにプッシュするためのベスト プラクティスは何ですか?

これは Mercurial に関するベスト プラクティスの質問ですが、他の DVCS/git ユーザーの考えも当てはまります。適切なウェブサイトがあれば、それを教えてください。

多くのコントリビューターがいる大規模なプロジェクトでは、メインの開発ブランチをクリーンに保つにはどうすればよいですか?

中央リポジトリからソースのコピーを取得し、ブランチ、タグ、実験的コードのローカル マージを使用してローカルで一連の変更を行い、すべてがテストされて機能するまでコミットします。

ここで、最終的なコミットを行い、変更をトランクにプッシュします。これにより、ローカルの変更の完全な履歴が中央サーバーに送信されます。

これは概念的には問題ありませんが、最終ビルドを実行するスーパーバイザーは、テスト済みの最終バージョンに向けて作業しているすべての実験的およびバグのあるコードを確認できることを意味します。

クリーンなコードのみが含まれるようにプッシュをスリム化するベスト プラクティスの方法はありますか? 私のコードをクリーンにするのは私の責任ですか (折りたたみまたは他の拡張機能を使用)、それともスーパーバイザーがクリーンなビットを選択して「最終リリース」リポジトリにコピーしますか?

あなたの助けに感謝します。

スティーブ

=======================

回答: 以下の Tims の回答と、特に github について彼が提供したリンク [ github.com/git/git/blob/master/Documentation/SubmittingPatches ] を受け入れました。そうです - 提出物を中央リポジトリにプッシュする前にクリーンアップしてください!

4

1 に答える 1

5

何よりもまず、プロジェクトで予想されるワークフローについて上司に相談する必要があります。次の一般的なアドバイスはほとんどの状況に適していますが、プロジェクトには別の方法で行う理由がある場合があります。

一般に、リポジトリの公開された履歴をできるだけクリーンにするように努める必要があります。清潔さは次の方法で判断できます。

  • 小さくてまとまりのあるチェンジセット
  • クリーンアップまたはリファクタリングは、新機能とは別にコミットする必要があります。
  • 各コミットはテストに合格する必要があります（などのツールを許可するためbisect）

すべてのDVCSには、ローカル履歴と公開履歴の概念があります。ほとんどのワークフローでは、変更セットは、他の人が複製した公開リポジトリにプッシュされると公開されたと見なされます。

リポジトリの履歴の編集に関する2つの基本的なルールがあります。

  1. チェンジセットを公開したら、履歴を変更しないでください。これは、公開の準備ができているチェンジセットのみをプッシュすることが重要であることを意味します。hg pushMercurialの用語では、すべての発信変更を行わないでください。代わりに、hg push -b <branch>またはを使用hg push -r <rev>して、特定の変更のターゲットを絞ったプッシュを実行します。EditingHistoryより具体的な理由とアドバイスについては、Mercurialwikiを参照してください。

  2. チェンジセットを公開する前に（つまり、ローカルにある間）、必要に応じて修正、リベース、折りたたみなどを行って、「クリーンな」履歴を作成できます。gitでは、これはgit commit --amendまたはを使用して実行されgit rebaseます。Mercurialには、、、などの拡張子がqueues (mq)ありhisteditますcollapse。

ほとんどのプロジェクトでは、開発者は、レビューや公開のためにコードを送信する前に、自分のコードをクリーンアップすることが期待されています。これにより、レビュー担当者/インテグレーターが面倒な作業に時間を浪費するのを防ぐことができます。

于 2012-06-26T12:48:10.640 に答える