Too many memes
True. I'll post it to 9gag as well.
Keep calm and continue rebasing
11–16 of 16 posts
Re: Keep calm and continue rebasing
#12I wish I could downvote purely on the basis of that hateful "Keep Calm" meme.
It is a little hateful, I must admit, but makes total sense based on the panic against rebasing that the original post was trying to spread.
Re: Keep calm and continue rebasing
#13I'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?
I would definitely leave the --squash part out. Commits should be atomic, simple, small, easy to read. If you squash whole features together you end up with huge commits, which makes harder to spot bugs if you later have to re-review them.
Re: Keep calm and continue rebasing
#14Earlier quoted context omitted.
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 probl…
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.
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.
Re: Keep calm and continue rebasing
#15Earlier quoted context omitted.
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.
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…
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.
Re: Keep calm and continue rebasing
#16Earlier quoted context omitted.
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…
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.
:+1: