1

私のオフィスでは Git に移行しています。現在、Git-SVN を使用して次のワークフローを実行しています。

 git svn rebase 
 git checkout -B FEATURE_NUMBER

ローカルでコミットしながら仕事をする

git checkout master
git svn rebase
git merge --squash FEATURE_NUMBER

競合を修正し、テストを実行するなど

git commit -a -m "Actual Commit Message for everyone else"
git svn dcommit

それは問題なく動作しますが、私はオフィス間を移動して別のコンピューターを使用することもあるので、未完成の場合はプライベート GitHub リポジトリを使用してブランチをプッシュしています。

そのためのワークフローは次のとおりです。

 git svn rebase 
 git checkout -B FEATURE_NUMBER

ローカルでコミットしながら仕事をする

オフィスを移転したい

git push オリジン FEATURE_NUMBER

新しいオフィスに行く

 git svn rebase 
 git checkout -B FEATURE_NUMBER
 git pull origin FEATURE_NUMBER

ただし、それに関する問題は、競合のヒープが発生することです。Github では、最初に本社に移転して以来、チームが行ったすべての変更を元に戻したと考えているようです。基本的に、SVN サーバーからの新しいコミットよりも、GitHub の古いコミット (つまり、リベースの前から) を優先します。

うまく融合させる方法はありますか？

4

1 に答える 1

1

git svn rebase機能ブランチでしばらくやったことはありますか? git svn rebaseは実際のリベースを行うことに注意してください。つまり、別の親を持つ新しいコミットを作成します。git pullまた、マージが自動的に作成されることにも注意してください。FEATURE_NUMBER競合は、ツリー内の 2 つの異なる場所からの異なるコミットで見つかった同じ変更 (オフィスを移動する前のもの) をマージしようとした結果です。

この問題を回避するには、プルを回避し、代わりにgit fetch. 新しいコミットを にフェッチするだけなorigin/FEATURE_NUMBERので、次のように、好きなことを行うことができます。

# fetch new work from GitHub into origin/FEATURE_BRANCH
git fetch origin
# reset FEATURE_NUMBER to the latest GitHub
git checkout -B FEATURE_NUMBER origin/FEATURE_NUMBER
# reparent those commits on top of the latest svn
git svn rebase
于 2012-09-11T05:45:24.260 に答える