Practical sharing of version control using Git

1. Introduction

Git is currently the most popular distributed version control system and is widely used in front-end development. Git's powerful capabilities allow developers to effectively manage code, collaborative development, and track code changes and version releases. Mastering Git best practices can greatly improve the efficiency and code quality of front-end development.

In this article, we will explore some of the best practices front-end developers should follow when using Git for version control, from basic Git operations to complex collaboration patterns.

2. Basic concepts of Git

2.1 The role of the version control system

Version control system (VCS) is used to manage file changes in projects, track modification history, and support multiple developers to work together. Git is aDistributed version control system, which means that each developer has a complete historical copy of the project, can work offline and can be developed in parallel through different branches.

2.2 Basic operations of Git

• Initialize the warehouse: Execute in the project foldergit initInitialize the local Git repository.
• Cloning the repository:usegit clone <warehouse address>Clone the remote repository to the local area.
• Add a file:usegit add <file>Add the modification to the temporary storage area.
• Submit the file:usegit commit -m "Submit information"Submit the modification of the temporary storage area to the local repository.
• View status:usegit statusCheck the modification status of the current project.
• Push code:usegit pushPush local commits to the remote repository.
• Pull the code:usegit pullPull the latest code from the remote repository.

3. Git best practices

3.1 Using meaningful submission information

When submitting code, the submission information should be as concise and clear as possible to help team members quickly understand code changes. Recommended to follow the following submission information format:

• Format：<Type>(<Scope>): <Short Description>
  • type: Describe the type of the submission, such asfeat(New features),fix(Fix bugs),docs(document),refactor(Reconstruction) etc.
  • scope: Optional, used to specify the scope of impact of the submission (such asmoduleorcomponent）。
  • Short description: Briefly describe the content of this modification.

Example：

git commit -m "fix(button): Fixed button click eventbug"

3.2 Submit in small steps, frequently submit

It is recommended that developers submit in time when completing each independent function, repair or improvement, rather than accumulate a large number of modifications before submitting. Frequent small-step submissions help keep the code history clear and easy to debug and rollback.

Advantages：

• It is easier to find the specific time point when the problem occurs.
• Roll back a small function without affecting other parts.
• Improve the efficiency of code merging when teamwork.

3.3 Develop with branches

Branches are one of the important features of Git, and front-end developers should use branches to separate different development workflows. Recommended branch management models include:

• Main branch (main/master): The main branch saves the production environment stable code. All code merged into the main branch must be tested and ready to be published.
• Development branch (develop): The code used in development can be unstable, but it is then merged into the main branch after testing.
• Feature branch: Each new function should be developed on a separate branch and merged into the development branch after completion.
• Fix branch (bugfix/hotfix): Used to urgently repair bugs in production environments, quickly create and repair them, and merge them into the main branch.

Branch naming specifications：

• feature/xxx: New function development.
• fix/xxx: Bug Fixed.
• hotfix/xxx: Production emergency repair.

3.4 Code Review

In front-end team development, code review is an important step to improve code quality and avoid potential errors. Submit code through Pull Request (PR) and invite team members to review the code.

Benefits of code review:

• Improve code quality: One more person to review the code can make it easier to find potential problems.
• Knowledge Sharing: Team members can learn different development techniques from each other by reviewing the code.
• Standardized code style: Ensure that the code style of the entire project is consistent.

3.5 Reasonable use.gitignore

In each Git project, there should be one.gitignoreFiles, used to specify which files should not be traced by version control. Files that usually need to be ignored include:

• Compile the file:like.cssand.jsFile (if generated using a preprocessor).
• Dependency package:likenode_modules/Folder.
• Environment configuration file:like.env, avoid pushing sensitive information to remote repositories.

A common one.gitignoreThe file example is as follows:

# Project Ignore Rulesnode_modules/
dist/
.env
.DS_Store

3.6 Code Merge and Rebase

During development, when it is necessary to merge the code of one branch into another, Git provides two main methods:MergeandRebase。

• Merge: Keep the history of each branch and create a merge commit between branches.

  • Advantages: Keep the commit history of each branch, and the history is more complete.
  • Disadvantages: If merged frequently, it may cause confusion in branch history.

• Rebase: "Replay" the commit of the current branch onto the latest commit of the target branch.

  • Advantages: Avoid generation of merge commits, and branch history is more linear and clear.
  • Disadvantages: The commit history may be modified, and inappropriate use may lead to conflicts.

For functional development, it is usually usedrebaseTo maintain the clarity of branches; for branches that are urgently repaired or long-term development, it is recommended to usemerge。

3.7 Avoid submitting large documents

Large files such as pictures and videos may be generated in front-end projects. These files are not suitable for submitting directly to Git repository because they occupy a large amount of warehouse space and increase the time to pull the repository. It is recommended to host large files to CDN or use Git LFS (Large File Storage) to manage large files.

3.8 Manage versions using Git Tags

When releasing production versions, you can use Git's tagging feature to mark specific version numbers. For example, after version 1.0.0 is released, you can create tags using the following command:

git tag v1.0.0
git push origin v1.0.0

In this way, team members and CI/CD tools can clarify the release time and content of a certain version, which facilitates subsequent search and debugging.

3.9 Backup of remote repository

In addition to pushing code to remote repositories such as GitHub and GitLab, it is recommended that developers backup code to other remote platforms to prevent data loss due to single platform failure. Git's distributed feature makes backup operations very simple, you only need to point the remote address to other platforms:

git remote add backup <Backup warehouse address>
git push backup

4. Summary

Version control using Git is an indispensable skill in front-end development. By following best practices such as submitting specifications, using branches reasonably, conducting code reviews, merging strategies, and managing large files, we can ensure the code quality of the project and the efficiency of teamwork.

Mastering these Git best practices can help front-end developers better manage code, reduce potential problems in development, and improve long-term maintainability of projects.

The above is the detailed content shared by the practice of using Git for version control. For more information about using Git for version control, please follow my other related articles!