使用 TortoiseGit 正确合并功能分支 [英] Correctly merging a feature branch using TortoiseGit
问题描述
我正在学习使用 Git，但是，我想保持 线性 的历史.我刚刚完成了我的第一个功能分支.
我现在准备将它合并到我的主分支中.
我知道正确的方法是重新设置功能分支或其他东西，然后合并它?无论哪种方式，都有一些合并过程，以便您保留提交历史或其他内容.
我的主分支叫做master.功能分支称为import-publictalk-names.
发现这个问题:
我想我现在已经成功地做到了:
当你创建一个新的分支时，你基本上可以并行工作.但是，每当您合并(如
图 2. 使用默认选项(即快进合并)将 reorder-commits 合并到 master 中:
图 3. 使用非快进"选项将 reorder-commits 合并到 master 中，注意带有Merge branch ..."消息的合并提交和两个父提交:
图 4. 通过(硬)将 master 分支重置到其旧位置来恢复"您的分支，使历史再次线性化.
I am learning to use Git, however, I'd like to keep a linear looking history. I have just finished my first feature branch.
I am now ready to merge it into my master branch.
I understand that the right way to do this is to rebase the feature branch or something and then merge it? Either way, there is some process for merging so that you retain commit history or something.
My main branch is called master. The feature branch is called import-publictalk-names.
Found this question:
Merging code branch to master using tortoisegit
So I think I have managed to do it correctly and this can be closed:
I think I have successfully done it now to my liking:
When you create a new branch you can basically work in parallel. However, whenever you merge (as described in https://stackoverflow.com/a/38203822/3906760) all changes from the feature branch are integrated into your current branch. At this point you have a synchronization point which somehow puts your changes into the history of your current branch (master). - Just in case a file is edited on both branches, there can be a conflict which needs to be resovled before an extra commit to finish the merge.
When you don't have an additional commit on your master branch (cf. Picture 1), a normal merge will result in a straight line which is not distiguishable from any commit which are on the master branch (the master branch label will just be assigned to the feature branch commit, cf. Picture 2). If you want to see a parallel line on the log which is optically merged into the master branch with a merge commit (a commit with has two parents instead of just one, cf. Picture 3), you need to enable the "No fast forward" merge option. - If there is a parallel commit on the master branch, you will always get a merge commit (unless you select "fast-forward only"). - Just as a side node: The files have all the the same content in picture 2 and 3, the only difference is in the meta-data in git.
Also, there are people who don't like that commits are visually interleaved as in your screenshot. From the git perspective normal merging is perfectly fine. But if you want to have a straigt line of commits, you need to rebase your feature branch on top of the branch into which you want to merge your changes (then you are in the case of Picture 1). After that merge the rebased branch (as fast-forward merge or non-fast-forward merge).
In order to make your history linear, "just" revert the merge by resetting master to the last commit (the parallel one, cf. Picture 4) with a "hard reset". Then checkout your feature branch and rebase it on top of master (click on the master branch in log dialog and click on "Rebase ... on this...". Then you have the case of Picture 1 and you can merge again.
Picture 1. Simple development on the reorder-commits branch with no parallel commits on master:
Picture 2. Merged reorder-commits into master with default options (i.e., fast-forward merge):
Picture 3. Merged reorder-commits into master with "non-fast-forward" option, note the merge commit with the "Merge branch ..." message and two parent commits:
Picture 4. Make the history linear again, by "reverting" your branch by (hard) resetting the master branch to its old position.
这篇关于使用 TortoiseGit 正确合并功能分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
