2015-11-26 39 views
0

我有6个版本的代码1,2,3,4,5,6在开发中。生产中有一个不同的分支,它是测试版的开发代码。我希望将第4版升级到今天的生产,并在晚些时候将版本6升级为生产。 我怎样才能做到这一点,而无需手动移动任何文件。在Git中选择一个特定的版本并将其移动到不同的分支

+1

由6个版本表示6个分支或6个不同的提交或什么? –

+0

有6个不同的提交。 – kelvy

回答

0

您需要重新绑定本地回购,然后推送到生产分支。

git checkout <develop_branch> 
git rebase <specific commit(4)> 
git push -u origin production_branch_name 

再后来又

git rebase <specific commit(6)> 
git push -u origin production_branch_name 

我希望它能帮助。

1

有这样做的

  • 衍合
  • 合并

@m两种常用的方法。阿宾描述了Rebasing方法。重新编辑允许您重写历史记录并在开发分支视图上进行更改,就像它们在发布分支上进行的一样。有些人更喜欢它,因为它使得最终的树不那么“多枝”。其他人不喜欢它,因为它混淆了真正的发展历史。另外,习惯于传统版本控制的人通常不喜欢重新装订。

另一种方法是将开发分支中的特定提交点提升到发布分支的合并。这种方法的缺点是它迫使你在Release Branch上创建额外的提交来进行合并。

欲了解更多信息,请阅读Merging vs. Rebasing由Atlassian教程。它显示了两种方法。

+0

“这种方法的缺点是它迫使您在发布分支上创建额外的提交来进行合并。”当可以进行快速前进合并时,情况并非如此。只有当发布分支的头部位于功能分支的分支点之前,或者如果与'--no-ff'选项合并,才会创建新的提交。无论如何,最终还是取决于既定的分支政策(你应该有一个并加以执行!)。就我个人而言,我总是更喜欢合并而不是基本版本,因为后者基本上是对你的版本控制撒谎,并且更容易产生混淆。 – sendaran

+0

@sendaran我一般也使用合并。我也将我的存储库同步到GitHub,我相信这会阻止在推送提交时快速转发或重新绑定。我偶尔会使用rebase来修复提交上的哎呀。 – markshancock

相关问题