Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Git Rebase
04-11-2018, 10:35 PM
Post: #1
Git Rebase
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?

Andy.

https://www.linkedin.com/in/andrewcouling
Find all posts by this user
Quote this message in a reply
04-12-2018, 10:23 AM
Post: #2
RE: Git Rebase
Would a "squash and merge" for each commit help without having to rebase?
Find all posts by this user
Quote this message in a reply
04-12-2018, 09:50 PM (This post was last modified: 04-12-2018 09:56 PM by afcouling.)
Post: #3
RE: Git Rebase
Hi Paul,

A couple of articles worth a read:

https://developer.atlassian.com/blog/201...at-debate/
https://blog.github.com/2016-04-01-squash-your-commits/

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:
Code:
git log --first-parent

Andy.

https://www.linkedin.com/in/andrewcouling
Find all posts by this user
Quote this message in a reply
04-12-2018, 10:41 PM (This post was last modified: 04-12-2018 10:51 PM by falkoner.)
Post: #4
RE: Git Rebase
Andy,

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.

Tim


.gz  ChangeLog.phps.tar.gz (Size: 279 bytes / Downloads: 2)
Visit this user's website Find all posts by this user
Quote this message in a reply
04-13-2018, 03:02 AM
Post: #5
RE: Git Rebase
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'.

Code:
git log upstream/master 5423276...HEAD --pretty=format:'| %s |  | %an | %cd | [View](http://github.com/webERP-team/webERP/commit/%h) |  |' --date=format:'%Y-%m-%d' --no-merges

Andy.

https://www.linkedin.com/in/andrewcouling
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)