Hacker News new | past | comments | ask | show | jobs | submit login

The warning regarding "public, shared, or stable branches" is always warranted, but I think those warnings end up reverberating where they needn't. Before interacting with anything public or shared — when working solo or locally — `rebase` can be hugely helpful. When starting out with something complicated, I often make separate commits for different files or steps; using rebase to reorder commits or amend can make turning your first steps into a viable change much easier, and can help with merge conflicts down the line. I also find it helpful for large commit messages; rather than needing to write everything at once, making liberal use of `fixup` or `squash` can keep disparate thoughts or bug fixes manageable.

I'd never use it on a public or shared branch, but `rebase --interactive` and `--exec` are some of my most-mused git aliases.




I'd use rebase --interactive quite aggressively on a public branch when it's a feature branch that's not yet been merged. As I'm the only owner of it, the way I see it I owe no guarantees to anyone. You're welcome to watch it, but it's work in progress in every aspect.


Github and refined-github[1] make it easier, by keeping track of changes from a `push -f` and having merge/squash/rebase options on merging, but I know of large projects with an explicit "no rebasing" rule as it can get confusing for reviewers. I'd say it depends on the project, maintainers, and general workflow. Which is good!

1: https://github.com/sindresorhus/refined-github


My team does this for branches during the code review process all the time, and it works great.


rebasing a shared branch is fine, if the audience who needs to know about it is within arms length (or the remote chat equivalent). Rebasing a public branch that's used by hundreds requires special notification tooling and email templates and elaborate public shaming rituals, which people are happy to come up with but seems unnecessary in my opinion if you think twice before force pushing

also: 'git push --force-with-lease' (worth repeating)


I use `--force-with-lease` instead of `--force` or `-f` because it ensures that if someone happened to push before me it would fail and I could manage that manually. Even on branches that no one "should" be touching other than me, it seems safer to type the extra characters `-` and `orce-with-lease` around the `-f`.


This was new to me, and makes me feel better about force pushing. However, while googling to find out if I could set this as the default behaviour I found an Stack Overflow answer that as well as saying "no" points out a very git-like gotcha:

https://stackoverflow.com/questions/30542491/push-force-with...

Apparently it will think you know about the changes if you've fetched them, even if you've not merged them. And some systems auto fetch in the background.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: