git相关

进入到想要用git管理的project目录下

1.git init

意即该目录会被git监视一切的变动

同时生成一个.git文件夹下面存放了管理该project的一切必要信息

2.git add <filename>，相应的文件会被git跟踪更改

3.git commit -m 'some commit message'

4.merge all changes to git repository将所有git跟踪的信息都归入到git repository

5.总起来看git监视的目录下的文件有下面几种状态

untracked file

changed but not being staged

对以上两种file 进行 git add操作都会将文件变为changed to be commited状态

changed to be commited

7.我们通过git status查看当前目录下，待处理的文件的状态。

8. git remote -v

查看关联的远端仓库

9. github上新建一个全新的库时，在本地执行git push <remote> <branch>的时候，会将本地的所有文件都上传到github.如果远端库不是一个全新的库，那么需要现在本地执行git pull 将远端和本地文件合并，然后再push才会成功，之后本地的增删改在你push的时候也会被同步到github远端仓库。同理，如果这时你又在github web端进行了一些增删改的操作，那么这时你的push请求同样会被远端拒绝。此外，很自然的，不是任何人都可以push，你需要远端仓库所有者的github帐号密码才可以push，但是任何人的pull请求是允许的。

10. git init --bare repos这种远端裸仓库是不能进行普通的git操作的，也就是说你所有的版本控制操作只能在本地完成，你可以在本地完成版本回退后再进行提交，也就是说虽然你不能直接在远端仓库上进行git操作，但你仍然可以进行版本回退

11. 如何删除一个git init后被git跟踪的目录？ 直接删除掉.git文件夹即可，该文件夹默认是隐藏的

12. 用.gitignore忽略的文件夹 后面要加一条斜线 e.g. some/path/  才表示或略some/path/下面的所有文件

13.git HEAD并不指向提交，他只是指向了分支，而分支则指向了某一个更改的节点, master 或者 dev他们既是分支名，同时也是指针名。

14. git rm 用于删除一个文件，并且git commit这样是真正删除一个文件

15.暂存区的概念,应该说所有的commit都是通过暂存区来转到最终的版本库的，git留下了足够的后悔余地，让你可以把更改提交到暂存区，这时如果你又有了新的更改，你可以把文件从暂存区撤回，或者更新暂存区的文件，其实更改完全可以直接提交到版本库，之所以设计一个暂存区就是为版本库不是那么零碎，你的更改确实是作为一个版本提交的，总之是为你的更改留出了足够的余地

如果你把一个文件提交到暂存区之后，这个文件又发生了改动，这时commit时，新发生的改动是不会提交到版本库的，也就是说，版本库并不直接从工作区获取文件，而是从暂存区stage来获取文件。

16.工作区和暂存区对所有的分支都是一样的，github上的都是版本库，没有工作区和暂存区.

17.使用git pull的时候 git 总是试图合并远程和本地的变更，也就是说远程增加的本地也可以增加的，本地增加的行仍然保留，但不会更新远程的分支，除非再次执行git push,这种情况下使得本地的分支仓库总是远程分支的一个超集，或者说远程分支是本地分支的一个子集，这都是在没有confiict的情况下，如果有conflict的话需要先行处理conflict然后才能merge

18.git 的分支实际上就是一条单向的时间线，除非git merge --no-ff -m "merge with no-ff" dev类似这样使用了--no-ff选项，那么这时会新生成一个commit作为merge后的commit。ff=fast forward

19.git revert反转提交，实际上这也是一次提交，这样你之前的一次提交也作为一个版本被保存下来

20.git stash 可以暂存本地工作区，这样pull的时候就不会发生冲突,当调用

git merge --strategy-option theirs 一次性合并多个

git pull -Xtheirs同上

git stash pop stash@{0}的时候，暂存的内容又被释放出来，这时git会提示冲突，并且需要手动修改冲突的部分来确保合并成功wen
对于二进制文件的冲突你可以选择

git pull
git checkout --theirs YOUR_BINARY_FILE or git checkout --theirs .|*批量检出
// git checkout --ours YOUR_BINARY_FILE
git add YOUR_BINARY_FILE
git commit -m 'merged with the remote repos.'
git push
还可以选择 git checkout -f强制合并
21.git reset HEAD file可以把文件重新放回工作区

22.git diff --name-only --diff-filter=U 这会列出所有冲突的文件

23.git merge时候的冲突是指已经commit到仓库的文件的冲突, unstaged以及staged文件都不在此列

24.git diff --cached|staged意思是查看当前staged的文件

25.git pull会影响暂存区和本地仓库,或者说会更新本地仓库(在没有conflict的情况下)

26.git push同样会引起冲突,如果远程的文件发生改动或者因为别的push 造成push冲突

27.git reset HEAD file 从暂存区撤回文件

git checkout -- file 从暂存区或者版本库撤回文件，为什么这么说，因为如果暂存区有相应的文件则优先从暂存区检出，如果没有，那么就从版本库检出，如果一定要从版本库检出，那么先用git reset HEAD file将文件从暂存区撤回，再调用git checkout -- file就可以直接从版本库里检出相应的文件了

28.git 比较

git diff 比较的是工作区和暂存区的差别

git diff --cached 比较的是暂存区和版本库的差别

git diff HEAD 可以查看工作区和版本库的差别

29. revert比reset更加温柔一点，回滚到某次commit且该commit之后的提交记录都会保留，并且会在此基础上新建一个提交

实际实验也是这样git commit 会重置暂存区和工作区

30.git stash可以将工作区藏起来

git stash pop 恢复工作区 ,git stash list git stash clear

git stash 会把暂存区的内容保存起来，未在暂存区中，但已经被更改的文件，在pop的时候会一并放到暂存区中

31.根据试验的结果git rm 的结果是将文件从版本库放回到暂存区 git reset HEAD file

git reset HEAD~1 和 git revert HEAD~1中  HEAD~1的含义是不同的，reset中指的是后退到倒数第二个版本，revert 中指将倒数第二个版本的更改撤销掉

因为git revert会生成新的一次提交，所以有可能会造成冲突 git 保持在reverting 状态,类似于git 的merging状态,需要手动处理冲突之后再行提交

32.git reset --hard和git reset 是不一样的，git reset --hard在进行版本切换的同时会将工作区和暂存区清空，但是--soft会保留暂存区的内容

33.git revert --continue --abort 会终止或者继续当前的合并

34.git merge的时候比较有意思，他默认采取的是fast-forward的方式，如果比较master和dev的分支头部之后，只是dev发生了增加那么合并的时候就直接将master指针指向dev当前的提交，如果使用 git merge --no-ff -m 'sdsd' dev就会产生两个提交，一个是master和dev合并之后的，另一个是当前dev的提交 这样分支的提交信息就会被保留下来。

35.git rebase 假如你对dev分支执行git rebase, 那么这条分支上的所有过往的提交都会被抛弃，并把这些提交的更改暂存起来，然后将他们应用到当前dev 的commit上，这个过程可能产生多个提交，因为前面暂存的那些更改并不是打包在一起的，而是和丢弃掉的commit是一个个对应的

36. git blame 文件逐行追溯

37. git push 的时候默认是不允许往当前工作分支push的，除非这是一个bare repo, 这话同时也意味着你可以往非工作分支push， 比如dev分支, 只要不是当前工作分支即可

38. windows下面有时候需要免密码提交，如果用Totorise当然就没有这些问题了，如果用bash 命令行pull或者push就需要保存rsa密钥对， 具体就是创建一个HOME/.ssh/id_rsa的文件用来保存自己的私钥，并在远程主机上的authorized_key中保存相应的公钥

39. ssh总是区分通信的两端的角色的，也就是说，如果一条通信链路建立，那么一定有一端是客户端，另一端是服务端， known_hosts中保存的密钥指纹是用来做client的时候使用的