This is the 7th day of my participation in Gwen Challenge

One, foreword

Seeing a Git-related article on Nuggets with more than 1,000 likes makes me envy it.

Git is a very important part of work, if the operation is not skilled or the use of non-standard, it is easy to cause a lot of trouble to work

  • For example, it is customary to write all functions in one branch, resulting in the inability to separate online
  • For example, the code in the Git repository is too large because you commit a dependent directory
  • Such as merge branch error, will not live code commit
  • For example, the branch name is not standard, causing the branch to be deleted

This article is just a part of the front-end engineering practice, since the overlap, I will write something different, the basic will not write too much. This article will focus on the following aspects:

  • Git usage scenarios
  • Git branch names are recommended
  • Git multi-party development branch management
  • Git record submission specification
  • Git graphical interface SourceTree and its usage are recommended

Some common problems of new students using Git

Recently, when I was helping new students to get started with the project, I found that they would have some minor problems when using Git, mainly because they are not familiar with it. I would like to mention them here for discussion.

1. Problem 1: Not familiar with Git concepts and operations

We’ve all seen this newbie, who just started the project, wrote the code and submitted it to the mentor for review, and then directly compressed the code and sent it to the mentor, and made a package for each update. This is crazy.

This is typical of not being familiar with Git, and it is necessary to read more documentation and force yourself to use it. Actually know the principle, Git commonly used just a few commands, it is not difficult.

2. Problem 2: Code merge, conflict, and save code without taking advantage of Git’s powerful features

Git merge merge git merge git merge git merge

It is easy to fail when merging. Conflicts occur or there is no latest code on the pull line, resulting in the current header falling behind the master. Therefore, git pull must be used before merging.

3. Problem three: Branches are built randomly and information is submitted randomly

Branches don’t cost money, but the time to review code and find branches does. If the name is arbitrary, it will be easy to forget and take time to recall the code, so it is necessary to standardize the branch name.

Submit information to write freely, such as test, temporary save, well, I also did, but now change. Good information is written in a format that makes it easy to find historical submissions and is pleasing to the eye.

4. Which of the following code submissions do you think is more professional?

In fact, these problems are not difficult to solve, as long as the attitude in place, skilled operation and some norms, minutes become excellent.

2. Common problems in using Git

Git a distributed version management tool, the local installation of Git, through a variety of commands can be code to pull, merge, submit, etc., he is also a programmer’s basic skills. Git is the best way to write code for SVN.

1..gitignoreConfiguration rules that allow the use of re

The.gitignore file allows Git to filter files or folders that do not need to be committed, such as 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 is half developed, so we need to stop and fix the Bug on the line. What should we 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.

3. Git conflict handling

It’s not unusual to have conflicts when merging code. Merging conflicts is easy, but it’s also easy to get confused. When a conflict occurs, I usually use VSCode to resolve it.

You can see the conflict in VSCode, and then select the option above to handle the conflict. If the comparison between the two is not obvious, you can also select Compare Changes

4, VScode install the plug-in, real-time view each line of code modification information

With GitLens — Git Supercharged, you can display the following information: who modified, when modified, and submit information, so that you can clearly find the author of the code

Git naming and management specifications

1. Git naming conventions

One of the great advantages of Git’s distribution and pointer location is the low cost of creating branches, so make the most of branches

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.

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

2. Development process

Diagram of development process and branches:

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

  • fromdevelopBranch detectionfeature/login, developed over a period of time
  • Need to release version test, at this time fromfeature/logincreaterelease/login, deploy the branch code and test it
  • Bugs in testing, infeature/loginFix, then mergerelease/loginBranch, submit second test build, third test build, etc
  • After the test passes, mergerelease/logintodevelopbranch
  • Confirm that there is no problem, merge the master branch and deploy online
  • deletefeature/login release/loginbranch

When you need to fix an online login page bug

  • frommasterBranch detectionhotfix/loginMerge the master branch, verify that it is ok
  • mergedevelopbranch
  • deletehotfix/loginbranch

Here according to the actual development needs, the common workflow on the Internet has been modified, the specific difference is to see below

3. In actual work

(1) The difference between common branch management on the Internet and here

In the process of consulting materials, I found many branch management as shown in the figure, but there is a problem in the actual use of the process.

Features are iterative, with multiple developers working on different features in different order, merging them into develop’s pre-release branch makes it easy to merge other people’s branch code into live code that shouldn’t be live.

Of course, you can also do this on different nodes and check out the pre-release branch by version number, but it’s always confusing because many of the release requirements are made by the boss on a whim.

Therefore, I will not merge the feature branches to Develop first, but first check out the pre-issued branch, then test the iteration, and finally merge the Develop branch without any problems.

You can merge develop to Master or release to Master.

If you have different opinions here, welcome to exchange them. Of course, you can also use SourceTree directly to get the branch management strategy such as Gitlab.

(2) Castrated version of the branch management

In fact, the above branch management strategy is already excellent.

But for many in-house projects, there may be less formal classifications.

For example, for an internal project, many people develop at the same time, basically each person is responsible for a function, and then also responsible for fixing the bug on the line. There is only one pre-release environment, and it may be tested at the same time. At this time, it is very troublesome to have so many pre-release branches.

At this point, I would recommend a castrated version of branch management

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

  • Zhang SAN wants to develop the login function:zs/feature-login
  • Zhang SAN wants to fix the bug of obtaining user information:zs/bugfix-userinfo
  • Li Si will develop the registration function:ls/feature-register

In this way, everyone’s branch is very clear, and it is not easy to delete by mistake, but also can distinguish the role of the branch, the disadvantage is that the branch name is a little long.

3. Git information submission specification

The code submission specification, which is not so important, is only used for code review and historical data query, but it can help you keep track of code updates.

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

4, Git graphic chemical tool recommendation

Git has many excellent graphical management tools, such as SourceTree and SmartGit, that make branching and updating easier. Amway is a tool that lets you type in commands line by line without having to use Git command-line tools.

I recommend SourceTree, which has the following advantages and disadvantages:

  • First, it’s free. Second, it’s easy.
  • The display is detailed and monitors code updates in real time, both for remote repositories and local changes
  • You can roll back code block by code base
  • Shows the submitted history information and the relationships between branches
  • Security, does not allow you to delete unmerged branches unless you force the deletion
  • Disadvantages: compared to the command line, a little slow, but does not affect the use, after all, it executes the command more detailed.

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.

Git bash can be used to generate keys using Git bash

  • 1, through theGitCommand line generation. For details, see section Git Generationsshkey
  • 2, through theSourceTree.sshAssistant to generatekey

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 togit clone, as long as the project address can be cloned 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, and here we highlight these six areas, which are also commonly used

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)

  • File status, mainly shows the current project you track modified, deleted files or untracked, new files, corresponding commandgit status
  • History, temporary file commit history and description, branch merge path information corresponding to the commandgit log.git grash
  • Search provides a pair ofgit logThe encapsulation

Third workspace

  • Branch: The commands used includegit branch -a, you can see the current branch directly
  • Label: Displays all label contents
  • Remote branch: All branches of the remote repository
  • Storage area: equivalent togit stashTemporary code saved locally

Fourth region

The main configuration, according to each Tab switch to display different content, filtering log data, file state partition, a clear display of the relationship between branches and context

At the same time, the content of the modification will be real-time access, this is very convenient, for example, you do not need to open the Gitlab web page, you can directly see here.

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

Note: There are some differences in the interface between MAC and Windows SourceTree

Five, reference articles:

  • Git documentation
  • How do I use Git in my work
  • Git branch development specifications you must know
  • Ruan Yifeng branch management