バージョン管理のベストプラクティス質問する

Question

あなたが尋ねている質問のほとんどは、あなたが誰と一緒に働いているかによって大きく異なります。あなたが一人の開発者であれば、好きなことを何でもできるので、あまり問題にはなりません。しかし、コードを共有しなければならないチームに所属している場合は、チームメンバーと話し合う必要があります。行動規範お互いの変更を共有することが時々困難になる可能性があるため、そうすべきです。

行動規範に関する議論は、長々とする必要はなく、非常に簡潔なもので構いません。チーム内のプログラマー間で共有されているリポジトリの使用方法について全員が同じ認識を持っている限りです。チェリーピッキングやパッチキューなど、Mercurial のより高度な機能を使用する場合は、パブリックリポジトリへのリベースなど、チームメンバーに悪影響を与えないように使用してください。

バージョン管理はチーム全員にとって使いやすいものでなければならないことを覚えておいてください。そうでなければ、使用されません。

いつ、どのくらいの頻度でコミットすべきでしょうか? 大きな変更があった後、それが機能するかどうかは関係ありませんか? 夜間の作業が終わったとき? 次の安定したイテレーションに達したときのみ? バグ修正後?

チームで仕事をする場合、いくつかのアプローチがありますが、共通のルールは早く頻繁にコミットする. あなたがすべき主な理由は頻繁にコミットする作ることですマージの競合をより簡単に処理できる。

マージ競合とは、少なくとも 2 人のユーザーが変更したファイルをマージしようとしても、同じ行を編集しているためにうまくいかない場合に発生します。複数のファイルにわたる複数の行の変更を伴う非常に大きな変更を伴うコミットを保留している場合、受信側が競合の発生を管理するのは非常に困難になります。この一連の変更が長期間保留されている場合、マージ競合の処理はさらに困難になります。

頻繁にコミットするというルールにはいくつかの例外があり、その1つは破壊的な変更ただし、ローカルでコミットする機能がある場合 (Mercurial と git では本来これを行います)、破壊的な変更をコミットできます。壊れた部分を修正したら、自分の破壊的な変更を修正したら、それを共有リポジトリにアップストリームでプッシュする必要があります。

たとえば、メニューのレイアウトを変更して、再度マージしたい場合、分岐しますか? 分岐する必要がありますか?

沢山あります分岐戦略選択できるもの（ストリームライン1998年の論文には分岐戦略の網羅的なパターンリスト) であり、自分でブランチを作成する場合は、自由に選択できる必要があります。ただし、チームで作業する場合は、ブランチが必要かどうかをチームとオープンに話し合うことをお勧めします。ブランチを作成する必要があるときはいつでも、次の質問を自分に問いかける必要があります。

今後の変更によって他の人の作業が損なわれるでしょうか?
私が完了するまでに行う変更によって、私のチームに直接的な悪影響が出るでしょうか?
私のコードは使い捨てコードですか?

上記の質問のいずれかに「はい」と答えた場合は、おそらくブランチを公開するか、自分用に保持します (Mercurial ではいくつかの方法でこれを行うことができます)。まず、チームと全体の取り組みをどのように実行するかについて話し合い、他の方法があるかどうかを確認します。また、変更をマージする場合は、ブランチする必要がない要因が作用している場合があります (これは主にコードのモジュール化の程度に関係します)。

ブランチを作成する場合は、マージの競合に対処する準備をしてください。ブランチを作成してコミットした人が、それを「メインブランチ」にマージできると想定するのは理にかなっています。このような場合、チーム全員が関連するコミットコメントを作成しておくと便利です。

余談ですが、あなたは良いコミットコメントを書いていますよね？そうですよね？良いコミットコメントは通常なぜ具体的な変更が行われたかどうかや、コミッターが作業していた機能など、漠然とした「コミットしました」のようなコメントではなく、明確に記述します。これにより、大きなマージ競合を処理している人が、リビジョン履歴を調べながら、どの行の変更を上書きして、どの行の変更を保持するかを判断しやすくなります。

コンパイル時間、またはビルド時間は、ブランチに関する議論に影響を与えることがあります。プロジェクトのビルド時間が遅い場合は、ブランチでステージング戦略を使用することをお勧めします。この戦略では、すべての開発者が「メインライン」に統合され、承認された変更がテストラインやリリースラインなどの次のステージに昇格 (または「昇格」) されることが考慮されています。これは、オープンソースソフトウェアのタグ名で次のように典型的に示されます。

main -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-> ...
         \           \              \
test      o-----------o--------------o---------> ...
           1.0 RC1     \ 1.0 RC2      2.0 RC1
release                 o----------------------> ...
                          1.0

ここで重要なのは、テスターがプログラマーに邪魔されることなく作業でき、リリース管理に携わる人にとっては既知のベースラインが存在することです。分散バージョン管理では、異なるラインがリポジトリのクローンになる可能性があり、リポジトリはバージョン管理グラフを共有するため、見た目が少し異なる可能性があります。ただし、原則は同じです。

Web 開発に関しては、ビルド時間は事実上ありません。ただし、段階的に分岐する (またはリリースリビジョンにタグを付ける) と、追跡が困難なバグをチェックしたい場合にロールバックしやすくなります。

しかし、まったく別の問題が関係してきます。それは、サイトの展開にかかる時間です。私の経験では、バージョン管理ツールはアセット管理にはまったく向いていません。合計で数 GB にもなるアートアセットを Subversion で処理するのは、通常、非常に面倒です (Mercurial ではなおさらです)。アセットは、従来の方法で同期およびバックアップされる共有スペースに配置するなど、時間のかからない別の方法で処理する必要がある場合があります (アートアセットは通常、ソースコードファイルのように同時に作業されることはありません)。

ブランチを作成してからマージし直すことと、リポジトリをクローンしてプルし直すことの違いは何ですか (一人の開発者である私にとって)?

ブランチとリモートリポジトリの保持の概念は、集中型バージョン管理ツールよりも近くなっています。これらはほとんど同じものと考えることができます。Mercurial (および Git) では、次のいずれかの方法で「ブランチ」できます。

リポジトリのクローン作成
名前付きブランチの作成

名前付きブランチを作成するということは、バージョン管理グラフの新しいパスリポジトリのクローンを作成するということは、ソースリポジトリを新しい場所にコピーし、新しい道クローンされたリポジトリのバージョン管理グラフこれらはどちらも、バージョン管理における一般的な概念としてのブランチの 2 つの異なる実装です。

実際には、両方の方法の違いは使用方法だけです。リポジトリをクローンするソースコードのコピーを持ち、自分の変更を保存する場所を持ち、名前付きブランチを作成する自分でちょっとした実験をしたいときに。

ブランチをブラウズするのは、コミットの直線的な流れに慣れている人にとっては少々風変わりなので、上級ユーザーはバージョンを操作する方法を知っています。例えば、バージョン履歴が「きれい」になるようにします。さくらんぼ狩りまたはリベース現時点ではgitのドキュメントでは実際に説明されているリベースかなりうまくいきました。

Answer 1