“This article has participated in the good writing call, click to see:Back end, big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!”

Use Git tools efficiently

Directory:

1. Some common problems with Git
2. Git branch naming conventions are recommended
3. Git multi-party development branch management
4. Git record submission specification
5. Git graphical interface SourceTree and its usage are recommended

I: Some common problems in the use of Git

1. Gitignore configuration rules, allowing the use of re

The.gitignore file allows Git to filter files or folders that do not need to be committed, such as proxy configuration files, packaged files, dependencies, editor configurations, etc. Specific filtering rules are as follows:

• /build/ do not commit the entire folder
• *. Zip Filters all. Zip files
• /docs/do. TXT Filters a specific file
• ! SRC/Do not filter this folder

Specific syntax:

1. Directories begin with a slash /;
2. Wildcard multiple characters with asterisk *;
3. On the question mark? Wildcard single character
4. Contains a list of matches for a single character in square brackets [];
5. In order to exclamation point! It does not ignore (trace) matched files or directories.

Executed from top to bottom, the following commands override the preceding ones

2, the current branch function development is half, need to stop to fix the bug on the line, how to do

Using the Git Stash directive, you can save your temporary changes locally. This clears out your workspace, then switch branches to deal with bugs, and when you’re done, you can switch back to the original branch and restore your changes through the Git Stash directive, rather than committing the half-written code directly to the staging area

Git branch naming conventions are recommended

Conventional branch naming

First, when a project is created, the default master branch (now Github has changed to main branch) is used as a production branch. For particularly important projects, this branch can be set as a protected branch, allowing only administrators to operate, thus avoiding code clutter. Of course, 90% of the code is probably not needed.

###### (1) Stable branch

• Master/Main branch: production environment code that records each iteration and keeps the branch stable and cannot be modified directly.
• Test branch: the branch of the version-to-test, which records the iteration of each version-to-test to keep the branch stable and cannot be directly modified.
• Develop branch: Development branch. Development functions need to be checked out from the current branch and remain stable, with the latest version.

###### (2) Unstable branch

• An unstable branch is one that updates frequently and has a lifetime.
• Release branch: Pre-release branch that can be created for testing when a feature has been completed, such as Release /login Release/Account
• Feature branch: Function branch. When a function needs to be developed, this branch can be created and deleted after the development goes online. feature/login feature/register
• Hotfix branch: it has the shortest life cycle. It is established temporarily after bugs are found and deleted after bugs are fixed. Branch name: hotfix/login Hotfix /register

The master and Develop branches remain stable, and the rest of the branches are named in the following format: name prefix/branch name

• Zs /feature-login
• Zs /bugfix-userinfo = zs/bugfix-userinfo
• Li 4 should develop the registration function: LS /feature-register

Three: Git multi-person development branch management

For example, when a new feature landing page needs to be developed

• Check out feature/login from the master branch and complete the development after a period of time
• If the Develop version also fixes some basic problems, merge the Develop branch to the Test branch and deploy the test environment branch code to test the test environment
• Test bugs, fix in feature/login, merge test branch, commit second test version, third test version, etc
• If the develop version also fixes some basic issues, you need to merge the Develop branch to the Master branch and deploy it online
• Delete the feature/login branch and merge the master branch with the latest version

Be sure to keep in mind:

• The dev branch is mainly used to develop fixes for problems with the daily release, and does not need to merge other branch code
• During development, there is no need to merge code into the dev branch, avoiding contamination between branches that could result in a rollback failure if needed
• For both phase 1 and phase 2 content, the branch is removed once live and the new development branch is checked out from master again
• Once live, the dev branch needs to merge with the Master branch

Git record submission specification

Description (Optional) Incompatible with <Footer> or close issue. (Optional) The Subject is a short description of the commit. Verb + Object + Adverb (not more than 50 characters) Add code and logic such as Add XXX field/method/class 2. Change: code update, such as Change XXX to yyy with reason 3. Remove: Remove old features/features such as Remove XXX which was deprecated 4. Fix: Fix bugs such as Fix #123, Fix XXX error 5. Update/Release: 5. Update/Release XXX version to 1.0.0 Write a detailed description of what this commit did and why (but not how) - no more than 70 characters per line. What problem does this change solve? 2. Why is this change necessary? 3. What other code will be affected? Bug fix - Component bug fixes; Breaking change - incompatible changes; New feature - Footer is used to close an Issue or add a description if there is an incompatibility. 1. Close related issues (link) 3. Revert: Undo previous commitCopy the code

Git graphical interface SourceTree and its usage are recommended

You are advised to use the same tools

A, install,

Download from SourceTree

2. Configure user information

• 1. Configure the user name and email address to be displayed as information in the submission code
• 2. Configure the SSH client

First, you need to install Git on your machine and generate a key, just like the server command line.

####### You can use Git bash to generate keys in two different ways

• 1. Generate the sshkey using the Git command line. For details, see section Git Generating sshKey
• 2. SSH Assistant generates keys using SourceTree

Generally, Windows keys are under User\ user.ssh_ID_rsa, and the selected protocol is OpenSSH

The key of a Linux COMPUTER is usually stored in the root/. SSH directory, where there is a public key and a private key.

Mac keys are usually stored in the /home/.ssh directory

Create or introduce a project

• 1. Add the existing local repository and manage the local Git repository with SourceTree
• Create a remote repository. SourceTree helps you create a remote repository directly
• 3, clone from URL, equivalent to Git clone, as long as the project address can be clone to the local
• Add local repositories that already exist locally. If you have a local Git project, you can import it directly
• Create a git repository. Select a folder that is not a repository and create a git repository
• 6. This way we can use git command to manipulate project through SourceTree.
• 7. After successful introduction, it looks like this

Iv. Description of work area

The SourceTree interface is divided into several areas

The first workspace, the top section, is mainly Git’s common operations, including

• Git add
• Git pull
• Git push
• Git fetch
• Git branch, Git checkout, git push -d branch
• Git merge
• Git stash
• Git workflows, which automate the creation of different branch processes, help multiple people collaborate to develop and manage branches, similar to those described in our section on branch management
• Remote: Click to display the remote repository information of the current project, providing git remote v and modification and deletion functions
• In command line mode, open the bash command line quickly at window
• Resource manager, one click to open the project folder directory
• Set the remote repository configuration and Git configuration information Settings

One of the cool things about this area is that whenever the code is updated online, it will remind you how many versions are behind the current version and remind you to pull the code in time instead of using the command to pull the code every time.

Second WORKSPACE (WORKSPACE WORKSPACE information)

Git status history, temporary file submission history and description, branch merge path and other information corresponding to the command git log, Git grash searches provide encapsulation of Git logs

Third workspace

Branch: You can use git branch -a to visualize the currently created branch tags: Show all the tag contents Remote branch: Remote repository All branch stash: equivalent to git Stash, temporary code stored locally

Fourth region

Main configuration, according to the different content of each Tab to switch display, screening of log data, file status partitions, clearly shows the relationship between the branches and context And to modify the contents of the can real-time acquisition, this is very convenient, such as you change some code, don’t need to open the Gitlab web page, can see here directly.

Conflicting interfaces appear

Merge conflicts display yellow exclamation marks.

Fifth Working area

Git logs commit-id and the changes between the two versions

Sixth working area

The difference between a specific commit- ID change is shown in the figure above. On the right, you can roll back blocks of code, which is very convenient