Using version control software is a best practice and industry standard nowadays for high performing software and development teams. If you are not familiar with Git and what is version control, check this website out https://www.atlassian.com/git, which provide a good introduction and tutorials.
During my past experience, most of my projects and teamwork followed Feature Branch Workflow. Whenever the developer starts working on a feature or fixing bugs, they could create a new feature branch based on main branch/master branch.
The reality is that different development team probably have different set up with their branches and development path due to some historical reason. I am going to talk about the situation that I experienced in my work. Hopefully, my experience could give you some inspiration and get a better understanding about version control.
We have three major branches, which are not deletable. They are prod-branch, qa-branch, and dev-branch. All the tasks/features we start to work on need us to create a new feature branch based on prod-branch. Once we finished the task, we’ll merge the feature branch into dev-branch and qa-branch for 1st and 2nd QA testing. If the code passed the QA testing, we could deploy the feature branch to prod-branch.
Ideally, this way won’t cause any issue if we strictly follow the process, since these three branches are equally the same with different purpose. In fact, there are some shortcomings during our development. First, we don’t have a version control for qa-branch and dev-branch, the differences between qa-branch and dev-branch are increasing while the code base is getting larger. When your feature branch merged into dev-branch and qa-branch, it could lead to different result, the developer has to spend extra time to correct differences. Second, if the developer is working on a complicated project and has been testing for a while, your feature branch is probably already far behind prod-branch. Once your feature branch is ready for launch, it could cause many conflicts that need to be solved, which for sure will cause more time to fix this. From the other perspective, whenever you want to do any upgrade or migration to the environment, if these three branches are not exactly the same, the developer need to spend triple time to get the work done.
It’s hard to maintain a development environment perfectly without any issues/conflicts, but the development environment that I am currently working on is definitely not a good practice of version control, but there is always pros and cons while we are making decisions in different stages of our lives.
