2011-07-01 7 views
4

私たちはMercurialの初心者です。評価などを行い、現実に使用しています。Mercurialチームでの作業

問題は私たちがチームで使用している方法です。

私たちはいくつかの研究を行いましたが、このリンクは同じ問題のように見えますが、解決策は実際には少し複雑に見えます。 http://blogs.oracle.com/tor/entry/mercurial_tip_checking_in_regularly

私たちの問題は、同じソフトウェアプロジェクトに取り組んでいるチームで、何も新しいことはありません。私たちはゲートキーパーモデルを使用してプッシュします。

1人のチームメンバーが「ファイルA」に大きな変更を加えていますが、これは少し時間がかかり、変更をローカルにコミットしています。

ファイルAの作業中に、問題を整理してファイルBの問題を修正するように求められます。これは別の開発者を支援するためです。彼はどうやってこれをすることができるの?彼は、ファイルAがゲートキーパに入るのに不完全な変更は望んでいませんが、ファイルBの変更をプッシュする必要があります。

+2

枝は__really__安価であることに注意してください。あなたが得た答えの1つとして、開発者に共有ゲートキーパーのリポジトリから自分のマシン上の別のブランチをクローンさせるようにしてください。 – Omnifarious

答えて

6

開発者にFile_B_Fixという名前の新しいローカルディレクトリを作成させてもらい、共有リポジトリをコピーしてください。修正をファイルBに作成し、変更を共有リポジトリにプッシュバックします。

1

私は名前付きブランチを使いたいです。現在、新しいフィーチャーごとに名前付きブランチを作成しています。次に、バグ修正が必要な場合は、updateコマンドを使用して、安定しているかデフォルトに(あなたが呼びたいものに)ジャンプできます。クローンを使用することもできます。相違点についていくつか考えてみてください。 Mercurial: Named Branches vs Multiple RepositoriesA Guide to Branching in Mercurialを参照してください。

0

この具体的なケースでは、柔軟性を高めるため、一般的にはMercurial Queuesを学んで使用することをおすすめします。これは、Mercurialを使用するすべての人がワークフローに加えるべき貴重なツールです。あなたのケースでは

、そのチームのメンバーはどうなる:

hg qinit -c 
hg qnew changes-to-fileA # creates a new patch with the outstanding changes 
hg qnew changes-to-fileB # creates a new empty patch 

# work on file B 

hg qrefresh    # updates the patch with changes to file B 

はレポにこれらの変更をコミットする方法についてMQ tutorialをお読みください。

これに代わる方法は、shelve拡張子です。これにより、未解決の変更を一時的に取り除き、ファイルBを処理して変更を復元することができます。しかし、MQを使用すると、多くのメリットがあります。

関連する問題