Pro Git --(Windows)总结

Pro Git --Windows

知识来源

        廖雪峰的官方网站 Git教程

Git入门与进阶

# 初步学习Git #
  个人建议先大致过一遍，对Git有个大致的理解，然后在实操项目

# 创建一个空目录
$ mkdir learngit
$ cd learngit
$ pwd

# 通过git init命令把这个目录变成Git可以管理的仓库
$ git init

# 把文件添加到仓库(暂存区)
$ git add readme.txt

# 用命令git commit告诉Git，把文件提交到仓库
$ git commit -m "wrote a readme file"

# git status命令可以让我们时刻掌握仓库当前的状态
$ git status

# git diff 查看文件readme.txt具体修改了什么内容
$ git diff readme.txt 

# 提交修改和提交新文件是一样的两步
$ git add readme.txt
$ git commit -m "add distributed"

# git log命令查看历史记录
$ git log

# 如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数
$ git log --pretty=oneline

# 把当前版本回退到上一个版本
$ git reset --hard HEAD^

# 也可以指定回到未来的某个版本(1094a)版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了
$ git reset --hard 1094a

# 查看文件内容 
$ cat readme.txt

# 修改文件内容
$ vi readme.txt

# Git提供了一个命令git reflog用来记录你的每一次命令(帮助你回滚未来)
$ git reflog



# 理解工作区、暂存区、版本库 #
# 工作区
  就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区
# 版本库（Repository）
  工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库
# 暂存区
  Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区
  还有Git为我们自动创建的第一个分支master
  以及指向master的一个指针叫HEAD

# 前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的
  第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区
  第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支
  因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改
  你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改



# 现在，假定你已经完全掌握了暂存区的概念。下面，我们要讨论的就是，为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件 #
  具体查看 https://liaoxuefeng.com/books/git/time-travel/add/index.html
  总结下来就是 git add 将修改内容放在暂存区，git commit将暂存区的所有内容提交到版本库



# 撤销修改 
  命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销
  这里有两种情况
  一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态
  一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态
  总之，就是让这个文件回到最近一次git commit或git add时的状态
  注意： git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令

# Git同样告诉我们，用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区
   $ git reset HEAD readme.txt
   git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本

# 删除文件
$ rm readme.txt



# GitHub远程仓库 #
# 由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：
# 第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key
$ ssh-keygen -t rsa -C "1xxxxxxxxx@qq.com"(注意：这边换成你们个人的邮箱)
# 第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面, 然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容
# 2019年之后私有仓库免费

# 关联远程仓库
  要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git
  关联一个远程库时必须给远程库指定一个名字，origin是默认习惯命名
  关联后，使用命令git push -u origin master第一次推送master分支的所有内容
  此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改

# SSH警告
  具体查看 https://liaoxuefeng.com/books/git/remote/add-remote/index.html

# 删除远程库
  如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息
  $ git remote -v
  然后，根据名字删除，比如删除origin
  $ git remote rm origin



# 克隆远程库 #
# 以上是先有本地库，后有远程库的时候，如何关联远程库
# 现在，假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆
# 现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：
$ git clone git@github.com:xxx-xxx/xxx-Software.git(这是我跟人的私有仓库，在此可以替换成你们自己的)

# 查看当前文件夹中的文件
$ ls



# 分支管理 #
# 创建dev分支，然后切换到dev分支
$ git checkout -b dev
# git checkout命令加上-b参数表示创建并切换，相当于以下两条命令
$ git branch dev
$ git checkout dev

# 然后，用git branch命令查看当前分支(git branch命令会列出所有分支，当前分支前面会标一个*号)
$ git branch

# 切换回master分支
$ git checkout master

# 我们把dev分支的工作成果合并到master分支上
$ git merge dev

# 删除dev分支
$ git branch -d dev

# 我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑
# 实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支
# 创建并切换到新的dev分支，可以使用
$ git switch -c dev
# 切换到已有的master分支
$ git switch master



# 解决合并冲突 #
# 如果你在分支中修改并提交了某个文件，然后你切换到master分支，在主分支上你又修改了某个文件，这种情况下，Git无法执行“快速合并”， 只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

# 果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件
$ git status

# 我们可以直接查看readme.txt的内容
$ vi readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

# Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
Creating a new branch is quick and simple

# 再提交：
$ git add readme.txt 
$ git commit -m "conflict fixed"

# 用带参数的git log也可以看到分支的合并情况
$ git log --graph --pretty=oneline --abbrev-commit
# 最后，删除feature1分支
$ git branch -d feature1



# 分支管理策略 #
# 通常，合并分支时，如果可能，Git会用Fast forward模式(上述$ git merge feature1)，但这种模式下，删除分支后，会丢掉分支信息
# 如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息

# 首先，仍然创建并切换dev分支
$ git switch -c dev

# 修改readme.txt文件，并提交一个新的commit
$ git add readme.txt 
$ git commit -m "add merge"

# 现在，我们切换回master
$ git switch master

# 准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward
$ git merge --no-ff -m "merge with no-ff" dev
# 因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去

# 合并后，我们用git log看看分支历史
$ git log --graph --pretty=oneline --abbrev-commit

# 分支策略
# 在实际开发中，我们应该按照几个基本原则进行分支管理
# 首先 master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
# 那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本
# 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了(不同小伙伴的dev分支合并)



# bug分支 # 
# 软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除
# 当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它
# 但是，等等，当前正在dev上进行的工作还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
# 幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作
$ git stash
# 现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug

# 首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支
$ git checkout master
$ git checkout -b issue-101

# 现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交
$ git add readme.txt 
$ git commit -m "fix bug 101"

# 修复完成后，切换到master分支，并完成合并，最后删除issue-101分支
$ git switch master
$ git merge --no-ff -m "merged bug fix 101" issue-101

# 太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了
$ git switch dev
$ git status
# 工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看
# 工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法
# 一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除
# 另一种方式是用git stash pop，恢复的同时把stash内容也删了
# 再用git stash list查看，就看不到任何stash内容了
# 你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令
$ git stash apply stash@{0}

# 在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在
# 那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了
# 有木有更简单的方法？
# 同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
# 为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支
$ git cherry-pick 4c805e2
# Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍



# Feature 分支 #
# 软件开发中，总有无穷无尽的新的功能要不断添加进来
# 添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了
# 所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支
# 现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船
$ git switch -c feature-vulcan

# 5分钟后，开发完毕
$ git add vulcan.py
$ git commit -m "add feature vulcan"

# 切回dev，准备合并
$ git switch dev

# 一切顺利的话，feature分支和bug分支是类似的，合并，然后删除

# 但是！
# 就在此时，接到上级命令，因经费不足，新功能必须取消！
# 虽然白干了，但是这个包含机密资料的分支还是必须就地销毁
$ git branch -d feature-vulcan

# 销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。
# 现在我们强行删除(如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除)
$ git branch -D feature-vulcan



# 多人协作 # 
# 当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin
# 要查看远程库的信息，用git remote
$ git remote
# 或者，用git remote -v显示更详细的信息
$ git remote -v

# 上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址
# 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上
$ git push origin master
# 如果要推送其他分支，比如dev，就改成
$ git push origin dev

# 但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢
# master分支是主分支，因此要时刻与远程同步
# dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步
# bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug
# feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发
# 总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定

# 多人协作时，大家都会往master和dev分支上推送各自的修改
# 现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆
$ git clone git@github.com:gcp-hql/Debug-Software.git
# 当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看
# 现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支
$ git checkout -b dev origin/dev

# 现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程
$ git add env.txt
$ git commit -m "add env"
$ git push origin dev

# 你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送
$ cat env.txt
$ git add env.txt
$ git commit -m "add new env"
$ git push origin dev

# 推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送
$ git pull
# git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
$ git branch --set-upstream-to=origin/dev dev

# 再pull
$ git pull
# 这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push
$ git commit -m "fix env conflict"
$ git push origin dev

# 因此，多人协作的工作模式通常是这样：
  首先，可以尝试用git push origin <branch-name>推送自己的修改；
  如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  如果合并有冲突，则解决冲突，并在本地提交；
  没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！



# 变基 # 
# 上面我们可以看到，多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功，每次合并再push后，分支变的很乱
$ git log --graph --pretty=oneline --abbrev-commit
# 如何解决呢
# Git有一种称为rebase的操作，有人把它翻译成“变基”
# 在和远程分支同步后，我们对hello.py这个文件做了两次提交。用git log命令看看
$ git log --graph --pretty=oneline --abbrev-commit
# 注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello，本地分支比远程分支快两个提交。
# 现在我们尝试推送本地分支
$ git push origin master

# 很不幸，失败了，这说明有人先于我们推送了远程分支。按照经验，先pull一下
$ git pull
$ 添加 + 提交

# 再用git status看看状态：
$ git status

# 加上刚才合并的提交，现在我们本地分支比远程分支超前3个提交
# 用git log看看
$ git log --graph --pretty=oneline --abbrev-commit

# 对强迫症童鞋来说，现在事情有点不对头，提交历史分叉了。如果现在把本地分支push到远程，有没有问题
# 有！
# 什么问题？
# 不好看！
# 有没有解决方法？
# 有！
# 这个时候，rebase就派上了用场。我们输入命令git rebase试试：
$ git rebase

# 输出了一大堆操作，到底是啥效果？再用git log看看
$ git log --graph --pretty=oneline --abbrev-commit

# 原本分叉的提交现在变成一条直线了！这种神奇的操作是怎么实现的？其实原理非常简单
# 我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到了f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的
# 但是，我们本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的
# 这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了
# 最后，通过push操作把本地分支推送到远程
$ git push origin master



# 标签管理理解 #
# 发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
# Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。
# Git有commit，为什么还要引入tag？
# “请把上周一的那个版本打包发布，commit号是6a5819e...”
# “一串乱七八糟的数字不好找！”
# 如果换一个办法：
# “请把上周一的那个版本打包发布，版本号是v1.2”
# “好的，按照tag v1.2查找commit就行！”
# 所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起



# 创建标签 #
# 在Git中打标签非常简单，首先，切换到需要打标签的分支上：
$ git branch
$ git checkout master

# 然后，敲命令git tag <name>就可以打一个新标签：
$ git tag v1.0

# 可以用命令git tag查看所有标签
$ git tag

# 默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
# 方法是找到历史提交的commit id，然后打上就可以了
$ git log --pretty=oneline --abbrev-commit

# 比方说要对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令：
$ git tag v0.9 f52c633

# 注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：
$ git show v0.9
# 可以看到，v0.9确实打在add merge这次提交上

# 还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字
$ git tag -a v0.1 -m "version 0.1 released" 1094adb
# 用命令git show <tagname>可以看到说明文字
$ git show v0.1



# 删除标签 #
# 操作标签
# 如果标签打错了，也可以删除
$ git tag -d v0.1

# 因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除
# 如果要推送某个标签到远程，使用命令git push origin <tagname>
$ git push origin v1.0

# 或者，一次性推送全部尚未推送到远程的本地标签
$ git push origin --tags

# 如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
$ git tag -d v0.9

# 然后，从远程删除。删除命令也是push，但是格式如下：
$ git push origin :refs/tags/v0.9
# 要看看是否真的从远程库删除了标签，可以登陆GitHub查看。



# 使用Gitee #
具体查看 https://liaoxuefeng.com/books/git/gitee/index.html
# 一个本地库既可以关联Github，又可以同时关联Gitee
# 我们先删除已关联的名为origin的远程库
$ git remote rm origin

# 然后，先关联GitHub的远程库
$ git remote add github git@github.com:xxxx/xxxx.git
# 注意，远程库的名称叫github，不叫origin了

# 接着，再关联Gitee的远程库
$ git remote add gitee git@gitee.com:xxxx/xxxx.git

# 现在，我们用git remote -v查看远程库信息，可以看到两个远程库
# 如果要推送到GitHub，使用命令
$ git push github master



# 自定义Git # 
# 让Git显示颜色，会让命令输出看起来更醒目
$ git config --global color.ui true

# 忽略文件
# 有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽
# 好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
# 不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：GitHub/gitignore

# 忽略文件的原则是：
  忽略操作系统自动生成的文件，比如缩略图等
  忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件
  忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件

# 有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了
# 如果你确实想添加该文件，可以用-f强制添加到Git
$ git add -f App.class

# 或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查
$ git check-ignore -v App.class

# Git会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则
# 其他
具体查看 https://liaoxuefeng.com/books/git/gitee/index.html

# 配置别名
# 有没有经常敲错命令？比如git status？status这个单词真心不好记
# 如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的
# 我们只需要敲一行命令，告诉Git，以后st就表示status
$ git config --global alias.st status

# 当然还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch

# 以后提交就可以简写成
$ git ci -m "bala bala bala..."
# --global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用

# 在撤销修改一节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名
$ git config --global alias.unstage 'reset HEAD'

# 当你敲入命令：
$ git unstage test.py

# 实际上Git执行的是：
$ git reset HEAD test.py

# 配置一个git last，让其显示最后一次提交信息：
$ git config --global alias.last 'log -1'

# 这样，用git last就能显示最近一次的提交
$ git last

# 甚至还有人丧心病狂地把lg配置成了
$ git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

# 配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用
# 配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中
# 别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。

# 而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
# 配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置，或者直接删掉配置文件错误的那一行。



# 扩展 # (实战项目可能会用到)
# 这个命令的作用是从 Git 的索引（暂存区）中递归地移除 FL_IADS/dll/ 目录及其所有内容，但不会删除本地文件系统中的实际文件。这样做的目的是为了让 Git 忽略这些文件夹及其内容，从而避免它们被提交到代码仓库中
$ git rm -r --cached FL_IADS/dll/

# 然后提交修改
$ git commit -m "移除已跟踪的文件并更新 .gitignore"

# 查询某个目录是否被Git跟踪
git ls-files FL_IADS/dll/

# 要仅保留最新的提交记录并删除之前的历史提交记录
# 用于创建一个新的孤立分支，并切换到该分支
$ git checkout --orphan latest_branch

# 将所有文件添加到新的分支
$ git add -A

# 提交这些文件
$ git commit -m "Initial commit with latest changes"

# 删除旧的 master 分支（或你想要替换的分支）
$ git branch -D master

# 将新的分支重命名为 master
$ git branch -m master



# 有以上Git技能后，就可以开始在Visual Studio上实操项目了，即可以通过本地指令管理版本库，也可以使用VS提供的UI管理，二者可以协同操作 #
# Visual Studio 2022 使用git进行代码版本管理可以参考改博客 https://blog.csdn.net/weixin_39237340/article/details/132776717