

Keep calm and continue rebasing - tuxie_
https://gist.github.com/tooxie/fbe5e1cff588c7cc8275

======
zimpenfish
I wish I could downvote purely on the basis of that hateful "Keep Calm" meme.

~~~
oneandoneis2
I would downvote purely on the grounds that you can legitimately rebase master
the same as any other branch - it's rebasing published history that screws up,
not rebasing commits that are on a specific branch.

There's nothing wrong with, say, creating three local commits on master,
"rebase -i"ing them into one commit, and then pushing.

The author has completely missed the point of what can and can't be rebased.

~~~
ShellfishMeme
I think the intended point was that you should always work on feature
branches, never on master, rebase your feature branch work against
upstream/master which is the one true published history and thus never rebase
master.

In this workflow there is no pushing to master because you never work on
master. So there is no reason to ever rebase master. Master is always assumed
to be published history.

~~~
tuxie_
Exactly. Thanks ^^

I'm assuming that you have someone else apart from you sync'ing with your
master. But even if you know that nobody else uses your software (so far), I
would still recommend, as a good practice, to stay away from rebasing master.

Work on feature branches, rebase them, and merge them. Once in master, you
don't rebase anymore.

------
andyhmltn
I'm working on a large project at the moment and am branching off quite often
to get new features in place. Then once I have finished I rebase with master,
switch to master and `git merge my-feature-branch --squash`. Is that okay to
do?

~~~
dasil003
I am a huge proponent of rebasing but not so much with squash. I tend to
squash judiciously with rebase -i if I feel the need. But otherwise I think
it's good to maintain that history of the general evolution of a feature
through development.

However if it's a small feature and your commit message is well-formed and
comprehensive (ie. 50-char top line and then paragraphs of description below)
then I don't see a problem squashing a few commits together.

~~~
tuxie_
For me, if a PR introduces a bug and then fixes it later, it must be squashed
together. First of all, and most importantly, because it makes it easier for
reviewers.

Second, makes no sense to merge, consciously, a bug into master, specially if
it's known and fixed already.

~~~
dasil003
That's the type of thing I use rebase -i for though. My concern with squashing
is that quite often you have multiple stable points in the development of a
feature. The order that those states were reached is informative to reviewers
and I wouldn't want to make a habit of squashing them away.

I think focusing on committing green test states often leads to faster
development and more focused thinking, and I'd prefer to see this approach
represented in the final commits rather than getting in the habit of squashing
days and days of work into single mammoth commits.

~~~
ShellfishMeme
I think you're both talking about the same thing. Basically, if you realize
you had a typo somewhere in an early commit, or some other random easily
fixable error that you simply overlooked and thus isn't part of the evolution
of development, you should use rebase -i to squash the fix commit together
with the one that introduced the error.

It's not about squashing together the entire history of development.

~~~
tuxie_
:+1:

------
Dissori
Too many memes

~~~
tuxie_
True. I'll post it to 9gag as well.

