5

I've searched a lot but didn't find a similar question.

Let's say that I have two branches. Branch S (stable) and branch E (experimental). Experimental has been created "from" Stable branch.

I'm working all the time on E branch by executing

git add -A . git commit -m "my new commit" git push origin E 

And it works just fine. When I think it's time for that I'm simply doing:

git checkout S git merge E git push origin S 

And that works fine as well but my stable branch is spammed with every single commit from experimental branch. I don't want to "squash" all commits into one in experimental branch but I want to have only one commit during such merge instead of all single ones.

Probably there is a very simple command for doing that but I didn't find it. Unfortunately git rebase E doesn't do the trick, all commits are still showed as single ones.

Thank you for your time.

5
  • Your idea of a branch and a merge seems to be somewhat off. I’d advise you read through the branching chapter in the Git Book. Commented Jul 8, 2013 at 0:44
  • 1
    And why do you think so? I've read this chapter in Git Book before and concept is nearly the same. I'm making some changes to exp and porting it to stable. Again making changes to exp and porting to stable... Why do you think that it's a "bad" way? Could you propose better one? It's important for me to have two branches so I can work on one and eventually push all changes into stable one after some time and testing. Commented Jul 8, 2013 at 0:52
  • Usually, commits are supposed to be rather small units, and you wouldn’t want to lose all the information within the commits you created on your experimental branch. By merging, you create a merge commit that just combines two (or more) branch lines while keeping all the information intact. You are not “spamming” your branch, because a branch is just a pointer to a single commit. That commit then holds information about its parent, creating the whole Git history. – The separation to stable and experimental branches however is not bad at all but very common and completely fine! Commented Jul 8, 2013 at 0:56
  • Thanks, I get your point of view and you're right. However I think that squashing all experimental commits from time X to Y and merging with stable is not that bad, especially because if f.e. bug is found I'm still able to create revert commit on exp branch and port it to stable one, because experimental branch still holds whole the history of every single commit. Correct me if I'm wrong, I'm still learning GitHub's magic :). Commented Jul 8, 2013 at 1:03
  • Keeping individual commits will not prevent you from doing either of that though, instead it will allow you to look back and see how (and often why) you made changes in one way or another. But sure, if you like to work that way, I won’t stay in your way ;) I just wanted to point out that you would usually want to keep those commits around. But there is no one workflow for Git, so feel free to do whatever you are comfortable with :) Commented Jul 8, 2013 at 1:07

1 Answer 1

2

Try git merge --squash E instead of git merge E.

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.