Comment by up_and_up | Hacker News Reader

Comment by up_and_up | Hacker News Reader

Parent Full thread

> It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them.

Honestly, I'm not sure you have realized the true power of git branching.

Here is our typical workflow at work:

1. Branch master to topic/feature branch

2. Work on feature branch, push feature branch to remote

3. Push of feature branch to remote triggers a Tddium test run.

4. Deploy feature branch to a staging server for internal review.

5. Make fixes, adjustments to feature branch and push to remote, which triggers more Tddium test builds.

6. Once things are looking good, we pull --rebase master, which pulls down everyone elses changes to master.

7. Rebase the feature branch off of master, resolve any conflicts.

8. Merge feature branch into master and push.

Above, branching allowed me to:

* Save my own personal branches to a remote repo where they are backed up,

* Offload my test suite to a 3rd party,

* Allow me to deploy a feature branch to a staging server all without messing with the master branch at all.

I can also squash or rename commits on my branch easily and cherry-pick other commits from other branches without worrying about master. I can also VERY EASILY switch to other branches to work on other features and bugfixes as they arise. I normally work on 2-4 diff branches per day. Try doing any of that in SVN and be in for fun ride...

Which does nothing to improve the core problems with your workflow :)

Offloading tests to 3rd party will not help you ensure that tests run fast as they should.

Working too long on your branch will only make mergers more painful later.

We use svn and git, but the workflow is still local fast tests before even branches commits. No personal branches, only features, and update those often because they're not exclusively your silo. And commit/merge to head often. And head is the only place where you get the 2h integration test run. Because otherwise, you'd wait 2h after every branch commit (which we know nobody can do)

> Which does nothing to improve the core problems with your workflow :)

Not sure what you mean. I state above how it helps my workflow.

> Offloading tests to 3rd party will not help you ensure that tests run fast as they should.

That's not the main point of CI. The main point is both: as a sanity check for tests pushed to the remote and also to not waste your time and CPUs running tests locally.

> Working too long on your branch will only make mergers more painful later.

I easily rebase off of master on a daily basis with git, no issues there.

rebase is not the same as avoiding merge problems.

what does it help you if you and other dev have their, often rebased or not, branches for a long time? the first one will be fine, second will have merge hell.

honestly, you are only comfortable with that setup because you probably work alone on a small team.

edit: and dont get me wrong, if that is the case, you are using the right tool for the job. i would love to be able to not rely on regular atomic commits in my huge dysfunctional group.

(Not the OP, obviously.)

> rebase is not the same as avoiding merge problems.

Yes it is. The point is this: Everybody rebases against "what is to become our next release" on a continual (daily if not more frequent) basis. If you have acceptable levels of unit testing and integration testing on your feature branches there's usually no problem with early (that is, way before the sprint ends) merging of feature branches to master. If your team is really paranoid and all your team's feature branches tend to pile up until the last day of the sprint[1], you could forcibly (via process) stagger your feature merges so that they're always at least 1 day apart to catch any bad interactions between features.

[1] This is indicative of other problems to do with process/management, so take the next bit of advice with a grain of salt.

Reply on news.ycombinator.com