DEV Community

Discussion on: How to use git efficiently

 
melezhik profile image
Alexey Melezhik • Edited

Well, the shortcuts you have here is just smallest and easiest part of the workflow, the hardest part is merge branches not creating them. In classical git flow https://jeffkreeftmeijer.com/git-flow/git-flow.png you have 5 types of branches you have to merge and create in specific order and in specific times. If you don't follow the rules strictly you end up with the mess.

While it's probably easy to follow gitflow with small projects and low frequency of releases, it is way too harder to keep this approach with frequent releases and large code base. This is why companies with large code base and frequent releases like Google practice kinda TDB methodologies ( with variations ) instead of gitflow.

And believe me, with TBD you get your trunk/master messy and unstable if anybody can merge there, I tried implementing that many times.

It's not true. Pull requests / Code Reviews are still here to fence main code from junior developers direct commits ( though you might not need this with mature teams, anyway )
Also if a build is broken - it's ok, but you have to stop all the current development and make a fix OR rollback - it's what all the pretty textbook stuff devops methodologies teach us. There is no problem with broken build, there is a problem with recklessness about it. Add here automatic tests triggered by CI/CD, pre commits / push hooks tests and you will get even more layer of confidence ...

And last thing:

Sure, it's one of my scripts that does all the hard work, but I don't need to think about merging...

Actually you do, but not about technical aspects of merging, but about WHAT you merge, even the fact you have no conflicts or resolved ones does not mean the resulted code is right. Don't get me wrong I am not against merging, but merging is still hard ( not technically but logically ), TBD tries to avoid a lot of merging while gitflow upholds.

And I ask you again: How do you manage what goes to release when everybody is merging to one branch whatever and whenever they decide?

The same as with gitflow. At some point you cut off from main branch and create release one.