Squash commits on master but separate commits on feature branch?

Let’s say Im working on a feature, in a branch called foo_baz.

I commit multiple times as I work on the feature.

  • What are the underlying git merge processes within the staging area?
  • file grained vs line grained version control systems
  • Is there a script that provides the equivalent to git-bisect for Perforce (p4)?
  • Git-Svn: Retain commit timestamp after dcommit
  • Heroku Java app crashing locally but not on the web
  • Does git pull always create a merge commit?
  • I periodically push foo_baz, a remote-tracking branch, to a remote repo. IE origin/foo_baz.

    I progress to the point where I want to merge all commits from foo_baz into master and push to origin/master. Here’s the question:

    Can I merge foo_baz into master such that all commits are still separate in foo_baz‘s histroy, but that in master‘s history, they are all one, squashed commit?


    I’m a bit of a git beginner, so please forgive me if there’s something totally obvious that I’m missing. I dug around on the web but couldn’t find a direct answer to my question.

  • How can I move a tag on a git branch to a different commit?
  • git clone from local to remote
  • Is there a difference between git rebase and git merge --ff-only
  • GIT add revert in my case (keep changes)
  • Can't remove file from git commit
  • How to measure IOPS for a command in linux?
  • 3 Solutions collect form web for “Squash commits on master but separate commits on feature branch?”

    You might indeed be looking for --squash (as in the other answers), but you might be looking for --no-ff instead.

    Here’s the difference between the two. Suppose you start with two commits:

    A --- B                <-- branch "master", when you start

    and then make two more on your new branch foo_baz:

    A --- B                <-- master
              C --- D      <-- foo_baz

    Now (once back on master), you have these two options (among others). You can git merge --squash foo_baz && git commit which will give you the following:

    A --- B ----------- E  <-- master
              C --- D      <-- foo_baz

    or you can git merge --no-ff:

    A --- B ----------- E  <-- "master" after merge --no-ff
            \         /
              C --- D      <-- foo_baz

    Both give you a new commit E—in the first case, from the separate git commit command—but the first one suppresses the multi-parent-ing action, so that in end, when you look back on this a year from now, it looks like you just copied all the changes from the branch. The tree (all the files you get when you git checkout the branches) will be the same in both D and E (in this particular case anyway, where there are no changes to B on master before the merge action), but they’re different commits.

    The difference from a straight git merge is that the latter will generally produce a “fast forward”, which looks like this:

    A --- B
              C --- D      <-- foo_baz, master

    where the angled line can be straightened out, giving you a history where both branches look exactly the same.

    I think what you want is something like this:

    git merge --squash foo_baz
    git commit

    I think you’re looking for the --squash flag.

    Git Baby is a git and github fan, let's start git clone.