撤销操作

# 撤销暂存，保留修改内容
git reset HEAD <file>

# 撤销修改
git checkout -- <file>

远程仓库操作

 #添加远程仓库
 git remote add demo https://gitee.com/dwp1216/demo.git

拉取指定文件

git init
git remote add -f origin https://172.16.0.120/astri/SmartDevelop/sdw-sys-manage.git
git config core.sparsecheckout true
echo 文件名或其它匹配规则 >> .git/info/sparse-checkout
git pull sdw-sys-manage develop

git reset命令

HEAD指针指向上次提交，可用于回滚操作
git reset Head~

reset 命令会以特定的顺序重写HEAD、索引、工作目录，在你指定以下选项时停止：

1. 移动 HEAD 分支的指向 （若指定了 --soft，则到此停止）

2. 使索引看起来像 HEAD （若未指定 --hard，则到此停止）

3. 使工作目录看起来像索引

–hard 标记是 reset 命令唯一的危险用法，它也是 Git 会真正地销毁数据的仅有的几个操作之一。 其他任何形式的 reset 调用都可以轻松撤消，但是 --hard 选项不能，因为它强制覆盖了工作目录中的文件。

在这种特殊情况下，我们的 Git 数据库中还留有提交版本，可以通过 reflog 来找回它。但是若该文件还未提交，Git 仍会覆盖它从而导致无法恢复。

git checkout

运行 git checkout [branch] 与运行 git reset --hard [branch] 非常相似，它会更新所有三棵树使其看起来像 [branch]，不过有两点重要的区别。

首先不同于 reset --hard，checkout 对工作目录是安全的，它会通过检查来确保不会将已更改的文件吹走。 其实它还更聪明一些。它会在工作目录中先试着简单合并一下，这样所有_还未修改过的_文件都会被更新。 而 reset --hard 则会不做检查就全面地替换所有东西。

第二个重要的区别是如何更新 HEAD。 reset 会移动 HEAD 分支的指向，而 checkout 只会移动 HEAD 自身来指向另一个分支。

例如，假设我们有 master 和 develop 分支，它们分别指向不同的提交；我们现在在 develop 上（所以 HEAD 指向它）。 如果我们运行 git reset master，那么 develop 自身现在会和 master 指向同一个提交。 而如果我们运行 git checkout master 的话，develop 不会移动，HEAD 自身会移动。 现在 HEAD 将会指向 master。

所以，虽然在这两种情况下我们都移动 HEAD 使其指向了提交 A，但_做法_是非常不同的。 reset 会移动 HEAD 分支的指向，而 checkout 则移动 HEAD 自身。

git merge

#取消合并
git merge --abort

#忽略空白修改
git merge -Xignore-all-space

git原理

.git目录下有以下文件夹：

objects： 存储所有数据内容；

refs： 存储指向数据（分支）的提交对象的指针；

HEAD： 指示目前被检出的分支；

index： 保存暂存区信息

数据恢复：

单行显示日志
git log --pretty=oneline
查询引用日志
git reflog

恢复到指定提交
git reset --hard 82446c0

如果在引用日志中未查询到，可以使用it fsck 实用工具，将会检查数据库的完整性。 如果使用一个 --full 选项运行它，它会向你显示出所有没有被其他对象指向的对象：

git fsck --full

可以在 “dangling commit” 后看到你丢失的提交