2 ms·

My biggest problem with "A successful Git branching model" is that it scares people into thinking they have to design and commit to a workflow before they can d

by Gratsby 11y ago

My biggest problem with "A successful Git branching model" is that it scares people into thinking they have to design and commit to a workflow before they can develop software. Having a defined workflow is not a bad thing. And it certainly wasn't the intention of the author for anybody to stagnate. Unfortunately, it's very natural for technical people to overthink and over-engineer process. In my mind, when an organization is new to source control or is haphazardly using it, it's best to simply start using the tool. Each product is different, each organization is different, and each developer is different. You should mature into an organized development model based on what you know about your own situation. If you develop on the develop branch and release on the master branch, but don't communicate that clearly to the new guy, I guarantee he's going to start working on master right out of the gate. The same goes for every model where there's a lack of communication around procedures and no workflow controls. Git saw a rise in popularity because it was easy where every other solution was difficult. If you're having issues with code review, patches, release versioning, or whatever - address that particular problem. If the problems are multiplying to the point where it's significant, it's time to think through a process. Spending your time and energy ferreting out a process based on the fear of what might one day happen will result in a significant amount more time spent doing that then addressing the would-be problem in the first place.

mcv 11y ago
I agree, communication is essential. The most important thing is that the developers agree on how they work with git, and all these branching models are just usable defaults and starting-off points from which you figure out what works for your organization. But preventing the new guy from pushing straight to master is not that hard. On my current project, a git hook prevents merging commits into the remote master if that commit doesn't already exist in another remote branch. So you have to do your work elsewhere or it won't be accepted.
- Gratsby 11y ago
  Unless of course he sees an error and runs `git push --no-verify`. I'm not really saying any of the advice around git workflow is bad. It's that too much time spent on process instead of development is. If you take the advice for what it is - a good starting point - I think it's great to use.
  - mcv 11y ago
    > Unless of course he sees an error and runs `git push --no-verify`. Yes, but then you know he's someone you need to fire. That's also useful knowledge.

by Gratsby 11y ago

mcv 11y ago

I agree, communication is essential. The most important thing is that the developers agree on how they work with git, and all these branching models are just usable defaults and starting-off points from which you figure out what works for your organization. But preventing the new guy from pushing straight to master is not that hard. On my current project, a git hook prevents merging commits into the remote master if that commit doesn't already exist in another remote branch. So you have to do your work elsewhere or it won't be accepted.

Gratsby 11y ago
Unless of course he sees an error and runs `git push --no-verify`. I'm not really saying any of the advice around git workflow is bad. It's that too much time spent on process instead of development is. If you take the advice for what it is - a good starting point - I think it's great to use.
- mcv 11y ago
  > Unless of course he sees an error and runs `git push --no-verify`. Yes, but then you know he's someone you need to fire. That's also useful knowledge.