Merge (with squash) all changes from another branch as a single commit

Another option is git merge --squash <feature branch> then finally do a git commit.

From Git merge

--squash --no-squash Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to cause the next git commit command to create a merge commit. This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).

---

Found it! Merge command has a --squash option

git checkout master
git merge --squash WIP

at this point everything is merged, possibly conflicted, but not committed. So I can now:

git add .
git commit -m "Merged WIP"

---

Try git rebase -i master on your feature branch. You can then change all but one 'pick' to 'squash' to combine the commits. See squashing commits with rebase

Finally, you can then do the merge from master branch.

---

Using git merge --squash <feature branch> as the accepted answer suggests does the trick but it will not show the merged branch as actually merged.

Therefore an even better solution is to:

Create a new branch from the latest master , commit in the master branch where the feature branch initiated.

Merge into the above using git merge --squash

Merge the newly created branch into master. This way, the feature branch will contain only one commit and the merge will be represented in a short and tidy illustration.

This wiki explains the procedure in detail.

In the following example, the left hand screenshot is the result of qgit and the right hand screenshot is the result of:

git log --graph --decorate --pretty=oneline --abbrev-commit

Both screenshots show the same range of commits in the same repository. Nonetheless, the right one is more compact thanks to --squash.

Over time, the master branch deviated from db.

When the db feature was ready, a new branch called tag was created in the same commit of master that db has its root.

From tag a git merge --squash db was performed and then all changes were staged and committed in a single commit.

From master, tag got merged: git merge tag.

The branch search is irrelevant and not merged in any way.

https://i.stack.imgur.com/7QK7i.jpg

---

2020 updated

With the --squash flag it looks like two parallel branches with no relation:

https://i.stack.imgur.com/I2Bhx.png

Sorting commits related to date looks like:

https://i.stack.imgur.com/g9F0X.png

Personally, i don't like --squash option, try this trick, maybe it fits your needs, i use it for small projects:

git init git checkout -b dev Several commits in dev After you did some great commits in dev(but not merged to master yet), if you do not want all commits copied to master branch, then make intentionally change something in master and (add some empty lines in README file and commit in master), git merge dev It results merge conflict(empty lines in README), resolve it, commit with new message you want, and you are DONE. Here is the visual representation of it.

null commit for intentionally merge conflict, name it anything you prefer

https://i.stack.imgur.com/pgABg.png

---

I have created my own git alias to do exactly this. I'm calling it git freebase! It will take your existing messy, unrebasable feature branch and recreate it so that it becomes a new branch with the same name with its commits squashed into one commit and rebased onto the branch you specify (master by default). At the very end, it will allow you to use whatever commit message you like for your newly "freebased" branch.

Install it by placing the following alias in your .gitconfig:

[alias]
  freebase = "!f() { \
    TOPIC="$(git branch | grep '\\*' | cut -d ' ' -f2)"; \
    NEWBASE="${1:-master}"; \
    PREVSHA1="$(git rev-parse HEAD)"; \
    echo "Freebaseing $TOPIC onto $NEWBASE, previous sha1 was $PREVSHA1"; \
    echo "---"; \
    git reset --hard "$NEWBASE"; \
    git merge --squash "$PREVSHA1"; \
    git commit; \
  }; f"

Use it from your feature branch by running: git freebase <new-base>

I've only tested this a few times, so read it first and make sure you want to run it. As a little safety measure it does print the starting sha1 so you should be able to restore your old branch if anything goes wrong.

I'll be maintaining it in my dotfiles repo on github: https://github.com/stevecrozz/dotfiles/blob/master/.gitconfig

---

git merge --squash <feature branch> is a good option .The "git commit" tells you all feature branch commit message with your choice to keep it .

For less commit merge .

git merge do x times --git reset HEAD^ --soft then git commit .

Risk - deleted files may come back .

---

You have a master branch and feature branch. You have lots of commits on a feature branch. You don't want all commits of the feature branch to appear on the master's commit history. Follow these steps

Create a new branch from the latest master code and you are in that branch

git checkout -b latest_MCode

Now merge your feature branch into latest_Mcode branch

git merge --squash feature

Do commit without -m param

git commit # without -m

An editor should be a popup with all the commit logs, and files changed from the feature branch. You can see all feature branch commits here. If you want you can delete everything, and write only one line of the commit message you want to show after merging into master. Press i then write your message then press Esc->:wq->Enter to Save and quit the editor. 4. Merge your newly created branch into master

git checkout master
git merge latest_Mcode
git push

You are done! The original answer can be found at GithubLink

---

You can do this with the "rebase" command. Let's call the branches "main" and "feature":

git checkout feature
git rebase main

The rebase command will replay all of the commits on "feature" as one commit with a parent equal to "main".

You might want to run git merge main before git rebase main if "main" has changed since "feature" was created (or since the most recent merge). That way, you still have your full history in case you had a merge conflict.

After the rebase, you can merge your branch to main, which should result in a fast-forward merge:

git checkout main
git merge feature

See the rebase page of Understanding Git Conceptually for a good overview

---