When I train developers on `git` in combination with GitHub, I emphasize that `git` the tool was written for a specific goal. Linus wrote it to replace BitKeeper for the express purpose of collaborating on the maintenance & development of the Linux kernel.
The biggest problem is when developers who do not really understand version control at all (there are a lot of them -- they tend to think of it as a "save" mechanism) are allowed to use all the features of GitHub and can only do their work with buttons.
For example, it is common for some developers to think that there are only two options when dealing with merge conflicts: "Accept theirs" or "accept ours" when, in reality, most real merge conflicts require a synthesis. Now, add to this the fact that such developers barely write commit message (seen too many projects with only "merge X and Y", "update", "fix bug", "implement feature" etc). The situation gets worse.
Soon, you end up with a project where the only tool for locating any issue becomes `git bisect`.
Yes, some devs just can't merge. Even worse, IntelliJ & co have this "magic merge" button, that resolves conflicts automatically, but the results are usually a mess, esp when merging complex features. But because lazy devs are lazy, they just smash that button, commit, push without testing locally and then move on to the next topic. Naturally, we've had countless CICD failures which were attributed to "merging in git is sooo broken" ...
Comments
When I train developers on `git` in combination with GitHub, I emphasize that `git` the tool was written for a specific goal. Linus wrote it to replace BitKeeper for the express purpose of collaborating on the maintenance & development of the Linux kernel.
The biggest problem is when developers who do not really understand version control at all (there are a lot of them -- they tend to think of it as a "save" mechanism) are allowed to use all the features of GitHub and can only do their work with buttons.
For example, it is common for some developers to think that there are only two options when dealing with merge conflicts: "Accept theirs" or "accept ours" when, in reality, most real merge conflicts require a synthesis. Now, add to this the fact that such developers barely write commit message (seen too many projects with only "merge X and Y", "update", "fix bug", "implement feature" etc). The situation gets worse.
Soon, you end up with a project where the only tool for locating any issue becomes `git bisect`.
Yes, some devs just can't merge. Even worse, IntelliJ & co have this "magic merge" button, that resolves conflicts automatically, but the results are usually a mess, esp when merging complex features. But because lazy devs are lazy, they just smash that button, commit, push without testing locally and then move on to the next topic. Naturally, we've had countless CICD failures which were attributed to "merging in git is sooo broken" ...