preface

Hello everyone! Some time ago, I watched a video on a certain station. In the video, a programmer with three years of work experience was fired on the second day because he could not use Git to pull a project on the first day he joined the company. It’s terrible to think about it. After learning this article, I believe you will get a lot. Well, without further ado, come on!

positive

What is Git?

  1. Git is an open source distributed version control system that can handle project version management from very small to very large projects efficiently and quickly.
  2. Git is an open source version control software developed by Linus Torvalds to help manage Linux kernel development.

1 Basic Configuration

1.1 User Information

For the user information of developers, please use the full spelling of Chinese pinyin, such as “Zhang San” and “Li Si”, pay attention to the capital letters of the first and last names, leave a space in the middle, and fill in the email address of the company, such as “[email protected]”. The command line is as follows:

Git config --global user.email "git config --global user.name"Copy the code

1.2 Environment Configuration

Windows due to the difference between the permission system and macOS, the newline is also different, so for The Windows platform to use Git need to do the following configuration:

git config --global core.filemode false
git config --global core.autocrlf false
Copy the code

For macOS, just run the following command:

git config --global core.autocrlf false
Copy the code

Git config –global -l git config –global -l

If you change the case of a file or folder name during project development, git will not detect it by default.

git config --global core.ignorecase false
Copy the code

2 About Git branches

Branching is one of the most powerful features of Git. It allows you to develop in multiple scenarios concurrently. It also allows you to develop different features at the same time without conflict, for distinguishing features or versions

Long-term branch:

Master: a distributable stable release branch that stores releases to the public. Any time a release is obtained from this branch, it is a stable release

The development branch is used for daily development and stores the latest development releases

The common development main line branch and the code of feature function branch will be merged into this branch after code review after the completion of the development

Temporary branches: Once development is complete, they are merged into Develop or Master and then removed.

The feature branch is usually checked out from the Develop branch.

Hotfix Branch: patch branch emergency repair. It is used to repair problems in the production environment after the patch branch goes online

Release Branch: Pre-branch test, release mainline, this branch is checked out from the Develop branch, usually used in the roll-out phase

2.1 Main Branch and Development Branch

The master branch is named master, and there is only one branch. All official versions must be published from the master branch and associated with the release Tag. The master branch can only be merged from other branches and cannot be changed on this branch.

The daily development branch is called Develop and has only one branch. In principle, when developing in parallel, the Develop branch is responsible for the most changes, such as large code refactoring, interface framework replacement, major version updates, or regular iterations.

2.2 Functional branches of temporary branches

For the upgrade of larger functional versions, different functional branch features are divided for management, which is convenient for functional testing on the one hand and code adjustment corresponding to requirement changes on the other hand. [Currently only used in local branches, do not upload to the server, reduce the workload caused by code conflicts]

Feature -{$build_version_id}, feature-{$JiraID}, Feature -{$featureName}, such as feature-logedit, is pulled from the Develop branch.

Once the processing is complete, the code is merged back into the Develop branch for submission to the server, and the temporary branch is deleted after the merge.

2.3 Patch branch of temporary branch

For those that are working on the main line but need temporary support for another bug or another event trigger, you can publish the branch separately.

Named hotfix-*, the name can be temporary processing event identifier or JiraID, such as hotfix-{$JiraID}, hotfix-{$eventName}, need to pull a patch branch from the master temporarily change.

After the modification, merge into the release branch pre-publish and master branch publish, delete the temporary branch after merge.

2.4 Pre-published branches for temporary branches

For released versions, they need to be released to a pre-release environment for acceptance and identified by the version number.

Release -*, depending on the version, such as release-{$version_id}, or a temporary release release-{$version_id}-{$jiraID/eventName}, You need to merge it from another branch (develop or Hotfix).

Master merge after pre-release.

2.5 Multiple development branches of the same repository

If multiple services share the same repository, the development process should be developed separately by service. Do not commit all services to the Develop branch.

Name it “service id -dev”, treat it as the Develop development branch, and then merge the publishing page into the Master branch.

2.6 Schematic diagram and flow chart of each branch:

3 Code Submission

Do one thing to submit the code, submit the remarks as accurate as possible, concise, do not submit the code of multiple things at the same time.

Commit comments should be concise and scope-conscious, and do not omit a description of how the commit function is implemented.

Commit Annotation specification, different in different cases:

The following is a copy from Jane’s book, let’s standardize, according to the Chinese name is easier to remember:

  • Feat 【 add 】: abbreviation of Feature, a new Feature or Feature
  • Fix: To fix a bug
  • Docs [document] : File modification, such as modifying the ngDoc content of a project in which ngDoc is applied
  • Style [interface] : format modification. Such as changing indentation, Spaces, removing extra blank lines, and filling in missing semicolons. In short, changes that do not affect the meaning and functionality of the code
  • Refractor: Code is refracted. Code changes that do not fix bugs or add new features
  • Perf [optimization] : short for Performance, to improve code Performance
  • Test: Tests the modification of files
  • Chore [Other] : Other minor changes. Typically a change of just one or two lines, or a small change committed several times in a row

If the version number exists, you can add the version number identifier to make the template cleaner. Commit Template PS: start with lowercase letters, do not end with a period, and use semicorn

Git commit -m '<type>(<scope>): <subject> [<issue_id>]' git commit -m ' Changed select component animation [issue-123]'Copy the code
  1. Type: branch behavior
  2. Scope: Indicates the scope of the commit impact, such as the data layer, the control layer, the view layer, and so on, which can vary from scenario to project
  3. Subject: A short description of the commit purpose
  4. Issue_id: If your change is for an issue in Git, add issue_id to the commit record

3.1. Gitignore file

This file will configure the ignored file list. Please try to save it in the root directory of the project. In addition to temporary files that do not need to be submitted and compiled output data, some local user-related configurations can also be added to the ignored file list.

3.2 Daily Build

The daily build server is typically based on the Release branch, and if the release is determined to be ready for release, the code is merged into the Master and Develop branch, and the release is built through the Master branch.

It is also possible to start daily builds of develop as part of daily development, but in principle you can only start daily builds of one branch at a time.

4 Code Distribution

4.1 Applying for Merger of Master Branches:

Master merger can be directly applied from GitLab, and the warehouse administrator is responsible for the merger;

4.2 Application Version Release:

In the pre-release test environment, build the test environment from the corresponding development branch, as for the test environment planning, another chapter explains. [Environmental differentiation needs to be considered when development joint tuning and testing are in parallel]

5 Git repository naming conventions

The project name should be in uppercase, the space is the department name, and the default is CPStudio.

Classification:

Default system entry codes, all named with system abbreviations, such as CPStudio/EKP

A separate API, named after the system plus _API, such as CPStudio/EKP_API

Backend timed task system, with system abbreviation plus _task, such as CPStudio/EKP_TASK

Other categories of subsystems, underlined with abbreviations for subsystems, such as CPStudio/EKP_RES, represent template library resources for the EKP system.

6 facilitate the cooperation process of code review

When writing code, in order to ensure the quality of the code to share knowledge with the developers, code review is usually included. Merge Request or pull Request is used to do this, so we should try to keep the commit record as one as possible, which has many advantages:

For code review, we only need to look at the logic of this commit record. In case the code of this commit causes problems, we can quickly reverse only this commit. Keep a commit record for a feature. If you need to commit the feature to some environment, such as production environment, you can quickly use the cherry-pick command to “reproduce” the commit record on the corresponding branch to achieve the goal of committing the feature in advance.

You may wonder if the principle of keeping a single git commit record is inconsistent with the principle of keeping a single Git commit record as fine-grained as possible. I feel there is no conflict because the two Git collaboration requirements are based on different perspectives. We need to keep each particle size in a commit a change, so we record working content and convenient do rollback in the branches, but for the main branch of a software development, it submitted should be based on function unit, without having to care about this function within the developers to develop this function how many times did change.

In this case, we use the rebase command, also known as the derivative operation. A derivative is the process of re” deducing “your branch’s commit records at a base point on the branch in order that they are slightly different from the original commit. The difference is that the HashId of the commit is different, but the commit content is the same.

The rebase command provides an interactive interface and multiple commands that allow you to combine multiple commit records into one, thus achieving our goal of maintaining a single commit record and keeping the commit history clean.

7 the git command

Git clone, Git push, Git add, Git commit, Git checkout, Git pull

  • git clone: Make a copy of the remote repository, i.e. download an item.
  • git push origin master: Pushes the file to the server
  • git add .: Adds all files in the current directory to the staging area
  • Git commit -m: Submit the temporary storage area to the warehouse area
  • git checkout [branch name]: Switches to the specified branch and updates the workspace
  • git pull: Local and server synchronization

8 Differences between SSH and HTTPS

Finally, let’s return to the topic. For the Clone project, in the management of Git project, most of the time, HTTPS URL is directly cloned to the local, of course, some people use SSH URL to clone to the local.

The main differences between the two approaches are:

  1. It is convenient for beginners to use HTTPS URL clone. Copy the HTTPS URL and clone it to git Bash directly. However, each fetch and push code needs to enter the account and password, which is also the trouble of HTTPS.

  2. SSH URL cloning requires an SSH key to be configured and added before cloning. Therefore, if you want to use SSH URL cloning, you must be the owner of the project. Otherwise, you cannot add SSH keys. In addition, SSH default is that every fetch and push code does not need to enter the account and password. If you want to enter the account and password every time for fetch and push, you can also set it separately.

It-scm.com/ Pro Git, a comprehensive introduction to Git, is available here. It-scm.com/ Git Magic, a very popular introduction to Git book, relatively short and refined.

Today is here, get to the small partners like support support, what deficiencies and lack of place, welcome to the comment area correction!