私はバザーが新しく、Subversionとgitのバックグラウンドから来ています。私は基本的なコンセプトを実践的に把握していたと思っていましたが、私の最初の大きなコミットで既に障害が発生しました。Bazaar:プル - マージ - コミット後のメインラインでのバブルのマージ
プロジェクトはLaunchpadでホストされています。私はローカルブランチ(bzr branch
)を作成しました。私は変更を加え、新しいファイルを追加し、他のファイルを改名した。暫定的にチームの他の人がコミットして変更をプッシュしました。私はローカルに自分の変更をbzr commit
3. Team Member A
2. Me (trivial commit of .bzrignore)
1. Original commit
今朝:この時点でコミットの歴史は、このようなものを見ました。コミット番号は3と報告されました。私は(間違って)私はサーバーと同期するときに調整されると仮定しました。私はbzr merge
をした
Using saved parent location: bzr+ssh://bazaar.launchpad.net/... bzr: ERROR: These branches have diverged. Use the missing command to see how. Use the merge command to reconcile them.
:私はbzr pull
をしたとき、私はこのメッセージが表示されました。競合は検出されませんでしたが、ローカルブランチで3つのファイルが変更されたままになりました。私は検査し、コミットとして私に報告されたコメント付きでコミットしました。その後、エラーは報告されていないbzr push
を実行しました。
4. My merge commit
2.1.1 Team Member A
3. My commit this morning
2. My .bzrignore commit
1. Original commit
シリアライズされた幹線を維持し、これらの気泡をマージ回避するために、ここで高い欲求があります:今
コミットの歴史は(bzr log --include-merges
)このようになります。 (ちなみに、Launchpadには2.1.1コミットが表示されないので、上書きしたように見えます。)このような状況を避けるためのベストワークフローは何ですか?私は最初に引っ張ったのか?私は他の人のコードを私のローカルのコミットされていない変更にマージすることに注意しています。
さらに、rebaseはgitで一般的に使用されていますが、Bazaarの世界で一般的に承認されていないようです。 bzr-rebaseプラグインの使用を避けることができれば、それは素晴らしいことです。
、また、あなたのブランチの設定でappend_revisions_onlyオプションを設定することで、将来的にこの問題を回避することができます。このセットでは、あなたの例のような改訂の順序を並べ替えるときに、コミットが進まないようにします。 – dOxxx
はい、私は私の投稿後にこれを提案する答えを見ました:http://stackoverflow.com/questions/5413602/monotonically-increasing-bazaar-trunk-revision-numbersしかし、私たちはBazaarのベストプラクティスに興味があります。 "正しい"ものの私たちの考えに合ってください。 –
off挙動はほとんど常にユーザーを驚かせるので、append_revisions_onlyをデフォルトで有効にする必要があるかどうかに関して実際には議論があります。したがって、ハックまたは非標準的な動作とは考えないでください。これは、セキュリティにもっと似ていて、将来これでもう驚かないのです。 – dOxxx