git 学习

1.快速看到一大堆文件中哪里有改动

2.快速看这个bug代码是谁写的

3.除了.git其他文件都叫工作目录

4.未跟踪就是创建的文件还和git没有关系

5.一次提交被认为是一个版本

add .代表当前目录所有文件加入仓库，简单省事i，在暂存区，文件变绿

在这里进入工仓库了，干净了，git status是查询状态的指令

如果修改仓库的文件，则这个文件会再次进入到工作区(就是图上所说的工作区)

看到这个文件有两次提交

6.版本回退后，该次提交记录删除，文件的修改也删除

7.版本回退之后，可以通过reflog分析找到回退的id号，找回不想回退的版本

在文件夹下本地提交的文件不会丢的，只要不把文件夹都删了（git的各种日志，操作都会记录在该本地文件夹下的.git）

8.为了方便使用add .需要把不想要管理的文件写入gitignore文件

9.分支：每个人一个分支，一个人一根线，相互不影响

10.多个人要合代码了，就算合并分支

11.为了防止错乱，工作区（当前目录下）只能同时为一个分支服务，该分支叫当前分支

注意看！！！

HEAD指向当前的分支

从图中我们看到:

master分支提交了file01,提交了gitignore，两次操作

master的工作区：

现在切换分支

就没有master分支创建的文件了

12.一般都是其他分支往主分支合并

13.在合并后，主分支就有全部文件了就是一个新的版本了，其他分支要是不需要就可以删除了

13.github和码云是把代码托管在别人的服务器(开源)

公司一般用gitlib，是把代码托管在自己的服务器

14.github只支持git提交(要翻墙)

15.码云是国内的

16.创建好远程仓库后，不能谁可以推送到远程仓库，所以需要验证，用SSH密钥验证

17.注意！！克隆会把工程所有信息都拷贝到本地，克隆会拷贝所有文件(拷贝到一个新的文件夹下)，一般只进行一次，如果项目有更新，推送和拉取就可以了

18.origin/master是远程分支，也是分支，也需要合并

19.git 的快模式"，Git 的 "fast-forward 模式"。快进（fast-forward）是指合并两个分支时，Git 发现要合并的分支的最新提交是当前分支的直接上游时，它会采用快进模式，直接将当前分支指针移动到最新提交，而不生成一个新的合并提交。这样的合并是线性的，没有新的合并提交产生。

在合并过程中，如果没有其他人在你的当前分支上进行了提交，Git 就可以执行快进合并。快进模式在保持提交历史的简洁性和清晰性方面很有用。

20.注意！！！(HEAD -> master, origin/master) 中的信息表示当前 HEAD 指向本地的 master 分支，并且 origin/master 指向远程仓库的 master 分支。

如果你看到这个信息，表示你当前的本地 master 分支和远程仓库的 master 分支是一致的，并且没有发生合并冲突。这通常是通过快进（fast-forward）模式进行的合并，也就是说，远程仓库的 master 分支是你当前分支的直接上游，Git 可以直接移动本地 master 指针到最新的提交，而不需要创建新的合并提交。

21.什么是直接上游？？

如果你在 master 分支上创建了一个新的分支 feature-branch，那么在这个场景中，master 是 feature-branch 的直接上游。你可以使用如下命令查看分支的上游：git branch -vv

* master        56a87e1 [origin/master] Add changes in feature-branch

  feature-branch 56a87e1 [master] Add changes in feature-branch

在这个例子中，master 是 feature-branch 的直接上游，因为 feature-branch 是从 master 分出来的。

22.查看远程仓库ip地址

$ git remote -v

origin   git@gitee.com:qhq2053639299-1/test2.git (fetch)

origin   git@gitee.com:qhq2053639299-1/test2.git (push)

23.git  fetch和git pull的区别：

执行git  fetch从在线仓库抓取到所有提交后，如果和当前的本地的提交有更新，则会有一个远程分支等待被merge合并，如果使用pull拉取，则远程分支自动和本地分支合并(相当于fetch+merge)

24.产生冲突的情况：(看手册)

本地一个master分支对txt1文件修改了第一行

然后我fecth远程仓库，产生一个远程分支，这个远程仓库里的txt1的第一行被某人改过了

现在准备合并，就产生了冲突，到底合并出来的txt1的第一行内容听哪个分支的？

merge后会报错，txt1文件内容会有标记，你来选择保留哪个，然后继续提交即可

25. 切换分支前先提交本地的修改！！！！

26.暂存的意义：我先在工作区修改文件，然后存到暂存区，继续在工作区修改文件，我可以看暂存区中，和暂存之前的区别，也可以看工作区中的继续更改和暂存区中的区别，相当于暂存区就是一次暂时保存的提交，将继续修改的提交暂存区，暂存区的该文件会覆盖成新的修改过的内容，暂存区可以撤回，放弃暂存区的内容

27.存储功能专属于各自分支

28.暂存非常非常常用，暂存保存的相当于是更改的记录，是当前工作区的内容，可以恢复在add暂存之前 一次的内容

29.暂存相当于我把编译过的版本先暂存，然后继续修改，如果报错，那就不要添加到暂存，直到修改不报错合适了，再添加到暂存，暂存中的大概率是可以提交的，如果发现问题，可以从暂存中拿回工作区

30.如果你的分支已经推送到远程仓库，并且其他人已经获取了这些提交，强烈建议使用 git revert，以避免分支历史的混乱。

如果你仅在本地工作，并且确定你不需要之前的提交历史，可以使用 git reset。在这种情况下，确保你了解该命令的影响，因为它会删除指定提交之后的所有提交。

请根据具体情况选择适当的方法，并在执行这些操作之前备份你的工作。

31.git revert -n (版本号) 回退版本

32.暂存区对比的时候不可以修改内容，工作区的修改可以修改内容

33.soft reset：

将分支引用移动到指定的提交，但不修改工作目录和暂存区。

可以用于撤销之前的一些提交，保留这些更改以供重新提交。

hard reset：

将分支引用移动到指定的提交，同时强制更新工作目录和暂存区，将它们重置为指定提交的状态。

可以用于丢弃之前的一些提交，删除历史记录，使分支回到指定提交的状态。

版本回退（revert）：

revert：

将某个提交克隆，然后创建新的提交，然后提交

34.关于soft reset、hard reset和版本回退revert的区别

soft reset 和 hard reset 可能会修改或删除提交历史，可能对协作团队造成问题，具有强制性，可能会导致工作目录和暂存区的丢失，会修改分支的提交历史，可能需要强制推送，影响协作。

soft reset 和 hard reset 更适用于对整个分支历史进行调整，包括删除提交、整理历史等。

revert 通过创建新的提交来保留原始提交的历史记录，创建新的提交，对工作目录和暂存区的影响相对较小，创建新的提交，通常不需要强制推送，更适合在协作环境中使用。

revert 更适用于在保留历史的情况下，撤销之前提交的更改。

35.git checkout

让你的工作目录回到指定的提交状态，但它不会改变任何分支的位置。在这种状态下，你处于一个“分离HEAD”的状态，可以自由地查看旧版本

36.在平时使用git开发的时候，我们 希望git不要关注某些文件的改动，比如.htm、.o这样的文件，就需要取消对这类文件的跟踪。

在最开始初始化git仓库的时候，所有文件都是未跟踪（U），我们需要创建.gitignore，这个文件里面说明了要git忽略哪些文件，这些文件变化了，git是不去管的，包括提交也只会提交我们跟踪的内容，这个是现在在用的.gitignore文件内容：（注意：git的gitignore文件不支持正则表达式，但是支持这样类似正则表达式的写法）

*.htm

*.o

*.crf

*.uvoptx

*.uvguix.qhq

*.dep

*.axf

*.hex

*.uvprojx

*.d

*.Inp

*.sct

*.iex

*.ini

*.url

*.s

*.readme

*.inc

*.scvd

*.lst

*.Bak

*.lenovo

*.lnp

37.设置.gitignore最主要是看历史提交的变化：(好用)

38.最开始初始化git仓库的时候，所有文件都是未跟踪，一旦提交过某个文件，那么这个文件就被跟踪了，这时候，不想再跟踪这个文件，就执行这个命令：

git rm --cached *.hex    //hex文件全部移除cach缓冲

git commit -m "Remove *.hex from tracking"   //取消hex的跟踪

这里的意思是取消跟踪所有hex文件

39.我们在vscode里设置的是搜索（ctrl + shift + H）忽略哪些文件，而.gitignore文件设置的是git忽略跟踪的文件，一个是vscode搜索用的，一个是git跟踪用的，是两个东西

40.keil工程里面有很多链接和其他烧录用的文件，对于我们开发来说不需要，这个时候就可以 将这些文件设置到.gitignore文件里面，注意，哪些链接等文件，我们再次编译keil的时候，keil就会生成我们本次代码的链接文件，所以说，代码如果是从某个提交上下载下来的，关键h和c文件肯定都是被跟踪也就是会被提交也就是最新的，但是文件夹里面的链接等文件可能不是最新的，因为这些就算改变文件也不会被提交，没关系，我们拿到c和h文件后用keil再编译下，链接和烧录等文件就可以使用了。

41.checkout命令的作用：

临时切换: 如果你只是临时需要查看或使用旧版本的代码，而不打算在其上进行长期的开发，那么在同一个分支上进行 checkout 后不提交变更是合理的。这样，你可以在完成查看或测试后，再切回到最新状态，继续之前的工作。

创建新分支的意图: 如果你在旧版本的基础上打算进行更改，并且想要这些更改作为项目的一部分，最佳实践是创建一个新的分支。这样做的原因是，你不想直接在旧版本上做更改而影响原有的分支结构，尤其是如果这个旧版本已经被共享或用于特定的发布。通过创建新分支，你可以在一个清晰定义的上下文中进行开发，而不干扰主分支或其他分支的进展。

42.为了避免意外丢失在分离HEAD状态下做的更改，推荐的做法是，在进行任何提交之前，先创建一个新分支指向当前的HEAD，这样你的更改就会保存在这个新分支中，而不是处于悬浮状态。

checkout后不提交在同一个分支的原因是：既然checkout了，就是旧版本，不应该作为同一个节点的新版本，需要创建新分支，这样，你既保留了项目的历史状态，也为新的开发工作提供了一个独立的空间。这种方式保持了代码库的整洁和组织性，同时也遵循了版本控制的最佳实践。