Correctly merging a feature branch using TortoiseG

Question

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:

Answer 1

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.