什么时候建议使用git rebasevs. git merge？
成功改造后我还需要合并吗？
我和其他开发人员一起在一个项目上使用Git几个月了.我有几年的SVN经验,所以我想我给这段关系带来了很多包袱.
我听说Git非常适合分支和合并,到目前为止,我只是没有看到它.当然,分支很简单,但是当我尝试合并时,一切都变得很糟糕.现在,我已经习惯了SVN,但在我看来,我只是将一个低于标准的版本系统换成了另一个.
我的搭档告诉我,我的问题源于我不顾一切地合并,并且我应该在很多情况下使用rebase而不是合并.例如,这是他所规定的工作流程:
clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature
基本上,创建一个功能分支,始终从主分支到分支,并从分支合并回主分支.需要注意的重要一点是,分支始终保持在本地.
这是我开始的工作流程
clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish …我们在最新的iOS项目中使用Git Flow,我正在尝试使用QA的方式,以便他们可以测试最新版本,以及测试新功能,而无需担心修复了哪些错误哪个分支.
目前,他们已经在release/v1.0.1分支机构进行了测试,该分支机构已经修复了多个错误release/v1.0.同时,我一直致力于为v1.1发布计划的新功能,但同时从develop分支机构分支出来release/v1.0.1,因此没有任何错误修复.
今天,QA部门希望将我的新功能用于试驾.但是,如果我从我的分支创建它们,那么他们已经重新测试和关闭的错误修复都不在那里.因此,我会收到大量关于已经重新引入的错误的投诉和恐慌......我想避免哪些错误!
那么,让他们测试这个的最佳方法是什么？我可以合并release/v1.0.1到我的功能分支,但是我应该确保在发布develop之前我没有合并回来release/v1.0.1...而且我想在一定程度上,这打破了Git Flow方法.我可以创建一个全新的分支,仅用于QA测试,它将我的功能合并release/v1.0.1,但是我如何处理他们在这个分支上找到的任何错误？在QA之后,我将它合并到哪里？
最重要的是,我必须考虑构建号和版本号,以便它们有意义.目前,版本号是用于发布的版本号,并且构建号随着QA的每个新构建而递增.但是,如果他们从两个独立的分支接收构建,我最终可能会发生构建数字冲突,这会引起混淆.
处理这些问题的最佳方法是什么？