Get started quickly with git Gitlab collaboration

Simple recording, sorting.

Summary

To make it easy for everyone to get started with git and work collaboratively with Gitlab, the manual is not too rich and in-depth.
It mainly contains the following content:

1. Git Usage Tutorials
   1.1 Installation
   1.2 Common commands
   1.3 Version Control
   1.4 Branches with Tag
2. Gitlab Using Tutorials
   2.1 Introduction to the interface
   2.2 General Function Introduction
   2.3 Precautions
3. Multi-person collaboration process and specification
   3.1 Permanent and temporary branches
   3.2 Workflow Diagram
   3.3 Specifications
4. Code Review
   4.1 Why you have code Review
   4.2 How do I proceed?

5. Resources

   Follow-up will join CI, automatic deployment and so on.

1. Git using Tutorial 1.1 installation

Recommended to install the latest version, and more than 1.7.

: Git download page
Official Installation Tutorial: Installation Tutorials

1.2 Common commands

Use terminal operations directly under Linux and Mac, and you need to right-click on "Git Bash" under Windows.

Using the company's Gitlab library, you need to ignore validation certificate legitimacy
git config http.sslVerify false

A. Cloning code libraries to local
Address is obtained in the gitlab.xsjcs.cn project, please select HTTPS address
git clone https://gitlab.xsjcs.cn/powerking/log-sever.git

B. Modifying the file and submitting it
git add file-name
git commit -m "注释"

Comments must be detailed, not "test", "Update" and so on. and try to use English instructions.

C. Push to remote branch, default is all
git push

D. Push to Main branch
git push origin master

For more commands please refer to:

git commands for Life

git command Quick check

1.3 Version Control

Usually we commit to a local code base which is the git add && git commit command that uses GIT push when it needs to be committed to remote.
So git's version control is divided into 2 blocks. Local and remote.

In a local command operation, you can also use git reset HEAD to undo the commit and git checkout to recover the file.

So there are three areas of the Git folder:

Actual directory: The file that was actually modified.
Pending area: Staging the content to be submitted, after submission is emptied. (also called Index area)
Submitted area: content submitted to the local Git repository, with version number.
Operations on these three zones can be done locally offline.

You can also git status view the file status by viewing the

A total of four states are in the file:
Consistent with Git repository
Inconsistent with Git repository, cached
Inconsistent with Git repository, not cached
Not yet added to Git repository

Usually we commit to a remote branch or development branch after the local operation is complete. Therefore, knowledge of the branch is involved.

1.4 Branches with Tag

Branches are used to separate feature development, and master is the default trunk when a warehouse is created. Usually we also create a development branch "Develop", and a test branch "testing". Each developer needs to develop a new feature, create a local branch "feature_a" locally, and then submit the branch for testing or development, tested and approved by the relevant personnel, and merge to the trunk.

Create a feature_a branch and switch to that branch:
git branch feature_a
git checkout feature_a
Switch back to main:
git checkout master
To view a list of local branches:
git branch -a
To delete a branch:
git branch -d feature_a

Merging branches
You usually need to use Git diff to see the version differences of the commits before merging the branches. There is a diff interface in the Gitlab interface to help us see. If no exception can be configured for automatic merging, manual action is required if the automatic Merge report conflict occurs.
Git add tag related information
Git merge merges other branches into the current branch before merging to confirm the current branch.

2. Gitlab Use tutorial

Gitlab interface is relatively concise, the current company configuration Gitlab does not support the SSH mode. Can only be done with HTTP (S). However, after registering, the user needs to configure personal information, especially the avatar. Recommendations are configured.

2.1 Introduction to the interface

It seems that this is not good to write, special personal avatar can be.

2.2 General Function Introduction

Create groups: Usually we create a group for a project. For example: Network Management Center, Xoyobox, operation and maintenance team development tools.
Create User: Currently open for registration, subsequent need for mail application.
Add users to a group: After you create a group, you can choose to have different users join groups for collaborative development.
Create Project: Projects can choose to belong to that group, and when they are created, they can also choose to import. After creation, the initialization information is registered to select the HTTP (s) protocol.

2.3 Precautions

Because the company configuration HTTPS certificate is not purchased, there is currently no request for free key, so you need to configure the validation certificate to ignore the legality:
git config http.sslVerify false

For more use, refer to: How to use Gitlab

3. Multi-person collaboration process and specification

To prevent 2 or more individuals from modifying a feature at the same time, or developing a new feature, strict specifications or processes are required to constrain it.
So we need to create a permanent branch with a temporary branch.

3.1 Permanent and temporary branches

Permanent Branch: Master Develop testing
Temporary branch: Created at development or release, deleted after a period of time.
Master: Trunk Branch, a stable version of the online release. The version number is even.
Develop: Develop the branch, merge the tests, or the branches that do not need to be tested together to master. When publishing, the version number is odd.
Testing: Test Branch for pre-test use of branch, can not add version number.

A few important notes:

Feature

Role: Develop new features
Branch Source: Develop
At the end: Merge Develop
Description: A feature branch that is used to develop new features for the next version. There is usually only developer local.

Release

Role: Release new version
Branch Source: Develop
At the end: merge Develop/master
Description: For new product release is to do support, generally used in the release, online environment updates. Need to have certain version update instructions, bugfix instructions, etc. After extraction, only small modifications are allowed, and no new feature are allowed to be added.

Hotfix

Role: Fix a bug in the release version
Branch Source: Master
At the end: merge Develop/master
Description: Hit the patch

3.2 Workflow Diagram

See figure

3.3 Specifications

Conventions:

1. Any version in the Master branch can be deployed immediately
2. Master merge operation for each master change from another branch
3. Must have review for master modification
4. No odd versions are allowed

4. Code review4.1 Why you have code review

It's not clear.

4.2 How do I proceed?

1. Recommended for the Gitlab interface
2. Branch and version number to be registered when submitting code
3. Use local git flow for merge operations

5. References

Github-flow
Git_gitlab

Get started quickly with git Gitlab collaboration