基本指令

git init
git add .
git add *.c
git commit -m "initial"
git status
git diff
git log

git clone https://
git remote -v
git remote add pb https://
//如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。 所以，git fetch origin 会抓取克隆（或上一次抓取）后新推送的所有工作。
git fetch
git push origin master
git pull = git fetch + git merge

//查看，创建，删除，切换，创建并切换本地分支
git branch //列出所有分支
git branch branch_name //创建分支
git branch -d branch_name //删除分支
git checkout branch_name //切换分支
git checkout -b branch_name //创建并切换分支

//查看，删除远程分支
git branch -a	
git push origin --delete branch_name

//合并分支
git checkout master
git merge hotfix

//分支同步
git rebase master

//查看分支头位置
git rev-parse head

revert commit：反做

适用场景： 如果我们想撤销之前的某一版本，但是又想保留该目标版本后面的版本，记录下这整个版本变动流程，就可以用这种方法。比如，我们commit了三个版本（版本一、版本二、版本三）；突然发现版本二不行（如：有bug），想要撤销版本二，但又不想影响撤销版本三的提交；就可以用 git revert 命令来反做版本二，生成新的版本四，这个版本四里会保留版本三的东西，但撤销了版本二的东西。revert的文件，如果后面commit同样修改过该文件，那么可能会有冲突。

reset commit：回退

适用场景：如果想恢复到之前某个提交的版本，且那个版本之后提交的版本我们都不要了，就可以用这种方法。回退到版本一，版本二和版本三都放弃。

reset - Keep Changes (–mixed)

删除该commit以后的所有commits，但是把后面的所有changes保留。相当于只删除了后面的commit IDs，所有代码的修改全部保留，此时如果再commit，相当于合并多个commit为一个commit。

reset - Delete Changes (–hard)

不仅删除了该commit后面的commit IDs，同时也把代码的修改内容也删除了。相当于完全删除。

git merge

“pull”命令把”origin”分支上的修改拉下来并且和你的修改合并； 结果看起来就像一个新的”合并的提交”(merge commit).使用merge命令合并分支，解决完冲突，执行git add .和git commit -m’fix conflict’。这个时候会产生一个新的commit。
日志文件夹

git rebase

git rebase命令会把你的”mywork”分支里的每个提交(commit)取消掉，并且把它们临时保存为补丁(patch)(这些补丁放到”.git/rebase”目录中),然后把”mywork”分支更新为最新的”origin”分支，最后把保存的这些补丁应用到”mywork”分支上。当’mywork’分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除.使用rebase命令合并分支，解决完冲突，执行git add .和git rebase –continue，不会产生额外的commit。这样的好处是，‘干净’，分支上不会有无意义的解决分支的commit；坏处，如果合并的分支中存在多个commit，需要重复处理多次冲突。If your branch is far behind your main branch, consider rebasing your branches before you open a pull request. Rebased branches will merge into your main branch without conflicts.
日志文件夹
日志文件夹

rebase & merge

rebase和merge区别就是:merge会按照时间顺序来合并commit树，而rebase 会将新分支的commit直接放在本分支的后面。

gitignore

  • 空格不匹配任意文件，可作为分隔符，可用反斜杠转义
  • 开头的文件标识注释，可以使用反斜杠进行转义
  • ! 开头的模式标识否定，该文件将会再次被包含，如果排除了该文件的父级目录，则使用 ! 也不会再次被包含。可以使用反斜杠进行转义
  • / 结束的模式只匹配文件夹以及在该文件夹路径下的内容，但是不匹配该文件
  • / 开始的模式匹配项目跟目录
  • 如果一个模式不包含斜杠，则它匹配相对于当前 .gitignore 文件路径的内容，如果该模式不在 .gitignore 文件中，则相对于项目根目录
  • ** 匹配多级目录，可在开始，中间，结束
  • ? 通用匹配单个字符
    • 通用匹配零个或多个字符

  • [] 通用匹配单个字符列表

      bin/: 忽略当前路径下的bin文件夹，该文件夹下的所有内容都会被忽略，不忽略 bin 文件
  /bin: 忽略根目录下的bin文件
  /*.c: 忽略 cat.c，不忽略 build/cat.c
  debug/*.obj: 忽略 debug/io.obj，不忽略 debug/common/io.obj 和 tools/debug/io.obj
  **/foo: 忽略/foo, a/foo, a/b/foo等
  a/**/b: 忽略a/b, a/x/b, a/x/y/b等
  !/bin/run.sh: 不忽略 bin 目录下的 run.sh 文件
  *.log: 忽略所有 .log 文件
  config.php: 忽略当前路径的 config.php 文件

Advanced

如果需要排除!/extlib/EmbedthisAppweb/bin/x64/文件夹下的文件，且在此之前已经有x64/和bin/的配置，那么同时也需要设置两行排除配置，如下所示，如果这保留!/extlib/EmbedthisAppweb/bin/x64/而没有!/extlib/EmbedthisAppweb/bin/，会因为bin目录没有被排除而导致失效。

x64/
bin/
!/extlib/EmbedthisAppweb/bin/
!/extlib/EmbedthisAppweb/bin/x64/

Prune Remote Branches

如果在Visual Studio中设置了Tools -> Options -> Source Control -> Git Global Settings -> Prune remote branches during fetch = true，那么在每次fetch时，会自动同步删除本地origin下的分支，本次非origin下的分支不会同步删除。
日志文件夹
日志文件夹

git status

一个文件从开始到提交需要经历四个阶段：未跟踪 -> 未修改 -> 已修改但未计划提交 -> 计划提交

  • Untracked: Untracked files are everything else – any files in your working directory that were not in your last snap- shot and are not in your staging area.
  • Unmodified files: These files haven’t changed since your last commit.
  • Modified files: These files have changes since your last commit, but you haven’t yet staged them for the next commit.
  • Staged files: These files have changes that will be added to the next commit.

日志文件夹

git stash

git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复出堆栈中的内容。这也就是说，stash中的内容不仅仅可以恢复到原先开发的分支，也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中。

  1. 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。
  2. 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。

#v使用–no-ff进行合并 —no-ff (no fast foward)，使得每一次的合并都创建一个新的commit记录。即使这个commit只是fast-foward，用来避免丢失信息。

Semi-linear merge

This strategy is the most exotic – it’s a mix of rebase and a merge. First, the commits in the pull request are rebased on top of the master branch. Then those rebased pull requests are merged into master branch. It emulates running git rebase master on the pull request branch, followed by git merge pr --no-ff on the master branch.

Master和Dev同步

当Master和Dev分支不同步时，可以使用Rebase和fast-forward，使两边同步。

Azure DevOps Pull Request

  1. Merge (no fast forward) = git merge pr
  2. Squash commit = git merge pr –squash
  3. Rebase and fast-forward = git rebase master + git merge pr –ff-only
  4. Semi-linear merge = git rebase master + git merge pr –no-ff

git config

git config user.name "Your Name"
git config user.email "your.email@example.com"
	
git config --local user.name "Your Name"
git config --local user.email "your.email@example.com"