To get a history of merge commits made in the current branch, use the following command:
git log --merges
To get a history of merge commits made in the current branch, use the following command:
git log --merges
can I offer another suggestion, that you search for the branches with head revisions that are included in the history of your develop branch ? It protects you from losing changes that were committed to a branch that had previously merged.
Something along these lines :
git log --oneline develop > /path/develop.log
# Just in case anyone's broken process and committed a bugfix directly to a release branch
git branch -a | grep 'remotes\/origin\/release\/' | while read branch;
do
git log --oneline $branch > /path/"$branch".log;
done
git branch -r | while read branch;
do
git log -1 --oneline $branch | awk '{print $1}' | while read commitID;
do
if grep -rq $commitID "/path/" ;
then
echo "git push --delete origin \"$branch\" Deletable $commitID";
break;
#else
# the head revision hasn't been committed to any 'master' branch
# echo "$branch $commitID";
fi;
done;
done
Situation:
-
My company purchased the code and rights to an existing software product in a acquision.
-
An outsourced dev firm "forked" the original GitHub repo for the initial owners by exporting the current HEAD, and committing it to a new GitHub repo as the initial commit.
-
Several additional commits, branches, and merges have happened since then in the new repo
Goal:
Have one repo with the full history from the original repo plus all the changes from the new repo.
I have access to, but not ownership of, the source repo.
How can I merge the history back into the repository?
Hi everyone, I'm having trouble understanding why my git merge is rebasing and the entire commit history of the branch that is being merged is getting added to the branch I'm merging into...
[git-test]$ git reflog
16b6ee0 (HEAD -> main, feature-a) HEAD@{0}: merge feature-a: Fast-forward
beae265 HEAD@{1}: checkout: moving from feature-a to main
16b6ee0 (HEAD -> main, feature-a) HEAD@{2}: commit: imported feature a in index
000b168 HEAD@{3}: commit: coded feature a
00b2791 HEAD@{4}: commit: initialised empty feature-a file
beae265 HEAD@{5}: checkout: moving from main to feature-a
beae265 HEAD@{6}: commit: coded index file
d0e5c98 HEAD@{7}: commit (initial): created index file
[git-test]$ git log --graph --oneline --all
* 16b6ee0 (HEAD -> main, feature-a) imported feature a in index
* 000b168 coded feature a
* 00b2791 initialised empty feature-a file
* beae265 coded index file
* d0e5c98 created index fileIt looks like the first merge was a fast-forward, and the second one was a three-way merge.
Explanation
Git has two versions of merge: fast-forward and three-way. (There are other versions, but that is not what happened here.) The default behavior is to do a fast-forward merge when possible, and otherwise do a three-way merge.
A fast-forward merge can take place when the commit that is being merged has the current position of the branch in its history (you can force this behavior with the option --ff-only, which will cause the merge to fail when fast-forward is impossible). For example:
A - B - C - D <-master
\
E - F - G <- branch-a
Executing git merge (with default settings) will result in
A - B - C - D - E - F - G <- branch-a <-master
You will also not get a chance to edit the merge commit because there is none.
A three-way merge when your other branch diverges from master (not just ahead):
A - B - C - D - E - F - G <-master
\
E1 - E2 <- branch-b
In this case, Git cannot just move the pointer of master from G to E2 because that will get rid of the changes that were made in F and G. When a three-way merge happens, it creates a commit that has two parents, and also has a commit message. Now, master can be moved to this commit. (Notice that in this situation, master and branch-b do NOT point to the same commit.
A - B - C - D - E - F - G - H <-master
\ /
E1 - E2 <- branch-b
If you want to have a linear history then you need to use rebase, but be forewarned that if anybody else has seen your branch commits this may lead to issues that are beyond the scope of this answer. Using rebase will involve two steps, rebasing and then fast-forward merge. So, instead of merging you first execute the following while on branch-b, git rebase master. This creates new commits that are copies of the old commits, i.e., the same change-set, author information and message, but new committer information and parent history. (I call the commits E1' and E2' in the illustration to indicate that they are just copies.) The old commits will exist until they are garbage collected, but will not be reachable unless you look at the reflog.)
A - B - C - D - E - F - G <-master
\ \
E1 - E2 \
E1' - E2' <- branch-b
Executing git checkout master; git merge --ff-only branch-b will now fast-forward your changes into master, thereby giving you a linear history.
A - B - C - D - E - F - G - E1' -E2' <-master <- branch-b
Use rebase instead of merge. From the tutorial:
If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
I imagine that the changes from your Branch-B cannot be merged using fast-forward merging into the master. In such cases a three-way-merge is done:
Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent.
I would always rebase my commits before commiting them into the master to keep the linear history.