1、在填写忽略文件的过程中，我发现.gitignore中已经标明忽略的文件目录下的文件，当我想git push的时候还会出现在push的目录中，原因是因为git忽略目录中，新建的文件在git中会有缓存，如果某些文件已经被纳入了版本管理中，就算是在.gitignore中已经声明了忽略路径也是不起作用的，这时候我们就应该先把本地缓存删除，然后再进行git push，这样就不会出现忽略的文件了。git清除本地缓存命令如下：
git rm -r —cached .
git add .
git commit -m ‘update .gitignore’

2、rebase
1）合并commit
2）合并分支，以origin为基础，将本地提交作为patch打到origin上
首先， git 会把 feature1 分支里面的每个 commit 取消掉；
其次，把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
然后，把 feature1 分支更新到最新的 master 分支；
最后，把上面保存的 patch 文件应用到 feature1 分支上；

https://www.codercto.com/a/45325.html

合并多个提交：
git rebase -i $commitId（待合并的若干commit的前面一个commitId）
把后面几个不想要的commit的pick改成s，最后wq

3、git clone [地址] [本地目录]

4、git pull origin $remote_branch 把指定远程分支拉下来并且合并到当前本地分支

show

git show commit-id
显示一次commit的详情

git pull origin $branch 拉取远程分支

git checkout -b Git - 图1branch

git clone -b $branch $repo

基本用法：

git pull <远程主机名> <远程分支名>:<本地分支名>

例如执行下面语句：

git pull origin master:brantest

将远程主机origin的master分支拉取过来，与本地的brantest分支合并。

后面的冒号可以省略：

git pull origin master

reset

reset —soft：保留工作目录，并把重置 HEAD 所带来的新的差异放进暂存区
reset 不加参数(mixed)：保留工作目录，并清空暂存区
reset —hard：重置stage区和工作目录:

区别：
—hard：重置位置的同时，直接将 working Tree工作目录、 index 暂存区及 repository 都重置成目标Reset节点的內容,所以效果看起来等同于清空暂存区和工作区。

—soft：重置位置的同时，保留working Tree工作目录和index暂存区的内容，只让repository中的内容和 reset 目标节点保持一致，因此原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)。所以效果看起来就是工作目录的内容不变，暂存区原有的内容也不变，只是原节点和Reset节点之间的所有差异都会放到暂存区中。

—mixed（默认）：重置位置的同时，只保留Working Tree工作目录的內容，但会将 Index暂存区 和 Repository 中的內容更改和reset目标节点一致，因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。

使用场景:
—hard：(1) 要放弃目前本地的所有改变時，即去掉所有add到暂存区的文件和工作区的文件，可以执行 git reset -hard HEAD 来强制恢复git管理的文件夹的內容及状态；(2) 真的想抛弃目标节点后的所有commit（可能觉得目标节点到原节点之间的commit提交都是错了，之前所有的commit有问题）。

—soft：原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)，所以假如我们之前工作目录没有改过任何文件，也没add到暂存区，那么使用reset —soft后，我们可以直接执行 git commit 將 index暂存区中的內容提交至 repository 中。为什么要这样呢？这样做的使用场景是：假如我们想合并「当前节点」与「reset目标节点」之间不具太大意义的 commit 记录(可能是阶段性地频繁提交,就是开发一个功能的时候，改或者增加一个文件的时候就commit，这样做导致一个完整的功能可能会好多个commit点，这时假如你需要把这些commit整合成一个commit的时候)時，可以考虑使用reset —soft来让 commit 演进线图较为清晰。总而言之，可以使用—soft合并commit节点。

—mixed（默认）：(1)使用完reset —mixed后，我們可以直接执行 git add 将這些改变果的文件內容加入 index 暂存区中，再执行 git commit 将 Index暂存区 中的內容提交至Repository中，这样一样可以达到合并commit节点的效果（与上面—soft合并commit节点差不多，只是多了git add添加到暂存区的操作）；(2)移除所有Index暂存区中准备要提交的文件(Staged files)，我们可以执行 git reset HEAD 来 Unstage 所有已列入 Index暂存区 的待提交的文件。(有时候发现add错文件到暂存区，就可以使用命令)。(3)commit提交某些错误代码，或者没有必要的文件也被commit上去，不想再修改错误再commit（因为会留下一个错误commit点），可以回退到正确的commit点上，然后所有原节点和reset节点之间差异会返回工作目录，假如有个没必要的文件的话就可以直接删除了，再commit上去就OK了。

git reset $commitid $filename —hard

删除分支

git branch -D 删除本地分支
git push origin —delete 分支

git commit —amend（可以去修改上一次提交的信息，也可以合并提交）

jianshu.com/p/e4013267de55
合并提交：
我提交了一次，然后写了一些代码
之前的操作步骤是：git add . git commit -m “ok” git push
现在的操作步骤是：git add . git commit —amend 可以不修改提交信息 git push -f （自己的开发分支上）

git merge —abort

修改origin git remote set-url origin / 读 git remote -v

git branch -m 源分支 目标分支

git tagxxx; git push —tags/git push origin xxx;

git tag -d xxx;git push —delete origin xxx

查询远程仓库 git remote -v

git rebase $commitId（合并commit）

git rebase -i 想处理的提交的前一个提交commitid

如果存在merge commit，此时有可能会不显示这个merge commit。一种办法是直接到比较早的commit，git reset $commitId —soft，然后将若干提交合并为一个，但是会吞掉merge过来的那些commit。

此时可以git rebase -i xxx—rebase-merges，然后把merge过来的commitId调整位置到最开始的位置，把自己的commit放后面，提交。此时会重新走一遍merge然后处理冲突的流程，并且会将自己的commit合并为一个。
https://zhuanlan.zhihu.com/p/260655709

git rebase $branch（用来替代merge，在gerrit下不适合用merge）

会将你自己比$branch更新的提交放在顶上（也就是最后），相当于以$branch为基础，把自己的增量commit放在最后。
如果就是当前分支，不要用pull（因为会同时merge），需要写git rebase origin/远程分支（如果本地不是最新的，要先git fetch origin/远程分支）。

git commit -amend之后想撤销

退回到上次操作 git reset HEAD@{1}
保险一点：git reflog，然后git reset $commitId

git reflog —date=iso

展示HEAD在各个分支上的移动轨迹

清空

还没add：git checkout .
add了：git reset .

文件状态

结起来一个文件的状态通常可以分为：

不受版本控制的 untracked 状态
受版本控制并且已修改的 modified 状态
受版本控制已修改并提交到暂存区的 staged 状态
从暂存区已经提交到本地仓库的 committed 状态
提交到本地仓库未修改或者从远程仓库克隆下来的 unmodified 状态
[

](https://blog.csdn.net/albertsh/article/details/104719370/)

各种回退命令

git checkout

这个命令又出现了，上次是总结 git branch 分支操作的时候，git checkout 可以用来新建或者切换分支，这次总结回退版本的命令，git checkout 也可以用来回退文件版本，很神奇吧。

其实这个命令的作用就是它单词的本义——检出，他的常用操作也取自这个意思，比如 git checkout branch_name 切换分支操作，实际上就是把指定分支在仓库中对应的所有文件检出来覆盖当前工作区，最终表现就是切换了分支。

而针对于文件的检出可以使用 git checkout — file_name，当不指定 commit id 就是将暂存区的内容恢复到工作区，也就可以达到回退本地修改的作用。

不过，这个身兼数职的 git checkout 命令现在可以轻松一些了，从 Git 2.23 版本开始引入了两个新的命令： git switch 用来切换分支，git restore用来还原工作区的文件，这个后面还会提到。

git revert

revert 这个词的意思是：归还，复原，回退，它和后面即将提到的 restore 在意思上简直无法区分，为了区别他们两个这里可以把 git revert 看成归还的意思，对某次提交执行 git revert 命令就是对这次修改执行一个归还操作，其实就是反向再修改一次。

要理解 git revert 就要从反向修改的含义来看，当我们再一个文件中添加一行内容，并提交到版本库后，产生一个提交id——commit-id-a，如果这时使用 git revert commit-id-a 命令，就相当于在工作区中的那个文件将刚在新加的一行内容删除掉，然后再进行一个提交。

注意，这个操作是会改变分支记录的，因为产生了新的提交。

git restore

这个命令是 Git 2.23 版本之后新加的，用来分担之前 git checkout 命令的功能，作用就是用暂存区或者版本库中的文件覆盖本地文件的修改可以达到回退修改的目的，同时也可以使用版本库中的文件覆盖暂存区的文件，达到回退git add 命令的目的。

注意，这个操作是不会影响分支记录的，就是相当于之前的 git checkout 命令重新检出一份文件来覆盖本地的修改。

git reset

reset 重新设置的意思，其实就是用来设置分支的头部指向，当进行了一系列的提交之后，忽然发现最近的几次提交有问题，想从提交记录中删除，这是就会用到 git reset 命令，这个命令后面跟 commit id，表示当前分支回退到这个 commit id 对应的状态，之后的日志记录被删除，工作区中的文件状态根据参数的不同会恢复到不同的状态。

—soft: 被回退的那些版本的修改会被放在暂存区，可以再次提交。

—mixed: 默认选项，被回退的那些版本的修改会放在工作目录，可以先加到暂存区，然后再提交。

—hard: 被回退的那些版本的修改会直接舍弃，好像它们没有来过一样。

这样来看，git set 命令好像是用来回退版本的，但是如果使用 git rest HEAD file_name 命令就可以将一个文件回退到 HEAD 指向版本所对应的状态，其实就是当前版本库中的状态，也就相当于还原了本地的修改。

git rm

临时插播的命令，本来删除不能算是回退，但是如果它和某些命令反着来就是一种回退，比如对一个新文件使用 git add newfile_name 命令，然后再使用 git rm —cached newfile_name 就可以将这个文件从暂存区移除掉，但是在工作区里没有消失，如果不加 —cached 参数，就会从工作区和版本库暂存区同时删除，相当于执行了 rm newfile_name 和 git add new_file 两条命令

git stash / git stash apply


https://www.cnblogs.com/zndxall/archive/2018/09/04/9586088.html

拉代码 git pull —rebase / git fetch origin xxx分支

rebase远程分支

git rebase origin/分支名
不要写成
git rebase origin 分支名
https://blog.csdn.net/shengzhu1/article/details/84836314

文件状态

image.png

已经跟踪了（待暂存）的文件如何删除

image.png
git checkout — …

已经在暂存区（待提交）的文件（staged）如何删除

image.png

这些文件就是在待提交状态。
要删除的话：git rm —cached …

在origin基础上新增一个远程仓库

git remote add upstream-selftest ssh://songxinjian@gerrit.zhenguanyu.com:29418/yfd-data-migration-selftest
git push upstream-selftest 提交当前分支
https://www.php.cn/tool/git/487235.html