Git QuickStart -- Team Collaboration
This article will introduce how Git is used in daily collaboration scenarios. Before reading, please make sure that you have a basic understanding of Git and master the common command usage.
Git is a handy version management tool. How we use it depends on the scene of team collaboration. Many arguments about its usage deviate from the collaboration model of each team, which makes it seems a bit awkward.
Generally speaking, the main difference between scenarios is the size of the team. The key issues faced by two people co-developing a project and two hundred people jointly developing a project are naturally different. The following will assume that we are developing the back-end of a web project. Let ‘s starting from simple scenarios, gradually meeting questions and come up with feasible solutions.
If you are developing a project with your own, you can freely choose the development method. The most direct way is to develop the
master branch. When you think the function is completed, give a tag to the commit for CI/CD.
As the project expands, several collaborators are participating at the same time, and you find that your development process will affect each other. For example, you have modified the routing part, but you are still in the stage of fixing bugs, and then, your collaborators always Unintentionally triggering this kind of problem caused the page it developed crashed. So you started to explore more suitable ways of collaboration.
It is recommended to use the well-known Github flow.
There is a branch called
master in the project, assuming that we need to develop a document function, then we need to create a new
feature/document branch from the
master branch, and merge it into the
master branch after development.
Before the development of the document function is completed, assuming that we find that there is an important payment problem that needs to be fixed, then we can create a new
fix/ pay or
feature/pay from the
master branch, and merge it into
master after the fix is completed.
If the function division is reasonable, then it is not necessary to have the commit on the
fix/pay branch and the
feature/document branch at the same time. Even if it is needed, we can use merge, rebase, cherry-pick, which are similar but different.
When we pull the contents of the
masterbranch on the
feature/documentbranch, it means we think that “the function branch needs to obtain other newly added functions in this time”. The advantages and disadvantages are as follows:
Advantages: The operation is simple, and the existing
feature/documentbranch will get a new node.
Disadvantages: Additional merge nodes will be added. If there are three branches at the same time, after merging one branch to the master, a merge point will be added to each of the other two branches.
We can also choose to rebase the
origin/master, which means we recognize that “additional features exist as an infrastructure for the features being developed.” The advantages and disadvantages are as follows:
Advantages: The existing
feature/documentbranch will not add a merge node, the branch looks very clear and concise.
feature/documenthas been pushed to the remote and then rebased, then the local
origin/feature/documentare no longer considered as the same branch. The push operation will be rejected unless the push is forced, but this will make other collaborators on the branch also affected by the changes in the branch.
To circumvent this shortcoming, there is a way to only take the rebase operation when merging the completed branches, and delete the remote branch immediately after the rebase is completed.
We can also choose to cherry-pick all the contents of the
fix/paybranch on the
Assuming that the
fix/paybranch was merged into the
masterbranch and the squash operation was performed, then directly cherry-pick the node after the squash.
The advantages and disadvantages are as follows:
Advantages: The existing
feature/documentbranch will not add a merge node.
Disadvantages: The cherry-pick nodes will appear repeatedly in the merged branch in the future.
As the size of the project increases, you may want the project to be automatically integrated and deployed. You only need to set it to the current
origin/master branch, which is very convenient.
In most small teams, this model can work very well. The next thing to mention is the product of a specific scenario – when facing some unique needs, we often choose to make some changes to the process, and may also introduce additional complexity. In short, we don’t have to stick to one solution, just read the following scenarios and understand the solution to the problem.
The size of the team continues to expand, and you are more cautious about changes in the production environment. After discussion, you have built a pre-release environment and a test environment.
However, it is troublesome that CI/CD is processed for a certain branch, and your
master branch is bound to the production environment, and a separate branch is created for the pre-release environment and the test environment.
Perhaps some collaborators suggested that we can dynamically create a
Beta/test_featA_featB_timestamp branch each time the test environment is used, and hand this process over to the CI/CD tool.
It sounds good until you find that you need to resolve branch conflicts every time, so you start to look for more elegant solutions.
Maybe someone will propose at this time that we can add a
Dev branch, and whenever we need to go online, merge the code of the
Dev branch into
master. Although it increases the cost of maintaining the branch, you are more at ease when developing.
It has also been suggested whether the branch strategy of
Release can be adopted. A new
Release/version_code branch can be established after each version is released, which can be directly modified on the eve of the release to avoid repeated merge branches. Maybe the traditional project development team will take this strategy.
The team is getting bigger and bigger, you start to explore, can you use the same branching strategies in a larger dimension?
Regarding past strategies, maybe you will choose Git flow and use
ReleaseBranch, emergency fixes use
hotfix, and may also regulate the use of
rebase and other supplementary regulations.
Back at the beginning of this article, when we use Git as version management and collaboration tool, we might as well accept the limitations brought by it and other tools such as CI/CD, and choose the strategy which is suitable for the team.
- Github flow(https://guides.github.com/introduction/flow/)
- Git flow(https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
- The trend of the “develop” branch going away(https://softwareengineering.stackexchange.com/questions/312022/the-trend-of-the-develop-branch-going-away)
- What is CI/CD?(https://www.redhat.com/en/topics/devops/what-is-ci-cd)