Neat, clean compacted git PR and merge commit, into one commit

Most of the time in repos, we see a PR, then a merge commit of that PR, which just says “Merged pull request #XXX from …”.

But recently, I saw a compacted version of that, where the avatars of the pull requester and the committer overlap, and only one clean commit shows up in the history:

  • git: how to move committed changes from master to branch?
  • GIT push not pushing commits to remote
  • Git: How can I find a commit that most closely matches a directory?
  • Find the git branch or branches from commit id
  • git “lost” my commit, sort of, log giving conflicting results
  • How to remove the first commit in git?
  • enter image description here

    How can this be done?

    What I’ve tried and doesn’t work:

    • deleting the branch after the PR is accepted (PR #755)
    • deleting the repo after the PR is accepted (PR #78)

    UPDATE

    An example of what it looks like when one of my PRs was merged that way:

    enter image description here

    Results in:

    enter image description here

  • How to push 2 branches from local to remote repo in git?
  • Howto add a changed file to an older (not last) commit in Git
  • Setting up GitHub Repo with Netbeans IDE
  • remote git repo digital ocean ubuntu
  • How to stop Visual Studio from closing the solution when changing the active Git repo
  • Version Control on Mac
  • 2 Solutions collect form web for “Neat, clean compacted git PR and merge commit, into one commit”

    2016 April update

    GitHub has introduced an option to squash commits when merging, so you can do this straight from its web UI:

    Squash and merge

    Old solution

    Just found this workflow from the Meteor team (coincidentally, thanks @Emily):

    When you look at a pull request in the GitHub web interface, there’s a very attractive “merge” button. NEVER USE THE MERGE BUTTON. It is an attractive nuisance. It leads to git history that’s way more complicated than necessary: if the PR was filed a month ago, the commit’s parent will be a very old revision that leads to way more lines than necessary in a graphical view of the git history. Plus, if you’re using the merge button, that means that you didn’t ever check out the code and try it yourself! The following is a better way to land pull requests.

    First, in your repository, find the [remote "origin"] section of the .git/config file and add this line:

    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
    

    Make sure to add it BEFORE the existing fetch line. Now, every time you git fetch, you’ll get all the Pull Requests in the repo updated! This is a one-time change that will give you direct access to PRs forever.

    Then you can just git checkout pr/XXX and work with the changes directly. A git push origin after cherry-picking will create the compact PR:

    git checkout pr/32
    # ... test changes ...
    git checkout master
    git cherry-pick pr/32
    git push 
    

    enter image description here

    The only downside is that GitHub won’t automatically delete PR branches when they are closed, but that’s just one click away and in exchange you get a much nicer history.

    If the PR is multiple commits, the best thing to do is to check it out, rebase it onto your development branch, make whatever other changes you need, and merge it back to the development branch with an explicit merge commit. This is similar to what the GitHub merge button does, except that the merge button doesn’t do the VERY IMPORTANT rebase step and so it leaves ugly spaghetti in the project’s git commit history. To do this, run:

    git checkout pr/32; git rebase devel; git checkout devel; git merge --ff-only pr/32
    

    Then test and push.

    If you’d like to combine some of the commits into a single commit, you can use interactive rebase by running git rebase -i devel instead. Some tutorials: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog

    Unfortunately GitHub is not smart enough to detect that you’ve merged a PR by hand, so you’ll need to manually comment and close the issue with a link to the relevant commit. Alternatively, make sure that the merge commit’s message contains Fixed #123.


    UPDATE: A further update was made by Kahmali Rose that enables GitHub to detect that the PR was merged, pretty much as if the evil Merge button was clicked: make sure to rebase and merge instead of cherry-picking.

    If the PR is just a single commit, you can cherry-pick it on to the master branch (or whatever branch you merge PRs into). So, for example:

    $ git checkout -b branch-for-pr master
    $ git pull <fork url> <pr branch name>
    $ git checkout master
    $ git cherry-pick branch-for-pr
    

    Alternatively, you can rebase the PR branch on top of master to allow a fast-forward merge (which will skip the merge commit):

    $ git checkout -b branch-for-pr master
    $ git pull <fork url> <pr branch name>
    $ git rebase master
    $ git checkout master
    $ git merge --ff-only branch-for-pr
    
    Git Baby is a git and github fan, let's start git clone.