webERP Forum

Full Version: Git Rebase
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
With the manner in which we are currently committing to the repo, the history is poluted by ‘merge pull’ and ‘merge branch’ references, making it rather untidy and difficult to follow. I discovered this my experimenting with git log, ref my related post here.

When accepting a Pull Request in GitHub, there is an option within a dropdown to ‘rebase and merge’.

For those of you who are interested, the subject of merging vs rebasing, is explained in this article.

Does any one have any experience of rebasing in git?
Should we consider trialling it, with the aim of keeping a clean project history?
Other than the 'Golden Rule' in the article linked above, are there any dangers or watch-outs?

Would a "squash and merge" for each commit help without having to rebase?
Hi Paul,

A couple of articles worth a read:

Here's a good explanation of squashing:

Quote:Commit squashing has the benefit of keeping your git history tidy and easier to digest than the alternative created by merge commits. While merge commits retain commits like “oops missed a spot” and “maybe fix that test? [round 2]”, squashing retains the changes but omits the individual commits from history. Many people prefer this workflow because, while those work-in-progress commits are helpful when working on a feature branch, they aren’t necessarily important to retain when looking at the history of your base branch.

So squashing would be appropriate for only some PRs, when merging small/individual chunks of work.

There seems to be a strong arguement for sticking with the standard merge commits, rather than rebasing onto the base branch.

I will have a look at extracting a cleaner project history with:
git log --first-parent


The attached is a quick and dirty PHP command line script that sort of produces the change log you are after - needs some more format work. On Linux putting it in a directory ~/bin and then form the root of your webERP running:

~/bin/ChangeLog.phps > doc/Change.log

should at least give you a start.


Hi Tim,

Thanks for that.
The code in the attachment is similar to where I got to.

the --first-parent didn't give the desired results.

I'm now trying the --no-merges option, which should hopefully give the same result as filtering out all commits containing 'Merge pull request'.

git log upstream/master 5423276...HEAD --pretty=format:'| %s |  | %an | %cd | [View]( |  |' --date=format:'%Y-%m-%d' --no-merges