Use Git for project management

This document is mainly compiled based on my project development experience. Gitlab-usage-demo includes tutorials on how to use Git and the company’s Gitlab platform for project development, version management, and code backup.

Git management tools with a graphical interface are more convenient and intuitive than the command line.

  • Vscode: if you are using Vscode as your development environment, Vscode integrates Git natively and provides a wealth of git-related plug-ins, including GitGraph, GitLens, etc. Vscode version control official documentation
  • GitKraken: This tool is easy to use, the UI is my favorite style, it is friendly to beginners who don’t have much experience with Git, and the learning cost is relatively low. What I particularly liked was how clear the branching and commits were. GitKraken official tutorial

This tutorial uses git command line tools to demonstrate.

Creating a new project

Create projects on Gitlab

Log in to your Gitlab account Gitlab address and click the New Project button to create a New Project. Fill in the project name, project description, and select project access rights. Company projects are generally selected as Internal, meaning that login is required to access the project, and external personnel do not have access rights. Click Create Project when you’re done.

Clone the project locally and initialize the project code

Git clone http://118.31.44.251:3000/hanbing/gitlab-usage-demo.git CD gitlab usage - demo touch README. Md git add README. Md  git commit -m "add README" git push -u origin masterCopy the code

Developing new features

Create new branches and complete functionality development

When Git projects are created, the default branch is the master branch. In the development process, try not to directly develop on the main branch, it is best to create a new branch, create new functions on the development branch, after testing merged into the master branch.

Create a new branch

Git checkout dev # Switch the current project to this branchCopy the code

Write the project code according to the requirements of the project. Create a new main.py file and add the HelloWorld code

vim main.py
Copy the code

Add the following

print("Hello world!" )Copy the code

View the project status at this point

$git status = "git add < file >..." The main.py commit is empty, but there are files that have not yet been traced (use "git add" to set up the trace)Copy the code

Commit the modified file

Git add. # add all changes to git commit -mCopy the code

Multiple changes can be committed multiple times until the current feature is developed and tested.

Merge the current functionality into the Master branch

Once a feature has been developed and tested, the corresponding code can be merged into the Master branch

Git merge devCopy the code

Commit to the remote repository

git push origin master
Copy the code

At this point, you can view our submission results on GitLab

At this point, if the dev branch has been merged, then we can delete the branch

git branch -d dev
Copy the code

Project online

Use tag tags to tag important versions

When all functions are completed according to the project design, the project can be deployed online. In order to keep the historical version of the online project and roll back to any historical online version, you need to use tag for management for each online deployment. When you need to roll back to a historical version, you simply switch to the corresponding tag. A tag is not a branch, but rather a milestone, marking each important live release.

To create a tag, -a specifies the tag name and -m specifies the commit information

Git tag-a v1.0-mCopy the code

View information about a tag

Git show v1.0Copy the code

When you need to roll back, you can switch to this tag

Git checkout v1.0Copy the code

Commit the tag to the remote repository

Git push origin v1.0Copy the code

Bug fixes for historical versions

We are always developing and incorporating new features on the master branch, and we need to fix bugs that are found in the live version. This can’t be done on the master branch because the live version always lags behind the master branch, so it’s best to create a new branch from our tag and fix the bug. Put a new label on the repaired version after it goes online. Here we demonstrate this on a sample project.

At this point we look at the current status of the project

# hanbing @ shuding1 in ~/MyProject/gitlab-usage-demo on git:master o [11:13:20] C:1
$ git branch       
* master

# hanbing @ shuding1 in ~/MyProject/gitlab-usage-demo on git:master o [11:13:43] 
$ git tag     
v1.0
Copy the code

We currently have the Master branch, and since this version is already available, we tagged it as V1.0 to indicate that this is the first version we have available. Due to the new requirements, we needed to develop version 2.0 on the Master branch, and we submitted some new code on the Master branch for demonstration purposes

echo "print(\"Hello world! My name is hanbing.\")" >> main.py git add mainCopy the code

A few days after launch, operations found some bugs in V1.0 and submitted them to developers for fixing. At this point, we could create a branch from V1.0 and fix the bugs on this branch.

Git checkout fix_bug_v1.0 # Switch to the created branchCopy the code

Add the code at the newly created fix_bug_v1.0

Echo "print(\"Fix a bug of v1.0.\")" >> main.py git add main.py git commit -m"Copy the code

At this point, look at our main.py, which should have the following

print("Hello world!" ) Print ("Fix a bug of v1.0.")Copy the code

After testing and launching, we can put a new label on it, V1.1

Git tag-a v1.1-m "git push origin v1.1 git checkout master # switch back to master branchCopy the code

This way we can fix bugs without affecting the development of new features on the Master branch.

Changes to historical versions are merged into the Master branch

At this point we have fixed the bug in the online version in time. The same bug may exist on the master branch as well. We need to merge the changes into the master. At this point, we can create a new branch merge_bug_fix on the master branch and merge the bug fixing code. After testing, we will merge the merged code into the master branch.

Git checkout merge_bug_fix # Switch to the branch you createdCopy the code

Merge the code that just fixed the bug

Git merge v1.1 merge a main.py conflict: Merge a conflict with main.py.Copy the code

The merge failed because we added different code between the master branch and the second line of V1.1. In this case, the conflicting locations are shown in the main.py file and we select the code we want to keep. Here we choose to keep both

print("Hello world!" ) <<<<<<< HEAD print("Hello world! My name is hanbing. ") = = = = = = = print (" Fix a bug of v1.0. ") > > > > > > > v1.1Copy the code

After modification, our main.py file looks like this

print("Hello world!" ) print("Hello world! ") print("Fix a bug of v1.0.")Copy the code

We commit the above changes

Git add main.py git commit -mCopy the code

The merge_bug_fix branch becomes the common upstream branch of master and V1.1, allowing us to switch to the master branch and merge the merge_bug_fix changes

$git checkout master $git merge merge_bug_fix 987e446.. 4499939 Fast-forward main.py | 1 + 1 file changed, 1 insertion(+)Copy the code

The merge is successful. At this point, we have merged the changes that we need to keep from the historical version onto the main branch.

Cooperative development

Involve other people in the project

Select Setting->Members on the left of the project to add developers

Select Developer as the permission (please refer to the instructions of Gitlab for details, and you can give different permissions according to your needs. Link) and click Add to Project. Developer permissions allow you to create, merge, modify branches, and create new tags. Each developer can create a branch locally, develop their own code module, and merge it into master or another branch after passing the test. (See above for the merge method).

The Folk project uses Merge Requests to request merging its own changes

When there are few developers, the above method can be used for cooperative development. As the number of developers grows, multiple developers commit or merge code to the same branch at the same time, causing confusion. So at this point we can’t give everyone a Developer permission. How do different developers contribute their code to the project at this point? The answer is the Folk and Merge Request (the same as the Pull Request on Github) described in this section.

First Folk the items you want to contribute to

The project from Folk is now owned by you, and you can submit your modifications to the project as if it were your own. For example, if I see that the readme.md for this project is not perfect, I can add some project descriptions to readme.md.

This is a Step by Step Git tutorial.Copy the code

Once added and committed, we can see the result of the submission on our project page.

Create Merge Requests by selecting the New Merge Requests button on the left side of your project

Here we choose to submit the code of our Master branch to the Master branch of the original project. After clicking “yes”, you can fill in some current modification instructions for the developer of the original project to review the code.

After clicking Submit, the original project developer is presented with a Merge Request Request

At this point the project developer sees your request and can directly select Merge. Normally, we don’t do this. Instead, we download the submitter’s code as a local branch, examine the submitter’s code carefully, and merge it into the branch that the submitter wants to commit. The specific steps are as follows. Click the Check out Branch button to see the submitter’s project address, which you can do at this point.

  • Procedure Step 1 Download the contents of merge Request as a new branch

    $git fetch http://118.31.44.251:3000/hanbing2/gitlab-usage-demo.git master remote: Counting objects: 3, done. The remote: Remote: Total 3 (delta 0), Reused 0 (delta 0) in flue: 100% (3/3), done. From http://118.31.44.251:3000/hanbing2/gitlab-usage-demo

    • branch master -> FETCH_HEAD

    $git checkout -b hanbing2/gitlab-usage-demo-master FETCH_HEAD = ‘hanbing2/gitlab-usage-demo-master’

  • Step 2 Check the changes he has committed locally. For details, see merging changes to historical versions into the master branch above.

  • Step 3 Merge conflicts and submit them

sh git checkout master git merge hanbing2/gitlab-usage-demo-master git push origin master

At this point, Gitlab last show merge success

Best practices

This section describes some of the specifications developed using Git

Add the. Gitignore file for the project

A large number of intermediate files may be generated during project development, including intermediate files for code compilation, resource files and so on. These files are usually not added to Git for management, which will cause a large number of modification records and interfere with our code management and development. The best way is to add the.gitignore rule to the project, ignore these files and only keep the core code and configuration files.

The project has various.gitignore templates that become language projects, which can be used as a reference to help you ignore intermediate files generated during code execution.