5 ms·

If you work on a branch also worked on by others, then yes, rebase is "only" possible on private commits. But if you work on a feature branch, you can publish

If you work on a branch also worked on by others, then yes, rebase is "only" possible on private commits. But if you work on a feature branch, you can publish that branch as long as everybody else understands that it is yours and nobody should push to it. Then you can safely git push --force to the feature branch so that others can (a) see what you're up to (b) test the results. When you're done, you can do a final (or only) rebase against the target branch then merge to that branch.

smcameron 2y ago
> Then you can safely git push --force What I hate about this workflow is it teaches you to git push --force. Then one day, you're in the wrong window and you accidentally git push --force on master. Much prefer a workflow where you never git push --force
- necessary 2y ago
  Git hosting platforms generally have controls that allow you to prohibit force pushes on protected branches (i.e. master)
  - The_Colonel 2y ago
    This doesn't fix the problem since you still can do a lot of damage doing that on a (perhaps wrong) feature branch.
    - SOLAR_FIELDS 2y ago
      It certainly diminishes it significantly. Very few people are usually collaborating on the same branch together that isn’t the main branch in most orgs. So the chances of you destroying yours or someone else’s work that way is pretty low. You can also branch protect any arbitrary branch, at least on GitHub, though I’ve never been in an org that protects branches other than the main one, besides an org that used release branches. I’ve also never seen someone clobber someone else’s feature branch, though it probably does happen. Much more often people are accidentally clobbering their own branches. The ability to rewrite history on feature branches is powerful in a good way and slots right into the way Git is philosophically designed. I would probably not be interested in removing that feature to prevent the rare case that someone footguns themselves or someone else
    - nickkell 2y ago
      That's where reflog comes in handy
- zimbu668 2y ago
  You should do this instead: git push —-force-with-lease repo branch
  - ajb 2y ago
    This. --force-with-lease is what --force should have been in the first place. Hopefully they will eventually make it so, and rename --force to something less accessible.
- cortesoft 2y ago
  Any repo worth its salt shouldn't allow a force push to the main branch.
  - ck45 2y ago
    I fully agree, and also think that if it's a professional environment pushing to the main branch itself is very questionable for most / code repos. Not only because of the Sarbanes-Oxley Act for public companies.
patrickthebold 2y ago
What annoys me about this is that every branch ends up being "private" and people don't collaborate (In practice). So you end up with: "I can't start work on X until feature Y is merged, and there's a lot of PR comments left unaddressed so let's just merge Y since X is urgent and fix the PR comments later..."
- PaulDavisThe1st 2y ago
  That's not at all our experience at ardour.org. Most PRs happen against the main branch, maybe after a private feature branch, maybe not. Meanwhile, major developments happen in a feature branch, and these are almost always owned by a single person who is responsible for rebasing against the main branch (and eventually merging back there). But maybe our development team and pace are not good tests for this model.
  - kfrzcode 2y ago
    OT but I love Audour so much. Thanks for you and your team!
  - The_Colonel 2y ago
    > and these are almost always owned by a single person who is responsible for rebasing against the main branch That still seems very annoying. People have unplanned time-off all the time, live in different timezones, or perhaps are l just busy ATM and can't do the rebase.
    - SOLAR_FIELDS 2y ago
      In practice I’ve found: - Unplanned time off means the feature just doesn’t make it in - Living in different time zones means that you just wait and work slows down In either event, there is rebase and squash auto merge from major git providers like GitHub which helps with this a ton. With that enabled unless the repo is super high traffic usually this is an afterthought unless there is merge conflicts which is semi rare. That being said, that’s just the reality of what I’ve seen play out in various organizations. I personally like to work off other people branches a lot more than my peers because I work in platform engineering and very often developers come to me with feature branches that need some CI/infra/other change or optimization and very often it’s easiest for me to just drop a commit into their existing branch. The change falls under their ownership and it gets mainlined along with their feature.
Aeolun 2y ago
Never use git push —force. Alway use git push —force-with-lease. Then if someone changed your remote branch, git will always let you know :)
- arrowsmith 2y ago
  Been using git every day for ten+ years and I never knew about --force-with-lease. That's great to have learned, thanks!
e12e 2y ago
I think feature branches typically should be "mostly" private - but sometimes a few quick fixer are better to push, rather than just describe as a review comment.

smcameron 2y ago

> Then you can safely git push --force What I hate about this workflow is it teaches you to git push --force. Then one day, you're in the wrong window and you accidentally git push --force on master. Much prefer a workflow where you never git push --force

necessary 2y ago
Git hosting platforms generally have controls that allow you to prohibit force pushes on protected branches (i.e. master)
- The_Colonel 2y ago
  This doesn't fix the problem since you still can do a lot of damage doing that on a (perhaps wrong) feature branch.
  - SOLAR_FIELDS 2y ago
    It certainly diminishes it significantly. Very few people are usually collaborating on the same branch together that isn’t the main branch in most orgs. So the chances of you destroying yours or someone else’s work that way is pretty low. You can also branch protect any arbitrary branch, at least on GitHub, though I’ve never been in an org that protects branches other than the main one, besides an org that used release branches. I’ve also never seen someone clobber someone else’s feature branch, though it probably does happen. Much more often people are accidentally clobbering their own branches. The ability to rewrite history on feature branches is powerful in a good way and slots right into the way Git is philosophically designed. I would probably not be interested in removing that feature to prevent the rare case that someone footguns themselves or someone else
  - nickkell 2y ago
    That's where reflog comes in handy
zimbu668 2y ago
You should do this instead: git push —-force-with-lease repo branch
- ajb 2y ago
  This. --force-with-lease is what --force should have been in the first place. Hopefully they will eventually make it so, and rename --force to something less accessible.
cortesoft 2y ago
Any repo worth its salt shouldn't allow a force push to the main branch.
- ck45 2y ago
  I fully agree, and also think that if it's a professional environment pushing to the main branch itself is very questionable for most / code repos. Not only because of the Sarbanes-Oxley Act for public companies.

patrickthebold 2y ago

What annoys me about this is that every branch ends up being "private" and people don't collaborate (In practice). So you end up with: "I can't start work on X until feature Y is merged, and there's a lot of PR comments left unaddressed so let's just merge Y since X is urgent and fix the PR comments later..."

PaulDavisThe1st 2y ago
That's not at all our experience at ardour.org. Most PRs happen against the main branch, maybe after a private feature branch, maybe not. Meanwhile, major developments happen in a feature branch, and these are almost always owned by a single person who is responsible for rebasing against the main branch (and eventually merging back there). But maybe our development team and pace are not good tests for this model.
- kfrzcode 2y ago
  OT but I love Audour so much. Thanks for you and your team!
- The_Colonel 2y ago
  > and these are almost always owned by a single person who is responsible for rebasing against the main branch That still seems very annoying. People have unplanned time-off all the time, live in different timezones, or perhaps are l just busy ATM and can't do the rebase.
  - SOLAR_FIELDS 2y ago
    In practice I’ve found: - Unplanned time off means the feature just doesn’t make it in - Living in different time zones means that you just wait and work slows down In either event, there is rebase and squash auto merge from major git providers like GitHub which helps with this a ton. With that enabled unless the repo is super high traffic usually this is an afterthought unless there is merge conflicts which is semi rare. That being said, that’s just the reality of what I’ve seen play out in various organizations. I personally like to work off other people branches a lot more than my peers because I work in platform engineering and very often developers come to me with feature branches that need some CI/infra/other change or optimization and very often it’s easiest for me to just drop a commit into their existing branch. The change falls under their ownership and it gets mainlined along with their feature.

Aeolun 2y ago

Never use git push —force. Alway use git push —force-with-lease. Then if someone changed your remote branch, git will always let you know :)

arrowsmith 2y ago
Been using git every day for ten+ years and I never knew about --force-with-lease. That's great to have learned, thanks!

e12e 2y ago

I think feature branches typically should be "mostly" private - but sometimes a few quick fixer are better to push, rather than just describe as a review comment.