1

Say My main branch is MainBranch. I have made a local branch Test.

I keep on doing work on my local branch meanwhile I have made several commits and pushed it to my local branch many times.

Now as My work is done I want to merge it to MainBranch.

I want to merge it to top of MainBranch.

I tried this :

git checkout `MainBranch`
git merge `Test`
git commit -m "Merging to main branch".

It is working fine, but it is also showing my local commits which are really un-necessary.

Is there any way to merge local branch to MainBranch without showing my local commits?

Am I missing something?

EAmez
  • 837
  • 1
  • 9
  • 25
Geek_To_Learn
  • 1,816
  • 5
  • 28
  • 48
  • Many small commits often mean fine granularity, which is appreciable when trying to read history and which changes belong together with others. Why are your small commits disturbing you? – Gauthier Jun 15 '15 at 11:17

2 Answers2

4

It is working fine but it is also showing my local commits which are really un-necessory.

If you don't want to show the local commits then use --squash switch on the git merge command.

From git merge documentation:

--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, move the HEAD, or 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).

With --no-squash perform the merge and commit the result. This option can be used to override --squash.

To read more about hiding micro-commits, this SO question seems a good resource.

Community
  • 1
  • 1
Davin Tryon
  • 66,517
  • 15
  • 143
  • 132
4

--squash is the simplest way to do it, as Davin wrote.

If you still want to keep some granularity to your branch (ie the branch shows too many small commits, but you don't want to put everything into one single commit that would be too large to grasp), you can try an interactive rebase.

git rebase lets you choose which commits to squash together, and which commits you want separated from the others. It lets you even split a single commit into several ones.

-i --interactive

Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).


If you actually don't mind having the granularity, but would like to have it visually separated from the main branch, you might be interested in the merge option --no-ff, see here.

This would only have effect if nothing happened in your main branch since you created the branch Test (commit A below). Starting example:

A - MainBranch
 \
  B---C---D - Test

After git checkout MainBranch && git merge Test, you have a linear history line such as:

A---B---C---D - Test - MainBranch

The history of MainBranch is not very clean or easy to follow.

Instead, you can run git merge --no-ff Test, and keep the branch separated:

A-----------M - MainBranch
 \         /
  B---C---D - Test

, M being a merge commit.

This is my usual workflow.

Community
  • 1
  • 1
Gauthier
  • 40,309
  • 11
  • 63
  • 97