5

私の会社は新しい SCM システムへの移行を検討しており、git は検討中の最終候補の 1 つです。開始する前に、サポートが必要なユースケースのリストを作成しました。

私が git で確かな答えを持っていないユースケースの 1 つは、単一の「プロジェクト」で複数の「変更セット」を同時に処理することです。

現在の SCM では、「チェックアウト」するときにファイルを「タスク」に関連付けます。変更が別のファイルにある限り、必要な数の「タスク」をアクティブにすることができます。

私の git の経験では、コミットのためにステージングするまで、変更を「変更セット」(コミット) に関連付けません。ただし、ステージング領域は 1 つしかないため、一度に 1 つの「変更セット」に対してのみこれを行うことができます (まだ概要/説明を関連付けることはできません)。

「スタッシュ」もありますが、これの典型的な使用法は、複数の論理的な変更を 1 つのビルドに組み込んでテストを実行することです。そのため、それらは同時に「アクティブ」である必要があります。

この投稿を書いているとき、考えられるワークフローが思い浮かびます。開始時に「変更セット」ごとに 1 つのコミットを作成し、さらに変更を加えたときにコミット + 'rebase -i'/squash を適切なコミットにします。ただし、これは複雑すぎるようで、あまり受け入れられない可能性があります。

より良い方法はありますか？または、このワークフローの使用をやめるべき理由の説得力のある理由 (非常に説得力のあるものにする必要があります) はありますか?

前もって感謝します！

4

2 に答える 2

0

私たちは 1 年以上前に大規模な開発グループとして git に切り替えましたが、非常に役に立ちました。

その通りです。git を使用する場合、一度に使用できる作業スペースは 1 つだけです。

git は、他の SCM のように個々のファイルを実際には追跡しません。名前を変更しても、実際には削除として保存され、新しい名前で追加されます。そのため、タスクを含むファイルを追加するワークフローを変更する必要があります。

代わりに、タスクをブランチとして追加します。git のブランチは非常に軽量で、非常にうまく機能します。ワークフローの例としては、マスター ブランチ (トランク) にリリース コードがあり、新しいタスクが発生すると、マスターのブランチを作成し、そこに変更を加え、検証、テスト、承認、およびマスターにマージします。ブランチを参照として保持するか、クリーンアップすることができます。

サポートおよびパッチを適用する製品のバージョンが複数ある場合は、リリース ブランチ システムを採用する方がうまくいく場合があります。master は次のリリース用に予約されており、バージョンが出荷されたら、release/<version> ブランチを作成します。これにより、後で戻ってバージョンをホットフィックスし、出荷した同じコード ベースを使用していることを確信して再ビルドできます。また、リリース間で行われた作業に関するメトリクスを行うのに適した場所も提供します。

スタッシュは、ブランチを切り替えるときに変更を一時的に保存するために実際に使用されます。たとえば、タスクの作業を開始し、何度か編集した後で間違ったブランチにいることに気付いた場合です。Stash はこれらの変更を保留スペースに移動し、正しいブランチをチェックアウトして変更をワークスペースにポップバックできるようにします。

複数の開発者が同時に作業している場合は、リベース方式を避けてマージ方式を使用することをお勧めします。git リポジトリは、親コミットのハッシュを含む一連のコミットであるため、リベースによってコミットが書き直され、その結果、開発者はリポジトリをホストしているサーバーから再クローンする必要があります。マージ メソッドでは、自分の変更をプッシュする前に、サーバーにプッシュされた他の変更をマージする必要があります。

それが役立つことを願っています。

于 2013-08-20T16:05:24.310 に答える
0

これは、SCM の中核となる必要があるものではなく、UI レベルの機能のように思えます。(たとえば) Eclipse は、使用したい SCM の上にこのような機能をレイヤー化することを知っています。

SCM 自体にそれがないことの難しさは、どのファイルがどの変更に対応するかを覚えていることです。ここで行うべき正しいことは、変更を互いに混合するのではなく、ローカルでブランチを使用することであるという JasonM に同意します。同じファイルに触れます。私が働いたさまざまな場所では、あなたが説明したものと同様のワークフローがありましたが、ほとんどの場合、人々は一度に1つのことに縛られず、ほとんどの場合、ツールを使用するのではなく、どのファイルがどこに行くべきかを覚えていました。変更を混ぜ合わせるのではなく、複数のローカル ブランチを使用できれば、全員が恩恵を受けていたでしょう。

于 2013-08-20T16:56:22.780 に答える