Lots of people often code using feature branching on git to avoid the hassle of conflicts while doing pull and/or to avoid pushing incomplete features that would break the system for all the team.
I find these reasons to be baseless and some even harmful to the development cicle. Trying to develop in your little temporal bubble without being distracted by the rest of your team it's a bad idea, imagine the following:
A team of five people have to do a painting of a big landscape, so they split the canvas in five pieces and then each of them paints their part without even looking at what their partners are doing and in two weeks they put all the five pieces together to deliver the product. What do you expect will happen? of course the painting will be a mess with miss aligned items on it that will need to be redrawn at the last minute pulling an all nighter on the worst case. Sounds familiar?
How can we work on a single branch without breaking stuff and without continuous conflict?
First the conflict part: Communication is key, daily meetings are there for a reason and should be used to smooth cooperation between developers working at the same classes.
Now, the scariest part: How to commit half baked features without breaking stuff? or even more, how to commit a new feature that we aren't sure is working correctly? Well, one of the best things about everyone working at the same branch is that if something breaks it will be noticed quickly and fixed at an early stage and therefore less painful process.
For the part of committing without breaking the system for everyone there is a very good technique called "feature toggling". Basically what you do is put an if like this:
if (useNewLogic) {
awesomeNewFeatureEntryPoint();
} else {
legacyEntryPoint();
}
This allows to run the new code when you want and where you want without risking all the environments and such.
This way of working also benefits of the fact that because everyone is working at the same place if your new feature conflicts with some change of class contract you can fix it quickly, it means that you are doing continuous integration.
One way I have found in my personal experience that people that comes used to work with branches feels more comfortable to do the switch is to have two branches, for example: develop and master. With the only way to put things on master is via a pull request.
I would love to read your opinions of this matter on the comments.
Latest comments (178)
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.
This really fails to understand the concept behind feature branches. The idea is NOT that a feature branch should go off by itself for 2 weeks at a time with no interaction, but rather than each developer should have their own control over when their code will not negatively impact others and when their code is in a state they can accept stable code from others.
In a well functioning feature branch flow, developers should be regularly pushing whenever their code is reasonably stable for the mainline branch they are working off of. Similarly, they should be pulling in changes from the mainline branch as often as possible to avoid long running conflicts developing.
What this means is that developers still get changes in a timely manner, but are exposed to significantly less thrash at inconvenient times. It does require developers to be responsible with understanding when their code is "stable enough" and to balance the risk of drift with the risk of both causing and receiving turbulence, but the alternative is to have things occur basically at random.
I think you're using Git wrong brother. You should be using Subversion instead.
That is why have a planning phase. So that everybody has a copy of what the final painting should look like, before they start painting.
The best way to get the right answer on the Internet isn't to ask the question, but to provide the wrong answer. 👍
Seriously now, as others pointed out, a proper use of Git flow solves the very same problems you're reintroducing here.
Again, if it works for you flawlessly, go for it 🤞
So what if I work in the same branch for two weeks without ever pulling in changes from my co-workers? Would that be exactly the same as how you describe working in branches?
On the other hand, what if I work in my own branch but pull changes from master into my branch consistently? Wouldnt that be the same as working in master and keeping up to date?
Branches are just scratch spaces as far as development goes. Once you are happy with the code that you want to dump on your co-workers, you merge, till then you keep it in your scratch space.
trunkbaseddevelopment.com/
I read you completely. Took 5 minutes thinking about it and trying to be in your shoes, and yet.. I cannot agree. As others said: I really respect your way of viewing things and, Man, honestly: If it works for you, then Congrats! There is more than a single way of achieving things in programming.
But what works for me is to have feature branches and merge: A wild conflict appears and we resolve it. We check that the resolution works (QA again) and Done!
I couldn't disagree more. I've worked on teams using a single branch methodology and it was always a mess. I've had no problems at all with a feature-branching approach. You give a cute analogy with the painting but it doesn't really hold up in real life. Of course, there are organizational challenges with it as well, but nothing that isn't manageable. Working in feature branches on a single project is like different mechanics working on the same car. If one works on the exhaust while another is fixing the brakes, you're fine. If you ask both to do different tasks, both on the engine, then sure, you're gonna have problems. So... just don't.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.