We're ending up with a lot of commits like this in our repo:
Merge branch 'master' of bitbucket.org:user/repo
This happens every time a developer syncs his/hers local fork to the top-level repo.
Is there anyway to avoid this merge-commit hell from cluttering all the repo log? Can one avoid them when initiating the pull-requests in some way?
I know I can do git rebase if this is done in my local VM only, is there any equivalence in the GitHub/BitBucket UI?
How do you guys do it?
Rebase Feature Branches Before Merging
If you want to avoid merge commits, you need to ensure all commits are fast-forwards. You do this by making sure your feature branch rebases cleanly onto your line of development before a merge like so:
Rebase also has a lot of flags, including interactive rebasing with the
-i
flag, but you may not need that if you're keeping things as simple as possible and want to preserve all of your branch history on a merge.Use the
--ff-only
FlagAside from rebasing, the use of the
--ff-only
flag will ensure that only fast-forward commits are allowed. A commit will not be made if it would be a merge commit instead. The git-merge(1) manual page says:"Todd A. Jacobs" already mentioned "rebase" is the concept here. This is just a more detailed way of doing things.
Let's say you're on the master branch
You want to make a fix, so create a “fixbranch” which is branched from the master
Maybe you would have worked for a couple of days on this branch and had a couple of commits.
The day you wanted to push your commits to central master repo! Checkout master and get the latest changes from the central master repo
Rebase your fixbranch with the master to have a clean history and resolve the conflicts if any in the local repo itself.
Now fixbranch is uptodate to with the central master, let me merge fixbranch into the master branch
I’m done! let me push local master to the central master
https://git-scm.com/book/en/v2/Git-Branching-Rebasing