I have a main branch as the root. Depending on the minor version, I create branches in the dev family, such as dev/2.3, dev/2.4, dev/2.5, dev/2.6. Currently, dev/2.6 is the active branch for development.
For a specific task, I branch off from dev/2.6 and work, for example, in tasks/task1. I make commits and push them to the remote tasks/task1 branch. Afterward, I create a pull request from tasks/task1 to dev/2.6. Then, after some time, I create a pull request from dev/2.6 to main.
My question is whether it's possible, after merging dev/2.6 into main via a pull request, to use the
git log
command to find the intersection of commits between dev/2.6 and main?
For instance, I tried
git --no-pager log --oneline main..dev/2.6,
but this command only shows the differences in commits. What I need is to log all the commits made in dev/2.6 that are present in main but not in dev/2.4, dev/2.5, and so on. Is there a git log syntax for displaying the output of a list of commits exist only in dev/2.6 and main??
Thank you advance
You can't exactly get that because if you've merged them together then everything in dev/2.6
is in master
( but not everything in master is in dev/2.6
)
The usual thing I can think of that is close to what you want is 'what did dev/2.6
add since our last release. If you had tagged that release with a version tag this would be even easier.
Here are some ways I can think of that try to get to what you wanted:
In short:
git log main dev/2.6
but likely better done with
git log --graph --abbrev-commit --decorate --date=short main dev/2.6
or whatever log mechanism you prefer.
This says to log both main
and dev/2.6
together so you will see where they diverge and where they merge together and if they diverge after that.
A better thing I would think of using is git shortlog dev/2.6 ^dev/2.5
or git shortlog dev/2.6 ^origin/master
or replace origin/master with the fork point where dev/2.6
broke off from. Which would show you whats on dev/2.6
that wasn't on dev/2.5
or master
respectively.
This really breaks down if you merge master
into those branches multiple times or those branches were merged multiple times back to master. Which is why I take tags when using a flow like this, when I merge dev/2.6
back to master
I would tag that commit as v2.6.1
and if I merged again v2.6.2
etc. in this way I can do git short-log
s between the current state or tag and the prior tag to see what was added.