Article directory
overview
"The history and current status of Git"
Git is another masterpiece of Linus Torvalds, the founder of Linux. In 2002, he used Bitkeeper in version control of the Linux kernel, but because Bitkeeper is a copyright-protected software, it was questioned. Later, Andrew Tridgell reverse-engineered Bitkeeper, causing BitMover to revoke Linux developers' free rights to use Bitkeeper. Linus was very angry about this, so he spent 10 days writing Git.
The meaning of the name Git is: "egotistical bastard" (narcissistic bastard).
Today, Git has become the first choice for most developers. GitHub, launched in October 2007 by Tom Preston-Werner, Chris Wanstrath and PJ Hyett, has grown into the world's largest developer website, with many teams making important contributions.
It is worth mentioning that even Microsoft, which has always been inventing its own wheels, plans to migrate the huge 300GB Windows source code to Git for management. In order to deal with the performance issues of huge code warehouses, they provide a new GVFS implementation for Git.
In addition, it is worth mentioning that Docker’s binary image management is also based on Git.
Centralized version management and distributed version management
There are fundamental differences in design concepts between Git and SVN. SVN adopts centralized management and has better stability and security. In contrast, Git is a decentralized version control tool originally created to meet the needs of Linux operating system development. It is more suitable for open source projects with multi-person collaboration, allowing remote code to be merged with local code at any point. Over time, Git has evolved into more powerful functions and complete operating procedures, making it also suitable for commercial software development.
Git basic commands
Basic Git commands can be divided into the following scenarios according to different scenarios:
Workspace（工作区）：当前工作区，即修改的初始状态。
Staging（暂存区）：修改后，添加到准备提交的缓存状态。
Local repository（本地代码库）：本地的代码仓库，只对自己的代码生效。与SVN的一个区别在于，SVN commit之后直接提交到远程服务器，而Git commit之后只是到本地代码库。
Remote repository（远程代码库）：远程代码库，用于同步本地代码库到远程，以供其他开发者分享。
The following is a brief introduction to several commonly used commands:
PS: The rebase and cherry-pick commands are not mentioned in the picture. These two commands are also very powerful and will be mentioned later. Please pay attention to them.
Patch diff:
As mentioned before, patch is the basic concept of Git/SVN code version management. It is actually the file modification history in line units. Added lines start with a + sign, and deleted lines start with a - sign. To modify a row, delete it first and then add it.
In Git, you can use the git diff command, or use diff -Naur in Linux/Mac/Conemu to generate file comparison results, similar to the figure below. This forms the basic concept of the entire code management, and all branches, tags, and remotes are derived from this basis.
Basic process
1. Clone the code to the local development environment - Clone
$ git clone [REPOSITORY_URL]
Similar to SVN's checkout command, used to clone remote code to local. Like SVN, REPOSITORY_URL's protocol is very flexible. The SSH/SCP protocol was commonly used before, but now the HTTPS/HTTP protocol is also becoming more popular.
2. Update code - Status/Commit/Log
Use the git status command to view the first two statuses in the four scenarios. The newly created code will be displayed as Untracked files (Workspace) status. After executing add, the code changes to Changes to be committed (Stage) state. After the files in the Stage are modified, the status changes to Changes not staged for commit. After executing commit, the code is transferred from Stage to Local repository. Use git log to view code submission history.
3.Branch and Tag
Both Branch and Tag can be regarded as sequential collections of patches, and Branches can be merged with each other. After cloning the repository, there is a mainline branch called master by default. Tag is used to mark versions after publishing. Unlike SVN, SVN's Branch and Tag copy the entire Trunk code base, while Git just re-applies the patch reference to the current code. Therefore, Git's Branch/Tag is very lightweight and very convenient to switch. When using Git, it is recommended to make full use of branches to improve development efficiency. When Git flow is introduced later, we will explain how to use branches for code feature development management.
development management
3.1 Two ways to create a new branch
$ git checkout -b [BRANCH_NAME] # 在当前版本切换并新建分支
$ git branch [BRANCH_NAME] # 直接新建分支
3.2 Switch branches
$ git checkout [BRANCH_NAME]
3.3 Two ways to merge branches
$ git merge [BRANCH_NAME] # 将另外一个分支的代码，合并到当前分支之后。
$ git rebase [BRANCH_NAME] # 不推荐，对代码进行比较，将本分支修改后的代码合并到另外一个分支之后
Rebase is not recommended under normal circumstances, because after rebase completes the downstream branch, and then merges from the upstream branch, the commits of the branch merge will be lost. It is not recommended to rebase commits that have been pushed to the remote repository, as this will cause a large number of conflicts when others pull.
3.4 Delete branch
$ git branch -d [BRANCH_NAME] # 已经合并到 master
$ git branch -D [BRANCH_NAME] # 该分支未合并到 master，强制删除
Even if you delete a branch, etc., you can use git reflogs to get it back.
3.5 Cancel modifications
git stash # 取消全部修改，它可以恢复过来
git reset --soft [REV] # 保留修改内容，从 Local repository 撤销，也可用于回退历史记录
git reset --hard [REV] # 丢掉修改内容，从 Local repository 撤销，也可用于回退历史记录
Push local code to remote repository
$ git push [REMOTE] [BRANCH]
REMOTE defaults to origin. If left blank, it will be pushed to origin. BRANCH defaults to the current branch and can be omitted. To push local feature branches, it is recommended to use the --set-upstream parameter.
A serious warning: never do --force on the mainline master branch.
Get remote branch updates
$ git pull # 更新到 workspace
$ git fetch # 更新到 Local repository，可能需要通过 merge 合并到 workspace 一次
Remote warehouse
There will be a default remote warehouse origin after Clone. If you need to add other remote warehouses, you can use the following command:
$ git remote add [REMOTE_NAME] [URL] # 添加远程仓库
$ git fetch [REMOTE_NAME] # 获取远程仓库更新
$ git branch -a # 查看所有分支，包括远程仓库内的
$ git push [REMOTE_NAME] [BRANCH_NAME] # 推送到远程仓库
GitHub has introduced a mechanism based on Git Remote to make it more convenient to participate in open source projects. The general open source project participation process is to first register a GitHub account, and then Fork the open source project you are interested in into your own namespace. Next, split the branch, make changes, and commit to your own GitHub repository. Then, initiate a Pull Request (PR) and request the project maintainer to merge your code. During this process, the project maintainer will review and comment on your code, and you need to make modifications according to the maintainer's requirements (here, rebase is often used to keep the code clean). Once the changes are approved and agreed by the maintainer, the maintainer merges the code into the project.
Once you try the specific process, you will understand that the principle of GitLab's Merge Request is consistent with this.
Git Flow
Git Flow implements a simple functional modular development process based on Git branches. The main idea is to divide branches into upstream and downstream levels, and then maintain them through a set of command line tools.
master分支： 与线上版本保持一致，当出现线上问题时可以轻松修复。
develop分支： 功能开发的基线分支，功能开发完成后合并到此分支。所有功能开发完成后经过测试上线，然后合并回master。
*feature/功能开发分支： 从develop分支拆分，需要定期将develop的更新合并过来，保持与上游分支的一致性。功能开发完成后，可合并到develop。通过与上游分支保持一致，可以避免误删他人代码。所有代码冲突必须在下游分支解决，测试完毕后才可合并到上游分支。
*hotfix/热修复分支： 主要用于在线上修复bug，修复后应同时合并到master和develop两个分支。
Then, git flow provides a set of command line tools to make these code merge operations easier.
$ git flow init # 初始化git flow分支模型
$ git flow feature start [NAME] # 开始一个功能分支
$ git flow feature finish [NAME] # 将功能分支合并到develop
$ git flow hotfix start [NAME] # 开始一个热修复分支
$ git flow hotfix finish [NAME] # 将补丁合并到develop和master
$ git flow release [NAME] # 发布一个新版本，打标签