添加文件到Git仓库，分两步：
要随时掌握工作区的状态，使用git status命令。
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
合并分支： git merge （合并）与 git rebase（变基）
NOW 所示： git merge 工作流程则如下：
git rebase。
git reset --hard HEAD~ 撤销回到 NOW 的状态。然后开始 git rebase工作流如下示：git reset --hard ORIG_HEAD
git pull 与 git fetch 的区别
git pull.执行fetch就可以取得远程数据库的最新历史记录。取得的提交会导入到没有名字的分支，这个分支可以从名为FETCH_HEAD的退出。
关联后，使用命令git push -u origin master第一次推送master分支的所有 内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
如果想要提交某一次指定的 commit 而不是本地最新的 commit， 可以使用如下命令：
$ git push <remote name> <commit hash>:<remote branch name>
# Example:
$ git push origin 2dc2b7e393e6b712ef103eaac81050b9693395a4:master
Fork 模式来协同开发时，常常会在自己的 Fork 分支上提交各种修改。但是有一个问题? 上游仓库，也就是源分支代码更新了，我们 Fork 的下游分支，怎么同步上游仓库的更新呢？第一步：查看所有远程库的远程地址
git remote -v
第二步：添加源分支 URL
git remote add upstream [源项目 URL]
第三步：检查所有远程库的远程地址
git remote -v
第四步：从源分支获取最新的代码
git fetch upstream / git fetch upstream [特定分支]
第五步：切换到主分支
git checkout master
第六步：合并本地分支和源分支
git merge upstream/master
第七步：Push 到 Fork 分支
git push
Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快
1、可以先使用 git log 找到该个文件提交的历史版本
2、然后使用 git show <git提交版本号> <文件名> 查看历史版本
git log或者 git log --pretty=oneline 找出 commit_id 。之后，便可以使用命令git reset --hard commit_id 切换版本了git checkout -b commit_id 的方法，创建一个新的分支，并切换到新的分支git branch 可以查看有哪些分支，注意看 master 分支前的 * 字符：它表示当前所在的分支。也就是说，如果现在提交更新，master 分支将随着开发进度前移。若要查看各个分支最后一个提交对象的信息，运行 git branch -v，然后可以用 git checkout 切换到对应的分支git tag -a <版本号> -m "<备注信息>"推送所有标签
git push origin --tags
推送指定版本的标签
git push origin <版本号>
删除远程仓库的标签
同创建本地标签一样，删除了本地标签之后也要同时删除远程仓库的标签。
新版本Git (> v1.7.0)
git push origin --delete <版本号>
在GitHub上我们会去fork别人的一个项目，这就在自己的Github上生成了一个与原作者项目互不影响的副本，自己可以将自己Github上的这个项目再clone到本地进行修改，修改后再push，只有自己Github上的项目会发生改变，而原作者项目并不会受影响，避免了原作者项目被污染。但经过一段时间， 有可能作者原来的代码变化很大， 你想接着在他最新的代码上修改， 这时你需要合并原作者的最新代码过来， 让你的项目变成最新的。
1、先克隆项目到本地：
Git clone https://github.com/iakuf/mojo
cd mojo
2、添加原作者项目的 remote 地址， 然后将代码 fetch 过来
git remote add sri https://github.com/kraih/mojo
git fetch sri
‘sri’相当于一个别名
查看本地项目目录： git remote -v
3、合并
git checkout master
git merge sri/master
如果有冲突的话，需要丢掉本地分支：
git reset –hard sri/master
4、这时你的当前本地的项目变成和原作者的主项目一样了，可以把它提交到你的GitHub库
git commit -am ‘更新到原作者的主分支’
git push origin
git push -u origin master -f –强制提交
把某些目录或文件加入忽略规则，按照上述方法定义后发现并未生效，原因是.gitignore只能忽略那些原来没有被追踪的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。那么解决方法就是先把本地缓存删除（改变成未被追踪状态），然后再提交：
git rm -r --cached .
git add .
git commit -m 'update .gitignore'
用户名和邮箱地址的作用
查看用户名和邮箱地址：
$ git config user.name
$ git config user.email
修改用户名和邮箱地址：
$ git config --global user.name "username"
$ git config --global user.email "email"
其中，加上 --global 是全局设置的意思，不加是局部设置的意思。
The requested URL returned error:
403
可以清楚缓存后，在尝试。命令如下：
git config --local --unset credential.helper
git config --global --unset credential.helper
git config --system --unset credential.helper
关于 credential 可以参见：
https://blog.csdn.net/u012163684/article/details/52433645
比如我们有 2 个分支：master, dev，现在想查看这两个 branch 的区别，有以下几种方式：
1.查看 dev 有，而 master 中没有的：
git log dev ^master
同理查看 master 中有，而 dev 中没有的内容：
git log master ^dev
这里写图片描述
2 查看 dev 中比 master 中多提交了哪些内容：
git log master..dev
注意，列出来的是两个点后边（此处即dev）多提交的内容。同理，想知道 master 比 dev 多提交了什么：
git log dev..master
3 不知道谁提交的多谁提交的少，单纯想知道有什么不一样：
git log dev…master
4.在上述情况下，再显示出每个提交是在哪个分支上：
git log --left-right dev…master
git commit --amend : 该命令可以使将这一次的提交合并到上一次最后的提交 commit 里。git revert HEAD: 通过修改 HEAD 的指向就可以实现撤销恢复。HEAD 表示工作区当前指针。git reset --hard HEAD~~ : 如果想删除当前分支最前面的两个提交, 可以使用该命令。如果撤销失败，可以使用 git reset --hard ORIG_HEAD 恢复到原来的状态。git cherry-pick 99daed2: git cherry-pick 可以将任意分支上的指定的 hash commit (如 99daed2) 合并导入到当前操作（如 master）分支。rebase -i：合并过去的几个提交成一个提交。如 git rebase -i HEAD~~。这样两个提交就合并成一个提交了。可以用 log命令确认历史记录。若其中还要修改某些文件内容，则可以修改后使用 git commit --amend 合并至上一次提交后，在执行 git rebase --continue.merge --squash: 本地端的历史记录的状态如下图显示。把issue1分支的所有提交合并成一个提交，并导入到master分支。
git checkout master , git merge --squash issue1 . 若有冲突，解决后， add 冲突文件后，再 commit 即可。背景：我们经常会遇到：某个工作中的项目需要包含并使用另一个项目。 也许是第三方库，或者你独立开发的，用于多个父项目的库。 现在问题来了：你想要把它们当做两个独立的项目，同时又想在一个项目中使用另一个。
如果将这个库包含进来，那么无论用何种方式都很难定制它，部署则更加困难，因为你必须确保每一个客户端都包含该库。 如果将代码复制到自己的项目中，那么你做的任何自定义修改都会使合并上游的改动变得困难。
Git 通过子模块来解决这个问题。 子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。 它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立。git 提交日志的独立，代码管理的独立性。从而避免将主项目和子项目混成一谈，从而避免 git 代码管理的混乱。
下面我们介绍子模块相关的基础命令，详细使用请参考 man page。
添加子模块非常简单，命令如下：
git submodule add <url> <path>
其中，url为子模块的路径，path为该子模块存储的目录路径。执行成功后，git status会看到项目中修改了.gitmodules，并增加了一个新文件（为刚刚添加的路径）
git diff --cached 查看修改内容可以看到增加了子模块，并且新文件下为子模块的提交hash摘要
git commit提交即完成子模块的添加
克隆项目后，默认子模块目录下无任何内容。需要在项目根目录执行如下命令完成子模块的下载：
git submodule init
git submodule update
或：
git submodule update --init --recursive
执行后，子模块目录下就有了源码，再执行相应的makefile即可。
子模块的维护者提交了更新后，使用子模块的项目必须手动更新才能包含最新的提交。
在项目中，进入到子模块目录下，执行 git pull更新，查看git log查看相应提交。
完成后返回到项目目录，可以看到子模块有待提交的更新，使用git add，提交即可。
有时子模块的项目维护地址发生了变化，或者需要替换子模块，就需要删除原有的子模块。
删除子模块较复杂，步骤如下：
rm -rf 子模块目录 删除子模块目录及源码
vi .gitmodules 删除项目目录下.gitmodules文件中子模块相关条目
vi .git/config 删除配置项中子模块相关条目
rm .git/module/* 删除模块下的子模块目录，每个子模块对应一个目录，注意只删除对应的子模块目录即可
执行完成后，再执行添加子模块命令即可，如果仍然报错，执行如下：
git rm --cached 子模块名称
完成删除后，提交到仓库即可。
根据 commit 记录生成的 patch，一般我们可以通过 git log 查看有哪一些 commit
git format-patch -M mastergit format-patch 4e16 --4e16指的是commit名git format-patch --root 4e16git format-patch 365a..4e16 --365a和4e16分别对应两次提交的名称git format-patch –n 07fe --n指patch数，07fe对应提交的名称git format-patch -1 07fegit format-patch 生成的补丁文件默认从1开始顺序编号，并使用对应提交信息中的第一行作为文件名。如果使用了-- numbered-files选项，则文件名只有编号，不包含提交信息；如果指定了–stdout选项，可指定输出位置，如当所有patch输出到一个文件；可指定-o <dir>指定patch的存放目录；
git apply --stat newpatch.patchgit apply --check newpatch.patchgit am --signoff < newpatch.patch如果应用patch出现问题，发生冲突：
https://backlog.com/git-tutorial/cn/reference/
https://www.cnblogs.com/wupeiqi/p/7295372.html
http://www.cnblogs.com/zhaoyanjun/p/5882784.html
https://blog.csdn.net/b644rofp20z37485o35m/article/details/80851382