How git makes branching not to be feared? [closed]

Question

I'm a beginner in the Git world, previously working solely on centralized version control mechanism, namely TFS (tfvc) from microsoft. I already read couple tutorials, editorials, questions/answers on stackoverflow as well as created couple git repositories in which I work, but nothing fancy so far.

I'm curious as to why so often I run into statement like "why I feared branching before, but not anymore with git", or something to that sort? I'm not questioning that statement, I'm just looking for the reason as to why it is so.

From the editorials I've read, and how I understand git architecture so far, I do understand how branching is easy, and how lightweight it is (branches are simply pointers to commits), but still there is nothing magical about avoiding merge conflicts etc. The scheme of how the conflicts arise is the same, so why me, a beginner in git world, should not fear of doing many branches, switching between them, commiting, merging etc?

Thus far I work in a small team, so we have 1/2 people per project, so there are virtually no merge conflicts (no suprise there), but say you have a team of 50 engineers, who all are working on various parts of the application, and I just cannot help but think, that it's simply a nightmare every once in a while for them, when all those commits start to intersect one another.

Having a company convention, like same IDE's, same whitespacing schemes etc, is all fine and good, but it applies to any version control mechanism, doesn't it? So to finish my small remark, and repeat the main question:

"Why I should not worry about working on branches in git vs other version control mechanisms"?

Thanks in advance

Answer 1

It depends...

if you have 50 people merging back to same branch then yes! You might have merge collisions and hell with git, with svn, with any tool (git merge is a little more sophisticated but it would not solve it!)

If you locally branch and merge as a "standalone" developer you will have nothing to fear.

Bottom line, the term has been abused. branching and merging is a theoretical concept and you are perfectly right, it does not matter which tool you use, branching and merging are still the same abstract concept and should be feared and unfeared - the same with any tool!

The change which git brings is mainly that it allows for quick branching and merging, locally or by distributed developers, but again if you have 50 people merging same code base - fear it - many merge problems will indeed occur git does not solve it (will have many screams here by git advocates :) ).

The issue here is ofcourse we have too many people working on same codebase and this does not relate to any source control tool but to teams structure and whether to use micro services or the monolyth design.