Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

> You can rebase all you want as long as you didn't make your private branch public.

True, but the big benefit of git comes from those branches being public, IMO.

> and even then some communication with the other people makes it pullable: tell them to first git reset --hard xxxxx

If other people are actually using the changes on your branch (and if not, why did they pull it?), you end up having to do staircase rebases, with everyone fixing the same conflicts again every time they rebase. It's not the end of the world, but it's noticeably worse than using merge.

> yet doesn't suffer from sometimes hard to read history

IME the only difficulty comes with tools that try and display a linear view of history, and with rebase you sacrifice an accurate time-ordering of commits, making it very hard to find a commit if you were working on several branches at the same time. As long as you configure your tool to show a tree/graph of commits, merged history is easy to follow, and keeps the time-order correct.

To me, the big benefit of Git is private branches. When I'm in development I don't need to build clean, atomic commits or have anything worth pulling. I write commit messages like "savepoint 2013-12-12 do not push". I don't want to think about version control because everything is still dirty.

I don't know if you've looked at the graph of a Git repo where people merge instead of rebase, but even in that view it's nearly impossible to track even the history of master. It's a mess. Rebase builds such cleaner graphs that I would only advocate merge when you have no reason to ever look at the graph view.

For me, almost all of the time, when I'm ready to merge to master I can almost always squash all my work into one or two clean commits. At that point a fastforward is the simplest solution. Merge-only workflows are great for long-lived public branches (if you have an integration and release branch for instance) but they're insane for feature branches.

I think private branches are just branches not pushed to remote. Isn't the problem here now that you have a critical point of failure and at risk of losing everything if you're not pushing things to remote nightly. I always advocate regardless of pushing branches to remote and getting things off of your local drives if possible.

If you're not regularly backing up the machine you work with, you're screwed. Git is not necessarily the best tool for this, but when you have nothing better, it often works to set up a "backup" remote that other people can't touch and then just do force pushes.

well most our stuff is in "the cloud" so really if we wiped everything, it be just a matter of pulling backups and go. Setting up a backup remote for something so simple of merge vs rebase sounds off to me.

So it sounds like you don't have to push your code since your workstation is already being backed up then? We agree that you don't need to push your feature branches in that situation? I'm not sure, I feel like you just pulled some weird conversational jiu-jitsu where all of a sudden you're making my point back to me.

no our things like documents, database backups, emails, and source code all exist in the cloud. By suggesting my employees all push to remote daily, theres no risk of ever losing anything. All it takes one stolen laptop, one hardware failure to push you back xxx days, from your private branch. I don't know how long you work on a private branch but I have seen people wait close to two weeks during a 2 week sprint.

The Git system we use at my workplace has a private "backup" remote for each employee and a public "share" remote for each employee. So there's no problem rebasing all the time even if you push to the backup remote because it's not shared. Ultimately backups should be a totally separate concern from version control workflow anyway, even if you use Git remotes to back up your work.

> I don't know if you've looked at the graph of a Git repo where people merge instead of rebase

We use merge instead of rebase. Here's a snapshot of the graph:

  | | | | | | | | | | | | | | |                  
  * | | | | | | | | | | | | | |
  |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \
  | |_|/ / / / / / / / / / / / /
  |/| | | | | | | | | | | | | |
  | | | | | | | | | | | | | | |

There are only 4 people working on the repo.

Exactly! I feel like I need a drink after looking at that.

I'd expect 5 lines (trunk + 4 branches). What're the others?

Reply on news.ycombinator.com