Git Tagging & Gitflow: What happens when you merge old commits

Question

I'm getting very confused about tagging and need to clarify something. For source control I like to use the 'gitflow' workflow. I commonly make feature branches off of develop that, once complete, I merge back into develop, and then during a release cycle, a release branch will be made off of develop and eventually find its way into master. Once merged into master, I tag the top commit with a version number.

Imagine the following scenario:

The master branch is sitting with a tag of 'v1.0', which has all the latest code from develop. Another team member pushes a branch he has been working on for weeks into develop. Some of this branches commits pre-date the tagged creation date. Eventually a release branch is made with these old commits and finds its way into master via a merge. If I look at the git history, I can see the old commits further back in the master branches log.

If I now tag the top commit (the merge commit) as 'v1.1', where does this leave my project? If I checkout the tag 'v1.0' will it now include the old commits as they're further back in the history? My reason for tagging is I can jump back and forth between versions if necessary, but if old commits are going to throw a spanner in the works I'm not sure what to do!

Answer 1

I've asked this question myself today, so I read some docs and made some test commits.

Take a look at my test repository https://github.com/pixelbrackets/hello-github-world/

I've made nine commits in »version.txt«, adding consecutive numbers to the file:

1. Two commits in the master
2. Tagged release version 0.1.0 (with two commits)
3. Switched to a feature branch
4. Created two commits in the feature branch
5. Switched back to master
6. Created two commits in the master
7. Tagged release version 0.2.0 (with now four commits, not including the feature yet)
8. Switched back to the feature branch
9. Created two more commits in the feature branch
10. Merged the master into the feature branch and resolved the merge conflict
11. Merged the feature branch in to the master
12. Tagged release version 0.3.0 (with nine commits - four from master, four from feature branch, one merge commit)
13. Removed the feature branch

The question was: what happens to the two pre-dated commits from step four, after they get merged back in the master?

Well, as Oliver Charlesworth already explained in his comment above, the commits are not connected through dates. What matters is the topological order. When you view a git log however, then the commits are shown in reverse chronological order by default. This may lead to this confusing situation.

To view the git history in topological order you may use a graphical tool like »gitg« or type »git log --topo-order --graph« on the commandline.

Here is a screenshot of my test commits, made with »gitg«:

As you can see on the right column, all commits are in consecutive order. But altough I deleted the feature branch, the graph still clearly shows that commits 3,4,7,8 (Step 4 & 9) were made separately. The tag names are shown next to the corresponding commits.

When I checkout the second tag, then the commits of step four are not included.

$ git checkout 0.1.0
HEAD is now at d76c450... Commit 2 Master 2
$ cat version.txt 
1
2
$ git checkout 0.2.0
HEAD is now at 3eeec86... Commit 6 Master 4
$ cat version.txt 
1
2
5
6
$ git checkout 0.3.0
HEAD is now at 699c6f1... Fix Merge Conflict
$ cat version.txt 
1
2
3
4
5
6
7

So, no, git tags wont include commits which are created earlier and merged into the branch at a subsequent date. You may use tags as release versions, just as you would expect them to work.