Convention Git specification
Everyone should follow the rules for branch naming, tagging, and coding. Each organization has its own specifications or best practices, and many suggestions are available online for free, and it is important to choose the appropriate specifications as early as possible and follow them in the team.
At the same time, the Git level of different team members varies. You need to create and maintain a set of basic instructions that conform to the team's specifications for performing common Git operations.
Commitizen is a tool for formatting commit messages. In short, git commit is similar to writing a note after you make a modification. Now that npm installs commitizen, you can use git cz instead of git commit. You can choose the type of commit each time you commit, so The commit text will be more readable.
Merge conflicts correctly
Each team member needs to develop on a separate feature branch. But even if a separate branch is used, everyone will modify some common files. When merging changes back to the master branch, the merge usually cannot be automated. It may be necessary to manually resolve conflicts between different people on different changes to the same file. This is why you have to learn how to deal with Git merges.
Modern editors have functions to assist in resolving Git merge conflicts. They provide various options for merging each part of the same file, for example, whether to keep your changes, or keep the changes from another branch, or keep them all. If your editor does not support these features, then it may be time to change to a code editor.
Use git rebase to merge conflicts, which means frequently performing the following steps:
git pull --reabase origin master
// 改完冲突后重新提交代码
git add .
// 重新提交不要写提交信息
git rebase --continue
// 退出
git push origin feature-todo -f
// 再次提交到远端需要强推
These steps will rewrite history on your feature branch (which is not a bad thing). First, it will make your feature branch get all the current updates on the master branch. Second, all your commits on a feature branch will be rewritten at the top of the branch's history, so they will appear in the log sequentially. You may need to resolve merge conflicts along the way, which may be a challenge. However, this is the best time to resolve conflicts, because it only affects your feature branch.
If you use a "pure merge" strategy (git pull origin master), then the history of the master branch will be interspersed with the submission of all concurrently developed features. Such a chaotic history is difficult to review. The exact submission time is usually not that important. It is best to have an easy-to-view history log.
Combine multiple messages
When you develop on a feature branch, even the smallest modification can be used as a commit. However, if each feature branch has to generate fifty commits, then as new features are continuously added, the number of commits in the master branch will eventually expand unnecessarily. Generally speaking, each feature branch should only add one or a few commits to the master. To do this, you need to merge multiple submitted messages into one or several submissions with more detailed information. This is usually done with the following command:
git rebase -i HEAD~20
// 合并20个提交
git commit --amend
// 编辑完之后执行退出
Finally, since the Git commit history of the branch has been rewritten, the remote branch must be forced to update.
Use label
When you have finished testing and are ready to deploy software from the master branch to online, or when you want to keep the current state as a milestone for some reason, you can create a Git tag. For a branch that has accumulated some changes and corresponding commits, the label is a snapshot of the branch at that moment. A tag can be seen as a branch without history, or as a named pointer that directly points to the commit before the tag was created.
git tag v1.0.0 -m "1.0.0版本"
In addition, if signed tags are helpful to your project, consider using them.
Consider a situation where the software version corresponding to the Git tag has been distributed to the customer, and the customer has reported a problem. Although the code in the code base may have been under development, in order to accurately reproduce the customer's problem and fix it, it is necessary to fall back to the code state corresponding to the Git tag. Sometimes the new code may have fixed the problem, but not always. Usually you need to switch to a specific tag and create a branch from that tag:
git checkout v1.0.0
// 切换到分发给客户的标签
git checkout -b bugfix-todo
// 创建新的分支用于重现 bug
Git is a complex tool that takes time to master. Using these practices can help the team better use Git for collaborative development.