Hacker News Reader

Comment by lmm | Hacker News Reader

Rebase is a bad habit to get into (because it means other people can't pull your branches), and a pain to fix when it conflicts. Merge master into your working branch instead.

View on HN

That's an unfortunate generalization. You can rebase all you want as long as you didn't make your private branch public. (and even then some communication with the other people makes it pullable: tell them to first git reset --hard xxxxx)

We use this more othen then not here, and never have problems. It's a great way to work on a dedicated feature while still getting features from others, yet doesn't suffer from sometimes hard to read history. Does this mean rebase is king and merge isn't? No. Is it the other way around then? Also no. Both are fine if you know how to use them.

> 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?

I don't get why people hate merges so much; it records the history of what actually happened, which seems like a nice default. I find it can be helpful for tracking regressions, even on private branches that never get pushed.

me too. the only reason i can see is laziness when looking at history because merges clutter it, but even then the fix should be in some front-end tool and not git itself.

as a real world example bitbucket added a cool feature recently where they grey out merge commits.

personally i love rich and complete history, including merge commits - any practice that damages that is something i'll be highly reticent about adopting.

irl i generally don't need to time travel to achieve my goals...

"as a real world example bitbucket added a cool feature recently where they grey out merge commits"

Interesting. I went a different route by making it very easy for users to dissect a merge commit. For example, if you click on the "Find included commits" link in the first commit at:

http://ny.testdrive.gitsense.com/index?#pid=13&cid=20&trail=

you'll be able to see all the commits that it included.

The problem isn't history. The problem is meaningless history. If I'm working on file X and meanwhile file Y changes on the remote repository and those have nothing to do with each other you shouldn't need to do a merge. Merges should reflect situations where related changes happen concurrently. Otherwise it's just clutter and you can no longer separate the "true" merges from the noise.

Rebasing public branches is no big deal as long as it's a personal branch. This should be obvious to the others you're working with, if not, your team probably needs to communicate more.

The only reason I can think of for others to pull your personal topic branches are to review it locally or help you debug something. Others shouldn't be branching off of your personal topic branches to work on them, use feature flags instead.

Feature flags make it much harder to encode appropriate constraints into your type system, and make testing much less effective. It's very useful to be able to collaborate at a finer granularity than only sharing changes that compile.

It depends on the use case. The author specifically says it is a workflow for /continuous delivery/.

We do continuous delivery and our branches typically live for about an hour before they are pushed to production.

Continuous delivery is about working in small deployable steps and using techniques that allow you to release incomplete features into a production environment (Feature toggles, Branch by Abstraction).

Feature branches are pretty much the opposite of continuous integration. By definition your changes are not integrated into production or with other people using other branches

http://martinfowler.com/tags/continuous%20integration.html

Feature branches really have nothing to do with CI per se. A feature branch is to test major changes without upsetting the stability of your build. Depending on your code review process, it also gives people a chance to give feedback and make changes before everything's merged back into develop.

In fact, the TeamCity CI system now supports automatically building feature branches -- so the two concepts are definitely not at odds.

Reply on news.ycombinator.com