为了适应新的工作环境，docker与git必须快速上手，很久没用了。做个笔记.
1. 查看当前登录账号：
git config user.name
2. 查看当前登录邮箱：
git config user.email
3. 修改用户名和邮箱：
git config --global user.name "Your_username"
git config --global user.email "Your_email"
git __init__ 这个文件夹下面所有的文件都会收到git软件的管理
用命令git add告诉Git，把文件添加到仓库
git add 文件名1 文件名2 放入暂存区
git commit -m "提示，最好写英文高大上" commit的时候，关注的只有add的时候的状态，所有最好全部add了,再进行commit。
git commit -am 应该相当于： git add -u git commit -m 而不是 git add . 因为-am并不会提交新增的untracked文件吧(git commit -am可以避免修改文件的提交就是git add .)
git commit --amend
这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（ 例如， 在上次
提交后马上执行了此命令） ， 那么快照会保持不变， 而你所修改的只是提交信息。
文本编辑器启动后， 可以看到之前的提交信息。 编辑后保存会覆盖原来的提交信息。
例如， 你提交后发现忘记了暂存某些需要的修改， 可以像下面这样操作：
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
最终你只会有一个提交 - 第二次提交将代替第一次提交的结果。
git status可以查看git代码仓库的状态
git diff 文件名可以查看文件修改的变化
- git diff ： 对比工作区(未 git add)和暂存区(git add 之后)
- git diff 新添加文件默认是不能追踪的
- git diff --cached: 对比暂存区(git add 之后)和版本库(git commit 之后)
- git diff HEAD: 对比工作区(未 git add)和版本库(git commit 之后)
git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file。如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：
git reflog
用git reflog查看命令历史，以便确定要回到未来的哪个版本。(当回退到最初的版本，想返回新的版本用这个找新的版本的id)
shijianongdeMBP:learngit shijianzhong$ git reflog
0fd808e (HEAD -> master) HEAD@{0}: reset: moving to 0fd808e
c9a0144 HEAD@{1}: reset: moving to c9a0144
0fd808e (HEAD -> master) HEAD@{2}: commit: 1.txt add
4646fe1 HEAD@{3}: commit: add distributed
c9a0144 HEAD@{4}: commit (initial): wrote a readme file
shijianongdeMBP:learngit shijianzhong$
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id
git checkout -- 文件名 当修改以后没有提交到缓存区，可以用这个命令，恢复到最近一次提交的状态。
git restore 文件名 通过.是所有的文件 *.后缀也可以，今天傻掉了，刚刚把前面的工作都restore了。
git reset HEAD <file>. 从缓存区撤回到本地文档，然后可以通过checkout -- 恢复到最近一次提交
git restore --staged(这个是新版本的用法) 这个也是从暂存区撤回的消息。
git rm 文件名 当删除一个文件的时候，需要通过git rm来确认删除了这个文件，这个会提交到缓存区，然后通过commit提交到主分支上面
- rm
删除文件
- git rm
git rm
当我们需要删除暂存区或分支上的文件, 同时工作区也不需要这个文件了, 可以使用git rm
git rm file = rm file+ git add file
rm file删除本地文件
git add file 提交删除的步骤同步到git仓库
- git rm --cached file
当我们需要删除暂存区或分支上的文件, 但本地又需要使用, 只是不希望这个文件被版本控制, 可以使用 git rm --cached
git rm --cached 会从index里面删除该文件，下次commit的时候会修改git仓库，但是本地的文件还是保留
- Untrack and stop tracking files in git
有一些文件我们不想提交到git上去了，但是又被检测到有变化，显示Untracked files，我们可以采用
git rm --cached file来停止跟踪这些文件
中间也可以通过git checkout与git reset HEAD从删除状态或者缓存区返回文件。
新建、合并、删除分支操作
git brance 分支名
git checkout -b 分支名 然后直接进入该分支。
查看分支：git branch -r 查看远程分支 -a 查看所有分支
创建分支：git branch <name>
切换分支：git checkout <name>或者git switch <name>
创建+切换分支：git checkout -b <name>或者git switch -c <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
解决冲突
当两个分支对同一个文件都进行了修改,在merge的时候会出现提示冲突，
Creating a new branch is quick AND simple. <<<<<<< HEAD master ======= featuel >>>>>>> featurel
文件里面会出现这里的内容，这里需要手工调试，调试完成后 git add 并git commit
用git log --graph命令可以看到分支合并图。
git log --graph --pretty=oneline --abbrev-commit
分支管理策略
当一个分支修改了文件，并进行了提交。主分支去merge的时候，会直接把指针指向这个分支，这样的话，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
可以在merge的时候添加参数 下面我们实战一下--no-ff方式的git merge：
git merge --no--ff -m "xxxxx"
bug分支
幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
经过测试好像只能隐藏修改的作业任务，新增加的文件任务无法影藏。
git stash list 查看影藏的作业
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了
如果想要找到bug的任务做的事情，可以通过git cherry-pick id
删除一个没有被合并(merge)的分支，可以用git branch -D 分支名
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin
用git remote -v显示更详细的信息 显示远程的信息
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
-
从本地推送分支，使用
git push origin 分支名，如果推送失败，先用git pull抓取远程的新提交； -
在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致； -
建立本地分支和远程分支的关联，使用
git branch --set-upstream branch-name origin/branch-name； - 从远程抓取分支，使用
git pull，如果有冲突，要先处理冲突。
git rebase 暂时用不到
强制拉取最新的代码库到本地。
git fetch --all //只是下载代码到本地，不进行合并操作
git reset --hard origin/master //把HEAD指向最新下载的版本
git pull //再拉一遍？？？不知道是否还有这个必要。。。。。。。后续测试