Hacker News Reader

Comment by mseebach | Hacker News Reader

Everyone should stop making sweeping statements about what everyone should do.

Snark aside,

> Long running branches are bound to happen, [...] Good communication comes in handy here if you are working on long running feature branches.

How about this: Instead of having long running branches, don't have long running branches. Everyone runs on the same master branch, and master is always deployable. This way you don't need to communicate (yes you do, but the sort of communication alluded to is secondary, the full, up-to-date code with tests is the authoritative source). Have features that you can turn on and off in configuration, it's not like having branches ensure that you didn't screw anything up.

View on HN

This is how my company currently operates. It works well for us, BUT we do have some tools/methods to help us along the way. One of which is staging and production trees.

We are using perforce, so cross folder integrations are very simple with branch specs.

We'll have one folder named 'staging' where all development happens. Yes, the label isn't quite right. We can deploy this code to a 'staging' environment and test. When we're happy, we can integrate into the production branch and deploy.

These integrations are always one way; they go from staging -> production only. There are no conflicts to deal with. We also get the benefit of cherry picking updates to push in an emergency.

Do you not even use local branches?

I recently evaluated different CSS-preprocessors for one of our projects. This included not only changing and renaming a bunch of CSS-files, but also adding new dependencies, updating Makefiles, etc. We ended up going with the first one we tried, but it was a tough call so we might've wanted to revert it completely. Isn't this a perfect use case for a branch?

We had previous experience with the preprocessors, but they behaved differently used in our context with modularized CSS, lots of imports, using our custom watch script, etc, so we had to try them out in the actual project.

Branches certainly have their place, I'm talking about long-running branches.

A long running branch is usually a feature branch that is worked on over a long period of time. Just committing everything to master is asking for trouble.

IMO working on long running branches is asking for trouble. Specifically, it discourages refactoring, as it's impossible for any one developer to grasp how any change would affect his colleagues.

If everyone works in master, you try it, run the tests, and if they're green, you know it works for everybody. You don't risk breaking feature branch X that did a refactoring in a different direction in an overlapping area.

Of course, this implies that you adhere to a CD/CI philosophy. Code always compiles, all test always pass. If your process involves code being uncompilable, unintegrable or test breaking for substantial periods of time, you'll need branching.

Even if all tests pass, it doesn't mean you're ready to ship half-completed features. The features should be on branches not in the deployable code.

Which is why you have configuration switches to turn them on and off. The tests ensure that they don't mess with existing features, the switch makes sure the users can't see them.

I prefer keeping unfinished features out of my deployed code base, so I keep them in branches.

...that's what tagged releases are for? Push code into production, put that version into a tag, and do development on mainline?

So you end up with a bunch of commits in a random order relating to different things.

Lets say person A and person B are working on two features both committing to master.

Person A commits some work to master and pushes to origin. Person B commits some work and pushes to origin. Repeat this a few times, now you want to scrap the feature person A is working on. How do you cleanly handle this?

So, the answer would be to never scrap features (that's why you did proper design beforehand, right?).

That said, it seems you are suggesting that the workflow should be centered around rolling back features rather than commits? That being the case, if your feature spans multiple commits, then indeed you have something there. If your feature does not, branching probably isn't needed.

> So, the answer would be to never scrap features (that's why you did proper design beforehand, right?).

Sure, if you work in some sort of enterprise or corporate environment.

There are some long running branches that are difficult to avoid...a typical one might be moving between some very key infrastructure piece (going from ruby 1.8.6 to 1.9 for example or python 2.7 to python 3).

Reply on news.ycombinator.com