When pushing to the git repo, please avoid merge commits...

["Darryl L. Pierce" <dp...@redhat.com>]

A request for all, please avoid doing merge commits on your Git repo.
When these hit the shared repo it can cause Git to try and "fix" [1] the
commit when rebasing.

The way I do commits with Git is to rebase my work branch on master
before merging it into master. That way it's a true merge and not a
merge commit. To do this:

1. Rebase your work branch:

 task-branch $ git rebase -i master

2. Fix any merge issues on the work branch until you get a clean set of
   commits.
3. Switch to master and then merge your branch:

  task-branch $ git checkout master
  master-branch $ git merge task-branch

Thanks.


[1] On my task branches I use autofix to merge changes back to the
appropriate previous commit in my branch. When I'm ready to merge them I
use "git rebase -i HEAD~[some # of commits] --autofix". Git then takes
all of the autofix commits and puts them after the appropriate commit to
merge together.

If I a merge commit is accidentally included in there then git will try
to rebase that merge commit and all hell can break loose.


-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

Re: When pushing to the git repo, please avoid merge commits...

["Darryl L. Pierce" <dp...@redhat.com>]

On Tue, May 12, 2015 at 02:10:59PM -0400, Alan Conway wrote:
> On Mon, 2015-05-11 at 09:36 -0400, Darryl L. Pierce wrote:
>     master-branch $ git merge --ff-only task-branch
> 
> That will refuse to merge unless the merge is a "fast-forward", which is
> the simple "copy my commits to the end of trunk" that we want. It is
> just a safety check - if you do what Darryl says it has no effect, but
> if you forgot to rebase properly git will complain instead of creating
> an unintended merge commit.

+1 I've worked on a project that flat out rejects any commits that
aren't FF. And it was very simple and clear to do a git --blame to look
up where changes came from.
 
> > http://mcpierce.blogspot.com/2012/08/git-fixup-and-autosquash.html
> > 
> autosquash! Lovely! Git is full of nice surprises.

When I learned the core set of tricks I use for working (interactive
rebase, autofix/autosquash, bisect, cherry picking) is when I finally
felt I was working with something more than just a version control
system, but a power tool. :D
 

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

Re: When pushing to the git repo, please avoid merge commits...

[Alan Conway <ac...@redhat.com>]

On Mon, 2015-05-11 at 09:36 -0400, Darryl L. Pierce wrote:
> On Mon, May 11, 2015 at 09:23:27AM -0400, Darryl L. Pierce wrote:
> > A request for all, please avoid doing merge commits on your Git repo.
> > When these hit the shared repo it can cause Git to try and "fix" [1] the
> > commit when rebasing.
> > 
> > The way I do commits with Git is to rebase my work branch on master
> > before merging it into master. That way it's a true merge and not a
> > merge commit. To do this:
> > 
> > 1. Rebase your work branch:
> > 
> >  task-branch $ git rebase -i master
> > 
> > 2. Fix any merge issues on the work branch until you get a clean set of
> >    commits.
> > 3. Switch to master and then merge your branch:
> > 
> >   task-branch $ git checkout master
> >   master-branch $ git merge task-branch

Another tip, when merging to master use:

    master-branch $ git merge --ff-only task-branch

That will refuse to merge unless the merge is a "fast-forward", which is
the simple "copy my commits to the end of trunk" that we want. It is
just a safety check - if you do what Darryl says it has no effect, but
if you forgot to rebase properly git will complain instead of creating
an unintended merge commit.

> 
> http://mcpierce.blogspot.com/2012/08/git-fixup-and-autosquash.html
> 
autosquash! Lovely! Git is full of nice surprises.

Re: When pushing to the git repo, please avoid merge commits...

["Darryl L. Pierce" <dp...@redhat.com>]

On Mon, May 11, 2015 at 09:23:27AM -0400, Darryl L. Pierce wrote:
> A request for all, please avoid doing merge commits on your Git repo.
> When these hit the shared repo it can cause Git to try and "fix" [1] the
> commit when rebasing.
> 
> The way I do commits with Git is to rebase my work branch on master
> before merging it into master. That way it's a true merge and not a
> merge commit. To do this:
> 
> 1. Rebase your work branch:
> 
>  task-branch $ git rebase -i master
> 
> 2. Fix any merge issues on the work branch until you get a clean set of
>    commits.
> 3. Switch to master and then merge your branch:
> 
>   task-branch $ git checkout master
>   master-branch $ git merge task-branch
> 
> Thanks.
> 
> 
> [1] On my task branches I use autofix to merge changes back to the
> appropriate previous commit in my branch. When I'm ready to merge them I
> use "git rebase -i HEAD~[some # of commits] --autofix". Git then takes
> all of the autofix commits and puts them after the appropriate commit to
> merge together.
> 
> If I a merge commit is accidentally included in there then git will try
> to rebase that merge commit and all hell can break loose.

Dug out this old post to my blog that has my steps for doing the commits
on a task-based branch:

http://mcpierce.blogspot.com/2012/08/git-fixup-and-autosquash.html

I've added a new comment on this post with the steps for doing an
autofix commit, but will write up a newer version of the post to include
this inline.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/