Hacker News new | ask | show | jobs
by omnipath 1247 days ago
Huh? You only rebase when you're either:

* Trying to shorten commit history

* Trying to merge feature branches together (main or other feature branches)

* Trying to remove feature branches

None of which are necessary in a lot of development models. If you have that many feature branches that you have to rebase constantly, it doesn't sound like feature branches as a concept are properly understood.

The idea behind feature branching is one of 2 models:

1) either the main branch always works, and development is done in a feature branch, only to be rebased into main when development, testing, and sign off occurred, or

2) serious bug fixes occur outside the main branch, to be re-incorporated back into the main branch once it's been proven to be effective.

The 1st model should only require a rebase when the feature is complete. The 2nd model MAY require a couple of rebasing, dependent on how extensive the bug fixes are, and how fast the main branch is moving along, but not to the point where constant interactively rebasing your branches is the norm.

1 comments

If you're writing a local stack of commits, you need to do an interactive rebase to edit the commits in the middle. You can't just check out and amend earlier commits in the stack, since git has a branch-first rather than commit-first model (one of its biggest UI failures).
No, I don't. Again, this seems to be a personal design/preference rather than a behavior git is forcing upon you, which is my point (This isn't a git issue, this is a development workflow that seems needlessly over complicated). When I do development locally, I only commit changes I want to keep. If there is something wrong, or code that needs to be modified, I make those changes, and then commit. When the work is done, if pressed upon me by the team, I rebase the local commits to a single commit before submitting a merge request.
It's the same development workflow used by the Linux kernel? You know? The project that Git was invented for?
There are tons of different workflows used by Linux Kernel maintainers. Some of them don’t even use Git except to submit patches.

Whose workflow are you trying to emulate? (followup question: and why?)

Are you working on something as complex as the Linux kernel?