undefined | Better HN

0 pointsjtchang7y ago0 comments

Doesn't using rebase generally mean you have to rebase on top of master and thus with your local branch you may need to git push --force ?

0 comments

7 comments · 2 top-level

rekwah7y ago· 5 in thread

You rebase your feature/topic branches on top of master and then merge the feature/topic branch back onto master, enabling a fast-forward merge.

austinjp7y ago

Is this a common workflow? Googling suggests almost religious feelings about this.

woodrowbarlow7y ago

it comes down to whether you want your version history to reflect the true version of development's history (merge), or a simpler, doctored version of history which reflects the final deliverable (rebase). advocates of the latter, myself included, argue that it eliminates noise and tells all the story that needs to be told -- and that the original history can be preserved by not deleting the feature branches. others argue that changing your parent commit is dangerous and occlusive.

i think the core of it comes down to the UX for "git log", which attempts to display history linearly when in fact it absolutely is not. ask yourself: what is the _contents_ of a merge commit? if you know git well, you know that the merge commit contains everything from the feature branch... and that the feature commits you see when you run "git log" on master are actually not on master at all. so the rebase strategy makes master truly linear to match the tools and reduce cognitive load.

however, the rebase strategy does introduce new possibilities of tool-driven bugs and requires more rigor. this article has a good run-down of the risks:

https://medium.com/@fredrikmorken/why-you-should-stop-using-...

the classic example of a rebase pitfall is:

a) you branch from master,

b) on your feature branch, develop a feature utilizing dependency x,

c) meanwhile, on master, another developer removes dependency x,

d) you rebase back on top of master -- there are no conflicts, and things look good, but the build is completely broken.

rekwah7y ago

Anecdotally, I feel it's less common than merge commits. There are plenty of places driven by the "Merge Pull Request" button in GitHub and that's the default functionality.

In personal projects or those with fewer developers, I prefer rebase + FF merge for a clean history. I don't really feel the need to see the merge commit in the master branch history.

tedmiston7y ago

Yes, it's common for open source projects. I've used a rebase workflow for feature branches in Apache projects and others.

It takes a little more work for each contributor but leaves history on master very clean.

jedbrown7y ago

Warning: If you don't also squash the entire topic branch, then you will sometimes break git bisect with this workflow.

tabbott7y ago

Yes. The default GitHub-recommended workflow of having contributors do `git pull` to integrate their changes an easily result in a confusing spaghetti monster history even if the contributor only has 1-2 commits that don't merge conflict with anything.

For this reason, most major open source projects use that part of the workflow (asking their contributors to rebase their PRs on top of master and never use `git pull --merge`), even if they plan to merge the commits into master via a merge commit.

(The Git documentation is very aggressive in discouraging force-pushing of commits, but that advice is intended for a public repository, like the main zulip.git repository, that others might pull from. Obviously, we don't force-push to zulip.git, but if you're using Git right, you should be force-pushing to your fork when you fix a typo in one of your commits.)

j / k navigate · click thread line to collapse