文章目录
负责人篇
情况一：本地已有Project
本地已经创建好了项目，想把本地的仓库链接到远程仓库。
操作步骤：
1.远端建库操作（码云为例）
当我们通过idea上传文件时，我们要配置一些忽略文件。忽略文件中有一些自定义配置，我们再配置以下这些
**/mvnw
**/mvnw.cmd
**/.mvn
**/target/
.idea
**/.gitignore
2.本地上传操作
- 打开项目所在文件夹。 git bash here
- 初始化本地仓库。 git init
- 添加远程仓库地址。 git remote add origin 远程仓库地址
- 重要步骤：拉取远端仓库的代码 git pull origin master --allow-unrelated-histories
- 选择上传的文件。 git add . 表示要上传所有项目文件到本地仓库
- 提交到本地。 git commit -m “提交内容的解释” 向本地仓库提交代码
- 将本地库提交到远程仓库（只在此使用一次）。 git push -u origin master
这里的origin表示远程仓库的名称，是git默认起的。 -u的意思是把本仓库的master分支内容推送到远程仓库的master分支，并将二者联系起来，在以后的推送或拉取时就可以简化命令。 git push origin master
3.常见问题汇总
问题一：为什么第四步要拉一下远端仓库代码。
解答：我们创建好远端仓库后，git会为我们生成ReadMe文件，如果我们本地没有这个文件，往远程仓库推送代码是，是会被拒绝的。所在我们在 git add .之前，务必要先拉一下（网上大多数教程没有这一步）
为什么使用git pull origin master --allow-unrelated-histories
使用git pull origin master出现fatal: refusing to merge unrelated histories（拒绝合并不相关的历史） 并且当你push的时候，push到master发现不能push，push到其他分支往master合并时，也是拒绝合并的。
原因：出现这个问题的最主要原因还是在于本地仓库和远程仓库实际上是独立的两个仓库。假如我之前是直接clone的方式在本地建立起远程github仓库的克隆本地仓库就不会有这问题了。
在pull命令后紧接着使用–allow-unrelated-history（该选项可以合并两个独立启动仓库的历史）。
问题二：推送被拒绝的解决措施，对应问题一
解答：三种处理方式。优先方式一，方式二，不推荐方式三。
方式一：变基操作，高级，不推荐
- 本地生成ReadMe文件 git pull --rebase origin master
- 然后再 git push -u origin master
方式二：推荐，但不一定解决
- 删除项目中的.git文件（git init 时生成的那个文件）
- 重新打开git bash here ， 再重头进行一次操作。
方式三：额，怎么说呢，建议不要使用，毕竟是覆盖
- 强制上传覆盖远程文件 git push -f origin master
- (这个命令在团队开发的时候最好不要用,否则…)
git忽略文件无效。
情况二：本地无Project
本地上传操作
Git基本操作指令
- git init 初始化本地仓库（生成.git文件）
- git add 文件名 (选择要准备提交到本地仓库的文件)
- git commit -m “content” 将（git add .）的文件提交到本地仓库
- git status 查看当前仓库的状态（如果我们修改了文件，通过这个指令可以查看哪些修改还没有提交）
- git diff 查看哪些地方进行了修改（git status可以看出哪些做了修改，但是具体修改了哪些内容，可以使用这个指令）
- git log 查看历史提交的版本
- git reflog 查看操作指令历史
- git reset --hard HEAD^ 版本回退（一个^回退一个版本）
- git reset --hard 2ea23 重回版本（2ea23为版本号，可以通过git log 或者 git reflog 进行查看）
- git checkout - - 文件名 可以让你的代码回退到最近的git add. 或 git commit 上
- git reset HEAD tiankong.txt 将已经放入暂存区的修改撤销掉，重新放回工作区
Git status的骚操作
- 不进行任何文件修改
在master分支，没有需要提交的修改
- 文件修改
lightbright.txt文件被修改了，但还没有准备提交修改（爆红）
-
查看修改的内容 git diff
我们可以看到，我们在文件中添加了123456789123456789 -
选择要提交的文件 git add lightbright.txt
再使用gitstatus，我们发现修改的文件名称（爆绿）
-
我们进行提交 git commit -m “content”
此时我们再查看文件状态（变白，没有修改未提交的文件）
小结：
查看工作区的状态：git status
查看修改的内容： git diff
Git版本回退
当我们修改文件到一定程度时，我们可以点一个保存，就算之后写的文件丢失，我们最坏也可以到达本次保存的这一步骤。
我们称这个操作为快照，在git中，通过commit实现。即 一次 git commit -m “content” 就是一个快照。
- git log 查看我们都在仓库中进行了哪些操作
我们可以看到，我们将两个版本的内容进行了提交，一个是添加文件，一个是更新文件。 - git log --pretty=oneline 简化日志
黄色的内容，是git的版本号。
使用图形化界面，我们可以看到操作历史线
- git reset --hard HEAD^ 版本回退
我们当前所在的版本是 update lightbright.txt这个版本，我们回退到add 这个版本（HEAD 所在的版本为当前的版本）
一个^回退一个版本，可以两个甚至更多个
回退两个（前提是我得有三个commit，这里是我又新建了一个）
cat lightbright.txt 查看当前文件内容
](https://img-blog.csdnimg.cn/20210216092811752.png)
此时我们发现，版本已经进行了回退
- git log 查看现在版本库的状态
此时我们发现，uodate lightbright.txt 这个commit已经没有了。
也就是说，我们回到了19世纪，但是回不来了。。。。。。
那怎么办呢？ - git reset -hard 版本号 重新回到20世纪
只要我们的命令行窗口没有关闭，我们就可以看到之前的版本号。
git reset --hard 2ea23(不用写全)
git log
此时我们发现，我们又回来了
- 关闭了命令窗口，找不到commit id 回不去怎么办？
吃个后悔药吧。
git reflog记录你的命令。
通过这个指令我们就可以看到之前的版本号了，进行恢复即可。但是还是要记得commit id 哦，否则提交多了，自己也不知道哪个是想要的版本号。
工作区和暂存区
工作区
电脑里面能看到的目录 testgit 就是一个工作区
版本库（Repository）
工作区有一个隐藏目录 .git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
- git add 即将文件添加到了暂存区。
- git commit 提交更改，就是把暂存区的内容提交到了当前分支。
- 创建GIT版本库时，git会自动帮我们创建一个master分支，所以当前git commit 提交的是master分支。
总结： 需要提交的文件修改通通放到暂存区，然后一次性提交所有修改。
例子：
在lightbright.txt中添加数字0-9，并且在当前文件夹下新建一个文件夹tiankong.txt
-
git status
lightbright文件做了修改，没有提交。
新创建的文件显示untracked（开始回升的） -
使用两次git add ，分别将两个文件提交
版本库现状：
-
提交修改
版本库现状
总结： git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
管理修改
GIt是管理的修改，而非管理的文件。
-
tiankong.txt中添加123456，并且git add .
-
tiankong.txt中添加654321，直接commit
此时我们发现，tiankong.txt文件中有修改未提交 -
分析
第一次修改——>git add. ——> 第二次修改——> git commit
由此可见，提交的时候，我们只提交了位于暂存区的修改，第二次修改后没有放入暂存区，所以第二次修改，并没有被提交 -
再次 git add . 之后commit
此时我们发现，当前不存在没有提交的修改。
总结： 每次修改，如果不用git add 放入暂存区，则就不会加入commit中。
撤销修改
指令：
1.git checkout – tiankong.txt
可以让你的代码回退到最近的git add. 或 git commit 上。
2.git reset HEAD tiankong.txt
将已经放入暂存区的修改撤销掉，重新放回工作区
情况一：修改后还没有添加到暂存区
撤销操作，回到版本库一模一样的状态
- tiankong.txt 添加 小明
- 进行撤销操作 git checkout – tiankong.txt
结果：小明被撤销
情况二：已经添加到暂存区再修改
撤销操作，回到添加到暂存区后的状态
- tiankong.txt添加小红，并添加到暂存区 git add .，进行撤销操作 git checkout – tiankong.txt
小红还在 - 添加 小红是小明的女朋友
- 进行撤销操作（不放入暂存区） git checkout – tiankong.txt
结果：小红是小明的女朋友 被撤销
小结： git checkout – 文件名 可以让你的代码回退到最近的git add. 或 git commit 上。
情况三：修改的内容已进入暂存区
git reset HEAD tiankong.txt
将已经放入暂存区的修改撤销掉，重新放回工作区
-
tiankong.txt 中添加小明是个博士生，并进入暂存区 git add.
-
进行撤销操作 git reset HEAD tiankong.txt
我们通过git status 查看状态可知，目前修改已从暂存区回归到了工作区。现在暂存区是干净的，工作区有修改
总结
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
删除文件
情况一：彻底删除某一文件，从版本库中也删除
- 删除tiankong,txt文件夹，并从版本库删除 git rm 文件名 git commit
现在，文件就从版本库中被删除了。
此时我进行恢复，我可以通过版本回退，回退到上一个版本，再进行恢复。
情况二：误删某个文件，通过版本库恢复
- 删除天空这个文件夹
- 恢复天空这个文件夹 git check – tiankong.file
因为此时我们只是删除了工作目录中的tiankong.file,之前我们把这个文件已经提交到版本库了，所以我们还可以恢复。
5895
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
