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.

Introduction

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.

Scenes

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.

Collaborative development by a few people

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.

• merge

  When we pull the contents of the master branch on the feature/document branch, 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/document branch 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.

• rebase

  We can also choose to rebase the feature/document branch to 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/document branch will not add a merge node, the branch looks very clear and concise.

  Disadvantages: If feature/document has been pushed to the remote and then rebased, then the local feature/document and remote origin/feature/document are 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.

• cherry-pick

  We can also choose to cherry-pick all the contents of the fix/pay branch on the feature/document branch.

  Assuming that the fix/pay branch was merged into the master branch 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/document branch 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.

Multi-environment coexistence

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?

Possible choices

Regarding past strategies, maybe you will choose Git flow and use master, Dev, ReleaseBranch, emergency fixes use hotfix, and may also regulate the use of rebase and other supplementary regulations.

Conclution

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.

More

1. Github flow(https://guides.github.com/introduction/flow/)
2. Git flow(https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
3. The trend of the “develop” branch going away(https://softwareengineering.stackexchange.com/questions/312022/the-trend-of-the-develop-branch-going-away)
4. What is CI/CD?(https://www.redhat.com/en/topics/devops/what-is-ci-cd)