1) Git was developed for an environment where people did not necessarily have the ability to have meetings every: distributed development 2) This is somewhat outside the scope of this discussion but I've found that having developers work on the same code (where conflicts are likely to occur) leads to a lot of disagreements and resentments about "the right way to code this, or format this etc". Good developers tend to be opinionated and it's hard to get them to agree. You must be working with very malleable co-workers :) 3) Developers should merge from master often, yeah, but that's true with branching too. I don't see a difference here from branching to non-branching 4) A branch is just a label/tag that follows the changes made over multiple commits. At the time of merging, it's just another commit as far as conflicts go. 5) There are many times where you are forced to work on something and put your current work aside. What are you supposed to do then, push broken code to master, so you can check out master on a different branch to fix a bug that needs to be done immediately?
If there were no branches, I could never commit any partial work I'd done on my computer. Like if I have to leave work and resume coding on my home computer. You are describing the old style of version control with a central server.
We use feature flags all the time, and we branch for our work. But it's because we have different requirements in different geographic regions. Some regions don't use a certain feature so it has to be turned off for them. When we merge to master that deploys code to canary boxes (beta tests). In my world, shipping a problem could mean the end of the company, so no matter how good our tests are, we want verification on an actual production machine before deploying everywhere. (We have no testers or QA people)
We have hooks that force the regression test to run and code review before any merge to master. That prevents almost everything you are complaining about. I think code review is non-productive but it's part of legal requirements.
Your complaint seems to be about lack of communication and frequent merging, not branching. I agree. Frequent merging from master and running regression test is key to avoiding conflicts and hard to debug merge problems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
1) Git was developed for an environment where people did not necessarily have the ability to have meetings every: distributed development 2) This is somewhat outside the scope of this discussion but I've found that having developers work on the same code (where conflicts are likely to occur) leads to a lot of disagreements and resentments about "the right way to code this, or format this etc". Good developers tend to be opinionated and it's hard to get them to agree. You must be working with very malleable co-workers :) 3) Developers should merge from master often, yeah, but that's true with branching too. I don't see a difference here from branching to non-branching 4) A branch is just a label/tag that follows the changes made over multiple commits. At the time of merging, it's just another commit as far as conflicts go. 5) There are many times where you are forced to work on something and put your current work aside. What are you supposed to do then, push broken code to master, so you can check out master on a different branch to fix a bug that needs to be done immediately?
If there were no branches, I could never commit any partial work I'd done on my computer. Like if I have to leave work and resume coding on my home computer. You are describing the old style of version control with a central server.
We use feature flags all the time, and we branch for our work. But it's because we have different requirements in different geographic regions. Some regions don't use a certain feature so it has to be turned off for them. When we merge to master that deploys code to canary boxes (beta tests). In my world, shipping a problem could mean the end of the company, so no matter how good our tests are, we want verification on an actual production machine before deploying everywhere. (We have no testers or QA people)
We have hooks that force the regression test to run and code review before any merge to master. That prevents almost everything you are complaining about. I think code review is non-productive but it's part of legal requirements.
Your complaint seems to be about lack of communication and frequent merging, not branching. I agree. Frequent merging from master and running regression test is key to avoiding conflicts and hard to debug merge problems.