how to place common team code in prod
Release branches are temporary branches in Gitflow that are created to prepare for the release of a new product.
The release branch is used for the following purposes:
Preparing for the release of a new product
Creating a release version of the project
Testing and debugging code before release
When you create a release branch, you create a separate branch to prepare for the release of a new product. The release branch contains changes that are ready to be released, but have not yet been officially released.
The release branch is used for the following types of changes:
Fixing errors
Code optimization
Adding new features
Gitflow recommends using release branches for the following purposes:
Creating a temporary branch to prepare for a new product release
Testing and debugging code before release
Merge changes into the master branch so that they are officially released
Thus, the release branch is used only for temporary changes – it should not contain changes that could affect the functionality and security of the project.
Once you've finished preparing the release, you can merge the changes into the master branch to release them officially.
How to overcome conflicts in merge requests
Let's say we have two completed changes that need to be pushed to prod. They are in different feature branches and are not yet included in master.
The first thing you need to do is create merge requests in the develop branch. I told you how to create MRs hereonly this time each developer chooses their own branch as the starting point, and the develop branch as the target.
Let's assume that Ivan completed the development faster than Masha, created an MR that passed the checks and his code got into the develop branch earlier than Masha's code. The testers successfully started testing this code. Masha also finishes her task. She has a few more changes, she made them to the files and classes already changed by Ivan.
And when Masha began to perform merge requestthen I received this message:
Essentially, Masha got a merge conflict, or a merge conflict – this is a situation that occurs in Git when you try to combine changes from two or more branches. But Git cannot automatically merge these changes because they conflict with each other.
This happens when you try to merge changes from two branches that modified the same file or region of a file. Git doesn't know how to merge the changes, so it leaves the file in a conflict state.
Merge conflicts can occur when you try to combine changes from two branches that modified all or part of the same file.
Git provides you with several ways to resolve merge conflicts:
1. Manual merge: Manual conflict handling is the ability to manually edit files and resolve conflicts.
2. Automatic merge: auto-merge – Git's ability to automatically merge changes, but can sometimes lead to errors.
3. Resolve conflict: Conflict resolution is Git's ability to leave a file in a conflict state that can be manually resolved later. (Unless you and your team have agreed that you are leaving project files in this state, I highly recommend against doing this, as it will break your project. If you cannot resolve this conflict, it is better to leave this MR alone and contact your more experienced colleague.)
The file area with the conflict looks something like this:
“`
<<<<<<< HEAD
Here is the content of the file that is stored in the merge branch
=======
Here are the changes that lead to conflict
>>>>>>> feature/new-feature
“`
There are several ways to deal with conflicts. But here I will consider one using the built-in tools of the Intellij IDEA IDE.
The algorithm for solving the Machine's problem is as follows. When we get a merge conflict, here's what to do:
1. Update locally the branch you made the merge request to. In our case, this is the develop branch.
2. Merge changes from the locally updated develop branch into the branch that caused the conflict. In our case, this is the feature/masha_feature branch.
3. After local merge you will get the same conflicts that you got when creating merge requestonly locally. And the list of conflicts is displayed in a separate window:
4. To resolve conflicts, select the file you want to fix and click the merge button. (You can use the IDE and select only your changes or the changes that are currently in the merge branch (Accept Yours or Accept Theirs), if the changes allow you to do so.)
An editor will open in a separate window where you can resolve the conflict.
On the left are your changes, on the right are the changes in the merge branch, in the center is the resulting file
You can move the changes to the center by clicking “>>” if you want to move the changes to the right or “<<” - to the left. By clicking on the cross, you will mark the changes. You can also make changes to the center yourself, manually.
In our case, we transfer the changes to the left by clicking on “>>”
And we cancel the changes on the right by clicking on the cross
When all conflicts are resolved, the window will display the message All changes have been processed. Save changes and finish merging. You can click on it or on the Apply button. After that, the file will be saved and will disappear from the list of conflicting ones:
5. After all conflicts have been resolved, the IDE will commit the changes itself and all that remains is to send these changes to the remote repository.
After these manipulations in merge request the notification banner will disappear and such a request can be successfully closed:
After this, the feature/… branch can be deleted.
Now that all the changes are in the develop branch, we need to create the release I wrote about above. We will also do this through the web interface.
We will create a release branch from the develop branch by clicking on the “+” opposite it.
Then we enter the release branch name and the release name. Since this is our first release, let's name the branch accordingly:
Usually, testers roll out the release branch on test servers and test this branch, after which we can create a merge request to the master branch and roll out the application to the production server. As a result, the code of all team members gets into production.
That's all for now. In the next final article I'll tell you what to do if a bug has slipped through to the master branch and appeared on production. Stay tuned for new releases.
