Comment by tunesmith | Hacker News Reader

Comment by tunesmith | Hacker News Reader

Parent Full thread

I think there's an inherent tension between your style, and the style that prefers pushing new branches immediately.

I personally like to create a new branch locally - sometimes I'm experimenting and get ahead of my commits, and then I'll make 3-4 commits in bite-sized concepts. Other times I'll commit something that seems like it will probably work, and then I realize it doesn't, so I'm able to revert/reset the commit (so the commit is deleted rather than seeing a commit and then a revert in the log). And once I'm close to done, I can even rebase so my clean commits are all in a row. Then I push my branch.

I lose all that flexibility as soon as a team's process demands I push my branch as soon as I create it. I can no longer rebase (I still don't understand the guides that explain how to use rebase after pushing), reverts add noises to the log, merges from master interrupt the flow, etc. So in that sense, I can see the allure of a squash-and-merge to master.

I just don't think that pushing an empty feature branch takes advantage of the benefits of using git.

Push after rebase is safe and easy if:

You have protection on your remote trunk branches against force push.

You have git configured to push only the branch you are on, to the same name on the remote.

git rebase; git push -f;

It is HARD, DANGEROUS and SHITTY under other configurations.

<3 Git.

As long as no one else is using your branch as well, then they'll hate you.

Yeah, basically as soon as you push, then there's no guarantee that someone else hasn't checked it out. That's how I see it anyway.

It'd be nice if git let you push (for backup/protection) without letting other people see it or check it out yet.

It's a fairly common practice to prefix branches only intended for your own work with your initials and a slash, e.g. jd/my-work-in-progress. You can't guarantee that nobody else will work off it, but it's their own fault if they do.

We treat branches for tickets (prefixed with the ticket ID) as owned by the owner of the ticket: feel free to check out, but if the owner changes it underneath you, tough.

There's no reason you couldn't rebase your feature branch work atop the commit it shares with the master branch, and push it. You would not be rewriting anything that the remote knows about.

Another option you might consider, if you need more flexibility, is doing your work in a branch off of your `feature-branch`, e.g., `feature-branch-wip`. When you're happy with your progress on `feature-branch-wip`, interactively rebase atop `feature-branch`, merge in, and push. Their process is satisfied, and they'll never be the wiser.

But leaving a day's work locally on your laptop is dangerous, no? You have to organise some other backup system, instead of pushing to the central, RAIDed, backed up repo.

I suppose you can always set up a private bitbucket as a second remote and push to there. It might be against your team's policy, though.

Reply on news.ycombinator.com