Git Learning Notes

Dec 22 2022 Learning>Computer Science 13 minutes read (About 1981 words)

I finally went through the tutorial. I learned Git because I wanted to be proficient with GitHub, but now I realize that Git is the core of the deepest mystery 😂

Introduction

Git is developed in C
Centralized & Distributed Version Control Systems
- Centralized: the repository is stored on a central server; the biggest problem is that you have to be connected to the Internet to make it work.
- Distributed: no “central server”, everyone has a complete repository on their computer, no network required; much more secure; usually there is a computer that acts as a “central server”, but this server is only used to facilitate “swapping” everyone’s changes; extremely powerful branch management

Creating a repository

A repository can be simply understood as a directory in which all files can be managed by Git, and each file’s modifications and deletions can be tracked by Git so that the history can be tracked at any moment, or “restored” at some point in the future.
Creating a repository
- step1: Create an empty directory
- step2: Initialize, git init.
Put a file into the Git repository
- git add
- git commit

Time machine shuttle

git status to see the status of the workspace
git diff to see what was changed

Version fallback

git reset --hard commit_id version fallback
- git reset --hard HEAD^
  - In Git, you use HEAD for the current version, the last version is HEAD^, the previous version is HEAD^^, and up to 100 is written as HEAD~100
- git reset --hard 1094a
  - It’s not necessary to write the full version number (commit id), the first few bits will do, Git will automatically find it
git log to see the commit history
- show the commit log from most recent to furthest back (if that’s too much, add the -pretty=oneline argument)
git reflog to see the command history
- You can find the version number

Working Directory & Stage

Working Directory: The directory you can see on your computer
Repository: There is a hidden directory .git in the workspace, which is not considered a working directory, but a Git repository.
The important things in the repository are
- Staging area: stage (or index)
- branches: the first branch master that Git automatically creates for us
- Pointer: a pointer to master called HEAD.
All the changes to the file that need to be committed are put into the staging area, and then all the changes in the staging area are committed at once

Managing Changes

Git tracks and manages changes, not files.
Every time you make a change, if you don’t add it to the staging area with git add, it doesn’t get added to the commit.
add only adds to the staging area, commit goes to the repository, and all the same files in the staging area are overwritten.

Unding changes

git restore -- file discards the changes and puts the file back in the state it was in when you last git commit or git add.
- -- is important, without --, it becomes a “switch to another branch” command
git restore --staged undoes the changes in the staging area and puts them back in the workspace
Note.
- The original git checkout can be replaced with git restore
- The original git reset HEAD can be replaced with git restore –staged
- The latest version of the git prompt has been replaced with restore
To summarize.
- Case 1: You made changes in the workspace and didn’t add them to the staging area, so you want to undo the changes in the workspace with git restore file
- Case 2: You made changes in the workspace and added them to the staging area with git add, but did not commit them; if you want to undo them, there are two steps: 1.
- Case 3: After making changes in the workspace, and git add git commit adds and commits the content, you want to undo this commit, directly use git reset –hard HEAD^ to roll back the version, which will ensure that the workspace, staging area, and repository are all the same as the last one

Deleting files

git rm
- If a file has been committed to the repository, then you never have to worry about deleting it by mistake, but be careful, you can only restore the file to the latest version and you will lose what you have changed since the most recent commit
When you delete a useless file directly in the file manager, or with the rm command, you have two options next.
- Do delete the file from the repository, then use the command git rm to delete it, and git commit
- If you deleted the wrong file, use git checkout to restore the wrongly deleted file from the repository to the latest version

Remote repositories

The transfer between the local Git repository and the GitHub repository is encrypted via SSH

Adding a remote repository

git remote add origin git@server-name:path/repo-name.git
- When associating a remote repository, you must assign a name to the remote repository, origin is the default convention
After the association, use the command git push -u origin master to push all the content of the master branch for the first time
After that, you can use the command git push origin master to push the latest changes whenever necessary after each local commit

Deleting the remote repository

git remote rm <name>
- Before using it, it is recommended to check the remote repository information with git remote -v
- It just unbinds the local and remote, it does not physically remove the remote repository. There are no changes to the remote repository itself. To actually delete the remote repository, you need to log in to GitHub and find the delete button on the backend page before deleting it

Cloning from a remote repository

ssh: git clone git@github.com:your name/repo name.git
- Faster
https: git clone http://github.com/yourname/reponame.git

Branch management

Creating and merging branches

git checkout -b or git switch -c creates and switches
- Equivalent to git branch (create) + git checkout or git switch (switch)
git branch to see the current branch
- will list all branches, with a * in front of the current branch
git merge merges the specified branch into the current branch
git branch -d delete branches
Creating, merging, and deleting branches is very fast, so it’s best to use a branch to complete a task, merge it, and then delete the branch, which is the same as working directly on the master branch, but a much safer process

Resolving conflicts

Manually edit the file that failed the Git merge to what we want it to be, and then commit it

Branch Management Strategy

Branching strategy
- The master branch should be very stable, i.e. only used for new releases, no work should be done on it.
- The dev branch is unstable, work is done on the dev branch; at some point, for example, when version 1.0 is released, the dev branch is merged into the master branch and version 1.0 is released on the master branch
- All team members work on the dev branch, and everyone has their own branch, so just merge it to the dev branch from time to time
Normal mode when merging branches: add -no-ff parameter
- This way the merged history has branches and you can see that a merge was done, while a fast forward merge will not show that a merge was done

Bug branch

When you fix a bug, you create a new bug branch to fix it, then merge it, and finally delete it
git stash saves the worksite, then goes to fix the bug, and after fixing it, there are two ways to get back to the worksite.
- git stash apply, the stash content is not deleted, you need to use git stash drop to delete it
- git stash pop, which removes the stash content while restoring it
git stash list to see what’s in the stash, then use git stash apply stash@{0} to restore to the specified stash (in this case, stash@{0})
For bugs fixed on the master branch that you want to merge into the current dev branch, you can use git cherry-pick <commit> to “copy” the changes from the bug commit to the current branch to avoid duplication of effort

Feature branch

To develop a new feature, it is best to create a new branch
If you want to discard a branch that has not been merged, you can force it to be deleted with git branch -D <name>

Multi-author collaboration

git push origin <branch-name> to push your own changes
If the push fails, the remote branch is newer than your local branch and you need to try to merge it with git pull first
- If git pull prompts no tracking information, then you need to use git branch --set-upstream-to <branch-name> origin/<branch-name> to establish a link between the local and remote branches
If there is a conflict in the merge, resolve the conflict and commit locally
If there is no conflict, or if the conflict is resolved, push with git push origin <branch-name>

Rebasing

Organize the history of unpushed forked commits locally into straight lines
Purpose: To make it easier to see how commit history has changed, since forked commits require a three-way comparison

Tag management

A tag is a meaningful name that is easy to remember and is tied to a commit
If the commit appears in both the master branch and the dev branch, then the tag can be seen on both branches

Creating the tag

git tag <tagname> creates a new tag
- The default is HEAD, but you can also specify a commit id
- Tags created are only stored locally and are not automatically pushed to the remote
git tag -a <tagname> -m "blablabla..." Create tags with descriptions
git tag to see all tags
- Instead of listing them chronologically, alphabetize them
git show <tagname> to see tag information

Manipulating tags

Push
- git push origin <tagname> push a local tag to the remote
- git push origin --tags push all unpushed local tags to the remote at once
Delete
- git tag -d <tagname> Delete a local tag
- Delete a remote tag: first from local (with the above command), then from remote with git push origin :refs/tags/<tagname>

Using GitHub

You can fork any open source repository
You have read and write access to the repository after fork
Push a pull request to the official repository to contribute code

Using Gitee

Domestic Git hosting service
Similar to GitHub

Customizing Git

git config --global color.ui **true** Make Git display colors to look more eye-catching

Ignoring special files

Github official .gitignore file collection
Principles of ignoring files.
- Ignore files automatically generated by the operating system
- Ignore compile-generated intermediate files, executables, etc.
- Ignore configuration files with personally sensitive information
git add -f filename is ignored but forced to be added
!filename exception file
.gitignore online generator

Configuring aliases

-git config --global **alias**.st status sets st to represent status
- -global is a global parameter for the current user, i.e. it makes the command useful for all Git repositories on this computer; if you don’t add it, then it’s only useful for the current repository
- Git configuration files for each repository are placed in the .git/config file
- The current user’s Git configuration file is placed in a hidden file .gitconfig in the user’s home directory
- To remove an alias, just delete the line after [alias] that corresponds to the alias

Setting up a Git server

You need a machine running Linux (Ubuntu or Debian is recommended). See here

Using Sourcetree

Free Git GUI tool

Appendix

Tutorial

Liao Xuefeng’s Git course

Links

Git Cheat Sheet
Git Official Website

#Git