Keep calm and continue rebasing
gist.github.com
Keep calm and continue rebasing
1–10 of 16 posts
Re: Keep calm and continue rebasing
#2I wish I could downvote purely on the basis of that hateful "Keep Calm" meme.
Re: Keep calm and continue rebasing
#3I'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?
Re: Keep calm and continue rebasing
#4I wish I could downvote purely on the basis of that hateful "Keep Calm" meme.
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.
Re: Keep calm and continue rebasing
#5I wish I could downvote purely on the basis of that hateful "Keep Calm" meme.
Talk about hateful...
Re: Keep calm and continue rebasing
#6Too many memes
Re: Keep calm and continue rebasing
#7I'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 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.
Re: Keep calm and continue rebasing
#8I wish I could downvote purely on the basis of that hateful "Keep Calm" meme.
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.
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.
Re: Keep calm and continue rebasing
#9Earlier quoted context omitted.
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.
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.
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.
Re: Keep calm and continue rebasing
#10I'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 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.