Git: From Syntax to Practical Collaboration

To do a good job, one must sharpen one's tools#

The most important thing is to download Git 🚀
Terminal Plugin: oh-my-zsh (mac) | oh-my-posh (windows)
Vscode Plugin: Git Lens | Git Graph

Why Git?#

As software development becomes more complex, collaboration has become essential in project development. I wonder how everyone gets the latest code from their teammates when collaborating. I believe many have shared project files like this, including myself. However, using QQ for collaborative development has several pain points:

Manual code merging (human eye diff)
No way for multiple people to develop simultaneously
Simple overwriting may lead to one's own code being overwritten
No way to record code modification history (Ps: don't know who wrote the mess, don't know who needs to fix the bug)
No way to revert code versions (or you compress every time, which is silly)

Of course, using QQ and other communication software for collaborative development will encounter various pain points, so using Git for collaborative development is very important. Git was created for this purpose. Let me show you how Git describes itself.

Git granularizes each code change into individual commits and, through different local branches and upstream online branches, allows everyone to develop locally and finally merge into the remote repository, achieving efficient collaborative project development, whether for a small project with two or three people or a complex project developed by hundreds of people. It can effectively solve the problems of collaborative development.

Therefore, learning Git is essential for every programmer, whether for projects done for teachers or future work in a company. Without further ado, let's start learning Git.

Basic Concepts of Git#

The local repository is relative to the remote repository (the local repository may lag behind the remote repository, so it needs to pull remote repository information before development to prevent code conflicts).
Local repository = working directory + version area
The working directory is the collection of files on the disk.
The version area (repository) is the .git file.
The repository = staging area (stage) + branch (master) + pointer Head
- Taking the most frequently used git command as an example, submitting to GitHub.
- git init originally only contains the working directory; this is the most common working state. At this point, running git init creates a .git file in the local area, establishing the version area.
- git add . means to submit all files in the working directory to the staging area in the version area.
- Of course, you can also add files to the staging area one by one using git add ./xxx/.
- git commit -m "xxx" submits all files in the staging area to the repository area, leaving the staging area empty.
- git remote add origin https://github.com/name/name_cangku.git connects the local repository to the remote repository.
- git push -u origin master submits the files in the repository area to the remote repository.
- Once submitted, if you have not made any changes to the working directory, the working directory is "clean." You will see the message nothing to commit, working tree clean.

Using Git Code Hosting Platforms (GitHub)#

Due to network issues in China, GitHub may not be accessible.

You need to use a proxy and configure Git proxy#

// Please use the actual proxy port

git config --global https.proxy http://127.0.0.1:1080

git config --global https.proxy https://127.0.0.1:1080

Set up your account#

// GitHub is widely used, you can set your GitHub account globally
git config --global user.name "Your Name" // Binds your name to all your Git repositories

git config --global user.email "Your Email" // Binds your email to all your Git repositories

Pulling from a remote repository#

// The simplest way is to clone directly

git clone https://github.com/withastro/docs.git

// Manually create a repository and bind it to the remote repository

git init 
git remote add origin https://github.com/withastro/docs.git
git pull origin main

Committing changes and pushing to the remote repository#

git add .
git commit -m "Current commit title" // The description of the commit is very important; see the details later
git push -u origin main

Git Standardized Collaborative Development#

Branch Management#

Many students, when first learning Git, will directly develop on the main branch, which can lead to many problems. Generally, the main branch is the production branch, which must remain stable and reliable. Developing and testing on the main branch can lead to bugs that users can perceive as production incidents. In collaborative development, at least everyone should have their own development branch to effectively avoid the risk of code conflicts. The best practice is to create a feature branch based on requirements and merge it into the production branch after development and testing. Below, I will provide an example of developing a branch for the image component.

git checkout -b feat-image-component

// Complete component development

git status // Check modified files in the working directory to avoid changes outside the requirements
git add . // Submit code to the staging area
git commit -m "feat: image component"
git log --oneline // View the commit history of the local repository
git push -u origin feat-image-component

// After confirming the component meets the requirements, merge into the production branch
// Ensure the main branch is consistent with the online repository
git checkout main
git pull

git checkout feat-image-component (current branch: feat-image-component)
git rebase main // Rebase to ensure a clean commit history

// Merge branches
git checkout main
git merge feat-image-component

This is the normal process for developing a feature. Following this process ensures development efficiency and minimizes code conflicts and bugs in production. Some may notice that there is a prefix "feat" in the commit; what does that mean? This leads us to discuss Git conventions.

The Difference Between git merge and git rebase#

https://joyohub.com/2020/04/06/git-rebase/

Commit Message Conventions#

Standardization is very important. Standardizing commit messages can enhance the robustness and maintainability of the code repository. One commonly used standard is the Angular standard proposed by Google. The Angular standard we used above indicates that "feat" represents a new feature. Many open-source projects use the Angular standard, such as Antd...

Here are some commonly used prefixes:

echo ""
	echo "feat        New feature"
	echo "fix         Bug fix"
	echo "docs        Documentation (new or modified)"
	echo "style       Formatting (changes that do not affect code execution)"
	echo "refactor    Refactoring (changes that are neither new features nor bug fixes)"
	echo "perf        Performance optimization"
	echo "test        Add tests"
	echo "chore       Changes to the build process or auxiliary tools"
	echo ""

Tips and Tricks#

git rebase -i
git cherry-pick
git worktree
git stash
git commit --amend

Common Git Commands#

git config --global user.name "Your Name" Binds your name to all your Git repositories
git config --global user.email "Your Email" Binds your email to all your Git repositories
git init Initializes your repository
git add . Submits all files in the working directory to the staging area
git add .// Submits the in the working directory to the staging area
git commit -m "xxx" Submits all files in the staging area to the repository area, leaving the staging area empty
git remote add origin https://github.com/name/name_cangku.git Connects the local repository to the remote repository
git push -u origin master Submits the master branch of the repository area to the remote repository
git push -u origin Submits other branches to the remote repository
git status Checks the current status of the repository
git diff Views the specific changes in the files
git log Displays the commit history from most recent to oldest
git clone + repository address Downloads and clones files
git reset --hard + version number Reverts to a version; the version number is associated with the commit (use --soft to keep changes and undo commit, --hard will lose all changes made in the reset commit)
git reflog Displays command history
git checkout -- Reverts the command, replacing the working directory file with the file from the repository. I think of it as Git's version of ctrl + z.
git rm Deletes files from the repository
git branch Views all current branches
git branch Creates a branch
git checkout Switches to the branch
git merge Merges branches
git branch -d Deletes a branch; it may fail to delete because Git protects unmerged branches
git branch -D + Forcefully deletes, discarding unmerged branches
git log --graph Views the branch merge graph
git log --oneline Views a summary of commits
git merge --no-ff Merges branches while disabling the Fast forward mode, as this mode loses branch history information
git stash When other tasks interrupt, "stores" the current working state, allowing you to continue working later
git stash list Views where your recently "stored" work went
git stash apply Restores without deleting stash content
git stash drop Deletes stash content
git stash pop Restores while also deleting stash content
git remote Views information about remote repositories, showing origin; the default name for remote repositories is origin
git remote -v Displays more detailed information
git pull Fetches the latest commits from the remote repository and merges them locally, the opposite of git push
git rebase "organizes" diverging commit history into a straight line, making it look more intuitive (rebase is usually used during development instead of directly using merge)
git tag Views all tags, allowing you to know the historical version tags
git tag Tags the current HEAD. For example, git tag v1.0
git tag Tags the version number, which is the string of letters and numbers next to the commit
git show Views tag information
git tag -a -m "" Creates a tagged version with a description. -a specifies the tag name, -m specifies the description text
git tag -d Deletes a tag
git push origin Pushes a specific tag to the remote
git push origin --tags Pushes all local tags that have not yet been pushed to the remote at once
git push origin /tags/ Deletes the remote tag
git config --global color.ui true Enables color display in Git, making command output look more prominent
git add -f Forcefully submits ignored files
git check-ignore -v Checks why Git is ignoring the file
git cherry-pick
git worktree Creates a new working directory, allowing for simultaneous development of multiple branches in the local repository.