Correct usage posture and best practices of Git: best practices for team collaboration and version control

Git is a version control system used to track and manage code changes in software development projects. It can track file modifications, additions and deletions and record the history of these changes. Git helps team members collaborate on development and provides an effective way to handle concurrent editing and code merging. In this article, we will introduce the correct usage posture and best practices of Git to better use Git to manage code for team collaboration.

1. Basic concepts of Git

Git has three local working domains: working directory, stage/index, and repository. If you include the git warehouse (remote directory) on the remote server, it can be divided into four work domains. The relationship is as follows:

(1) Four work areas

Workspace: The workspace is where you usually store project code.
Index / Stage: Staging area, used to temporarily store your changes. In fact, it is just a file that saves information about to be submitted to the file list.
Repository: The warehouse area (or version library) is a safe place to store data. It contains the data you submitted to all versions. HEAD points to the latest version put into the warehouse
Remote: Remote warehouse, a server that hosts code, can be simply thought of as a computer in your project team for remote data exchange.

(2) Work flow

The general process of git work:

Add and modify files in the working directory
Put files that need version management into the staging area
Submit the files in the staging area to the git repository

(3) Four statuses of files

Untracked: This file is in the folder, but has not been added to the git library and does not participate in version control. The status changes to Staged through git add.
Unmodify: The file has been put into the library and has not been modified, that is, the file snapshot content in the repository is exactly the same as that in the folder. This type of file has two places, if it is modified, it becomes Modified. If you use git rm to move out repository, becomes an Untracked file
Modified: The file has been modified, only modified, and no other operations have been performed. This file also has two places. It can enter the staged state through git add, and discard the modifications using git checkout and return to the unmodified state. This git checkout That is, take the file from the library and overwrite the current modifications.
Staged: Temporary state. Execute git commit to synchronize the modifications to the library. At this time, the files in the library and the local files become consistent again, and the files are in the Unmodify state. Execute git reset HEAD filename to cancel the staged storage, and the file status is Modified.

2. Git basic commands

git init: Create a new Git repository in the current directory.
git clone: Clone a Git repository from the remote server to the local one.
git add filename: Add files to the staging area of the Git repository.
git commit: Submit the files in the staging area to the Git repository.
git status: Check warehouse status
git log: View commit history
git reflog: View the operation log of the warehouse
git diff HEAD: Compares the differences between the current content and the last submitted version.
git checkout filename: Abandon modifications to the workspace code.

3. Operation of Git branch

Branching is often used when running multiple parallel jobs.

git branch : List all current branches.
git checkout : Switch to the specified branch.
git merge : Merge the code of the specified branch into the current branch.
git rebase : Change the code of the current branch to the specified branch.

4. Git collaboration

git push: Push the code in the local Git repository to the remote server.
git pull: Pull the latest code from the remote server.
git fetch : Pull the latest code from the remote server.
git merge : Merge the code of the remote branch into the local branch.

5. Version release

Every time a stable version is released, a tag should be created for that version. Tags can be used to identify a specific version of the code, making it easier to find and trace back in the future. The steps to create a label are as follows:

Switch to the master branch:git checkout master
Pull the latest code:git pull origin master
Create a label:git tag -a v1.0.0 -m "Release version 1.0.0"
Push tags to remote repository:git push origin --tags

6. Remote warehouse operations

Generate communication key: ssh-keygen -t rsa -C " [email protected] " , the generated public key is under /home/stu/.ssh/, as shown below.

2. Test whether there is connectivity with github or gitee (code cloud):

Test github command: ssh -T [email protected]

Test gitee, which is the code cloud command:

3. Clone the project: git clone project address

4. Submit the branch to the remote warehouse: git push origin branch name

5. Submit the branch to the remote warehouse and track the branch: git push -u origin branch name

6. Pull the branch on the remote server and update it locally: git pull origin branch name