This article was originally intended to be written in the way of introducing functions, but after writing a part, I found that there is nothing to write about. The functions will be used by those with a bit of experience, so I decided to start over to introduce gogs from the perspective of usage scenarios.

Introduction

The most famous Git code hosting platform is GitHub, and there are also code clouds available in China. If you want to build a Git hosting platform yourself, the most famous one is to use GitLab. But for simplicity and ease of use, our company chose Gogs as our Git hosting platform.

Gogs (Go Git Service) is an extremely easy to build self-service Git service. Gogs' goal is to create the easiest, fastest, and easiest way to set up a self-service Git service. Development in Go allows Gogs to be distributed as a standalone binary and supports all , including Linux, Mac OS X, Windows, and ARM platforms.

Gogs provides the easiest-to-use Git project team multi-person collaboration management system. Its main functions include warehouse management, organization management, user management, code authority management, code submission management, and behavior records.

Official website: https://gogs.io/

installation and configuration

The installation and configuration official website provides a more detailed introduction, and the configuration of different versions may also be different.

So only give the official website description link

Official Instructions: https://gogs.io/docs/intro

Collaborative approach

I feel it is necessary to discuss how the project will collaborate before explaining.

We divided the project group into two organizations, the interface group and the mobile client group. The number of teams in each group is determined according to the number of warehouses, that is, each warehouse is responsible for one team. Create a master branch in the warehouse as the production online branch, merge the tested development branch code into the master branch and create a tag for version marking before going online. Each repository may have multiple development branches, managing business modules developed in parallel. Programmers only have the submission authority of the business branch, and the trunk is managed by the development team leader.

Manage R&D team

The first thing we need to do when using gogs is to enter our own R&D team and conduct effective classification and organization.

The following describes the general process step by step

1. Create a user

Create gogs accounts for project team members. We generally set the "Maximum number of warehouses allowed to be created" to 0 and do not allow programmers to create remote warehouses by themselves.

After the creation is complete, team members need to fill in a custom name, upload an avatar, set their own password, and configure an SSH public key in "User Settings".

2. Create an organization

The founder of the organization sees the benevolent and the wise see the wisdom. If the project team is relatively small, it is enough to establish an organization and assign several teams. If the organization is complicated, several more organizations can be established. Each organization has some warehouses of its own. If each department does not need to share warehouses, organizations can be established separately. For example, our company has created two organizations, namely the interface group and the mobile client group. The warehouses of these two organizations do not overlap.

3. Create a team

Team members have the same collaborative repository and the same repository read and write permissions. I understand something like a role definition. The establishment of the team is mainly based on different warehouses and different read and write permissions. Git can't assign permissions by directory (it's a pain in the ass to use SVN), so obviously programmers who share the same repository don't need to build two teams. Our company business group has two warehouse interfaces and management backgrounds. We set up two teams for management. Of course, team members can be repeated.

4. Add team members

Team members can be selected among existing users. Team members automatically become members of the organization after they are added.

Assign warehouse permissions

1. Create a warehouse

The owner of the repository can be a user or an organization. If it is an organization, the organization administrator has administrative rights to the repository.

Repositories can be set to public or private. Shared projects are similar in nature to open source, and all users can clone. So all our repositories are private, and we only add collaboration to those who need it.

2. Allocate team warehouses

If a team assigns a warehouse, the warehouse will become a collaborative warehouse for all members of the team.

3. Allocate user warehouses

We can also set up a repository as someone's collaborative repository. Generally, the warehouse is allocated through the team, unless one person has different permissions to the warehouse than others, then we can configure it separately here. A common situation is that the development team leader needs to have the management authority of the warehouse and configure it separately here.

4. Warehouse permissions

Warehouse permissions are mainly divided into read permissions, write permissions, and management permissions.

Read permission: has the permission to view and clone the repository to which it belongs.

Write permission: has the permission to view, clone and push the repository to which it belongs.

Admin Permissions: Permission to view, clone, push and add other organization members to the team.

Programmers generally assign write permissions, and project leaders assign management permissions.

(It should be noted here that you may not be able to push if you have read and write permissions to the warehouse, because branches can be restricted from pushing, and the branches will be explained in detail later)

branch management

1. Create a branch

After the repository is created, a default branch master will be created. But gogs doesn't provide the ability to create branches (at least the version I'm using doesn't). If we need to build a dev branch, we need to create a dev branch locally, and then push it to the gogs remote warehouse.

$ git branch dev
$ git push -u origin dev:dev

2. Protect the branch

Protecting branches is important because you cannot limit the level and care of the programmer. Programmers have the possibility of branch commit errors or delete branches by mistake, and we want to limit the possibility of errors to a minimum.

The image below shows what we are able to restrict in branch protection

Our approach is to check the first and third items of the production branch (master), and select the development team leader as the member who can push the code, so as to ensure that only the development team leader can change the production branch code. Instead, check the first item of the development branch (dev) to prevent programmers from accidentally deleting the branch.

conflict handling

Dealing with conflicts is a headache for me, or it may be due to my lack of academic skills. In the past, companies often dealt with conflicts and lost code, so it is best to be careful when dealing with conflicts.

1. Conflict handling before code commit

This is usually the case when two programmers pull code from the same node and then modify the same file.

If we pull the branch before committing the code, the system will prompt that the files will be overwritten, please commit or stash them.

error: Your local changes to the following files would be overwritten by merge:README.md
Please commit your changes or stash them before you merge.

At this time, we can use the command git stash to store the work and view the storage area git stash list.

$ git stash
Saved working directory and index state WIP on dev: 7725ccf 2018年4月2日09:20:15
$ git stash list
stash@{0}: WIP on dev: 7725ccf 2018年4月2日09:20:15

Then pull again. After a successful pull, we need to restore the contents of the storage area git stash pop --index

$ git stash pop --index
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Index was not unstashed.

Those files are prompted for merge conflicts during recovery, and then we have to manually resolve the conflicts.

After that git add . to commit the merged work to the staging area. The conflict resolution is now complete.

$ git add .
$ git status
On branch dev
Your branch is ahead of 'origin/dev' by 20 commits.
  (use "git push" to publish your local commits)
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   README.md

2. Conflict handling after code commit

If we pull the branch after committing the code, we will be asked to handle the conflict.

CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Then we do conflict handling manually.

After that git add . to commit the merged work to the staging area. The conflict resolution is now complete.

$ git add .
$ git status
On branch dev
Your branch is ahead of 'origin/dev' by 20 commits.
  (use "git push" to publish your local commits)
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   README.md

3. Trunk merge conflict handling

When we use different development branches to merge (rebase) to the master master, conflicts will arise if different development branches modify the same file.

When rebase, the system prompts a merge conflict error

First, rewinding head to replay your work on top of it...
Applying: 测试上传
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M       README.md
Falling back to patching base and 3-way merge...
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Patch failed at 0001 测试上传
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

git add . after manually resolving conflicts and continue rebase git rebase --continue

$ git rebase --continue
Applying: 2018年4月2日09:20:15

If the file is modified multiple times, a conflict will be prompted every time when rebasing, we have to modify it again and again and continue.

Although we have resolved the conflicts in the master branch, the "patch branch" code still has conflicts. In order to avoid dealing with these conflicts next time, we'd better regenerate the development branch so that the code of the development branch is consistent with the latest master before subsequent development.

Production goes online

When the development branch meets the online requirements through testing, we merge the development branch into the master branch by rebasing, and then tag the master branch to determine the online version.

1. The development team leader pulls the latest development branch and master branch to the local.

$ git pull

2. Then switch to the development branch to perform the rebase

$ git checkout master
Switched to branch 'master'
$ git rebase dev
First, rewinding head to replay your work on top of it...
Fast-forwarded master to dev.

3. Create an online label

$ git tag -a v3.5.0 -m "v3.5.0 go live"

$ git tag -n
v3.5.0          v3.5.0 go live

4. Push the rebased code and tags to the remote warehouse

$ git push
Counting objects: 113, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (113/113), done.
Writing objects: 100% (113/113), 9.66 KiB | 0 bytes/s, done.
Total 113 (delta 72), reused 0 (delta 0)
To ssh://192.168.17.247:10022/PL_service_department/pmall.git
   8866a0b..c7a8275  master -> master

5. The server deploys the service using the generated tag

Fix production bugs

When there is a bug in production, we need to create a production branch to modify it, and also merge it into the development branch.

1. Create a production bug branch

git branch bug1

2. Modify the code on the production bug branch

3. After the modification is completed, rebase to the dev development branch

$ git checkout dev
$ git rebase bug1
$ git push

4. Test development branch

5. After the test is completed, push the bug branch to the remote warehouse

$ git checkout bug1
Switched to branch 'bug1'

$ git push -u origin bug1:bug1
Total 0 (delta 0), reused 0 (delta 0)
To ssh://192.168.17.247:10022/PL_service_department/pmall.git
 * [new branch]      bug1 -> bug1
Branch bug1 set up to track remote branch bug1 from origin.

6. The development team leader obtains the bug1 branch and merges it into the master for production deployment

$ git rebase origin/bug1
First, rewinding head to replay your work on top of it...
Fast-forwarded master to origin/bug1.
$ git push
Total 0 (delta 0), reused 0 (delta 0)
To ssh://192.168.17.247:10022/PL_service_department/pmall.git
   c7a8275..9bbeea4  master -> master

7. Delete the remote bug branch

$ git push origin :bug1
To ssh://192.168.17.247:10022/PL_service_department/pmall.git
 - [deleted]         bug1

merge commit (interactive rebase)

When we develop code locally, we go through multiple commits, but these commits are obviously meaningless to remote repositories. Remote repositories only want general information about the last commit. So we're going to proceed and commit.

1. First, we make multiple commits locally

2. Enter edit mode git rebase -i HEAD^^^