I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.
Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first):
H(3) Implement feature B
H(2) Implement feature A
H(1) Initial commit
H(5) Shiny feature, improvements.
H(4) Shiny feature, initial implementation.
H(3) Implement feature B
H(2) Implement feature A
H(1) Initial commit
Then you `git pull --rebase`, and your history looks like this:
H(10) Shiny feature, improvements.
H(9) Shiny feature, initial implementation.
H(8) Pulled commit C
H(7) Pulled commit B
H(6) Pulled commit A
H(3) Implement feature B
H(2) Implement feature A
H(1) Initial commit
With the usual pull request flows, `H(9)` (i.e. anything between your new "base" and your most recent commit) usually stays untested, entirely ignored by the developers, and you would only ever find out if you ever need to bisect.
Not usually a problem, unless you have a rule of "every commit should be verified/tested" and the untested commits have a change that doesn't prevent a build but still causes issues (e.g. something that's only visual, or a new config file was added to a "conf.d" directory and its presence changed some behavior, stuff like that).
git reset --hard origin/branch-name> git pull --rebase
git config --global pull.rebase=trueYour two feature branches would be unprotected so you can merge away if you like. When one of you wants to commit something to master, that's when you'd check for dodgy merges.
Also, "git cherry-pick" is a good alternative to merging for this use case.
No, the feature branches need to be protected or something, to enforce that they only rebase locally and don't rebase the parts that I've merged into my branch (and vice versa).
> Also, "git cherry-pick" is a good alternative to merging for this use case.
No it isn't, it means you get multiple unrelated commits for the same change, which causes conflicts and can be disastrous if a commit is deliberately reverted.
- Having a developer on your team that rebases their own feature branch
- Then tries to "git push", only for it to be rejected since a force push is required
- Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously
Our team uses merges because they are safe from this kind of problem, although a rebase workflow would have cleaner history. I wish that "git push --force" would not push all branches by default, and just fail unless a (remote, branch) pair or --all is given.
This is (part of) why, for most common operations, I use a Git GUI (SourceTree). Force pushing all branches can only be done by very explicitly selecting them all and initiating a force push; the default when pushing is to push only the currently active branch.
It's also overall much clearer and more intuitive to use than the Git CLI. I use it when I have to—there are things that I can't do through SourceTree, and a few things that are complicated enough that I just want to be 100% sure I know exactly what's happening—but for 99% of the Git operations I do, it handles them perfectly and without any worry that I've mistyped something or forgotten to specify a branch.
And only on working branches. I do this every single day.
To collaborate more closely and reduce (or get ahead of) conflicts. The whole point of using git at all is to be able to base your work off other people's in-progress work; if you're not interested in doing that then Subversion works better.