patik/how-to-squash-commits-in-git.md

git checkout master && git fetch && git pull

git pull is a synonym for git fetch && git merge so your version will git fetch twice, although the second time it likely won't fetch anything, so it probably doesn't matter.

git merge feature_branch
I think you are better to

• checkout the feature_branch
• merge master into it
• squash your commits on the feature_branch
• push your feature_branch to the remote (origin or other)
• create a pull request from the remote feature_branch to the remote master (origin/master).
• Someone else reviews & merges your (squashed) commit to origin/master.

The reason I say that is because if you've merged your feature_branch to your local master, how do you then push it to origin master with an opportunity for someone else to review & merge your commit? I don't think you can create a pull request from your local to a remote, only push directly,
Although, workflows in git differ, so this might work for you if no-one is reviewing the code and you are happy to just push direct to origin/master. If that's the case, creating branches is more of a convenience for working on multiple discrete changes and being able to switch between them cleanly.

👍

cool

@davoscollective Thanks for the feedback. I removed the extraneous git fetch.

As for the second part, you are correct that it removes the opportunity for a pull request and probably doesn't work for many teams' workflows. I do have a note/warning in the text about this, however I've made it bolder so hopefully it saves some people a headache.

Very useful )) Thanks.

Ta, very useful. I like the first one, and useful even without pushing to master:

git checkout master && git pull
Merge your feature branch into the master branch locally:

git merge feature_branch

Reset the local master branch to origin's state:

git reset origin/master

Now all of your changes are considered as unstaged changed. You can stage and commit them into one or more commits.

At this point, create the branch you're going to create a pull request for:

git checkout -b merging_branch

git add . --all
git commit

git push --set-upstream origin merging_branch

Then create a pull request etc.

Pro tip: do NOT squash file renames together with file edits. You will end up with lost ancestry history.

Good article.

git reset --soft HEAD~3
git commit -m "New message for the combined commit"

I am guessing that it is assumed, but you should probably add an explicit "git add" between these statements. Changing -m to -am may not be sufficient if there are new files that were previously un-versioned.

Is it still possible to squash all commits in the remote branch if I have already pushed multiple commits to it ?

@kkannan-carecloud, yes, you'll have to do a "git push -f" but be aware that this will cause problems for people that have already pulled that branch.

Why would you use the first option over git merge --squash?

I used to use the second option, but nowadays a much easier way to squash commits I use (for me, at least) is git rebase HEAD~[x number of commits] -i

I usually do squashing while interactive rebase.

git rebase -i origin/master your-branch

Your 2nd solution was the only one I could find on the internet, which shows how to do NON-interactive squash on a single branch (not merging).

I had to squash 134 commits, so interactive squash was not attractive for me... 😋

can I squash commits I made on separate branches?

can I squash commits I made on separate branches?

Do you mean that you have commits on branch A that you want to squash with commits on branch B? I don't think so, at least not with one command. Probably you can merge one branch into the other one first, then squash them.

git push origin +name-of-branch

in the + synonymous with force ?

in the + synonymous with force ?

According to the docs, it seems to be the same