git相关学习笔记 1
事先声明，鼠鼠理解不深，边学边理解边记的
建一个git仓库和简单操作
-
对于已有项目文件，使用git init进行初始化
-
对于新建一个项目 给git init xxx,再cd进入
-
对于新加入的文件，使用git add xxx文件 ， 该命令可将该文件的修改添加到暂存区。如果不是新的文件，使用该命令的意思是的修改应该包含在下一次提交（commit）中。
-
git status查看当前状态
-
git commit -m"xxx" 进行提交。当然如果不想写message信息，使用
git commit --allow-empty-message -m ''就可以不在里面填信息了
-
除此外，还有 git commit -am ，其中的-a参数代表着修改文件后不需要执行 git add 命令，直接来提交。git add命令来跟踪新文件，但如果使用git commit -am可以省略使用git add命令将已跟踪文件放到暂存区的功能
-
git中既然添加是git add xx,删除就是git rm xx,如果是要重命名/移动，就是git mv了（实现与mv相同的重命名操作，可以先rm再add新的，效果是一样的）
-
git log 进行版本演变历史的展示 ，git log --all,(效果不好，一坨玩意)
图形化 git log --all --graph（可以比较清晰看到版本演替和历程）
简洁显示 git log --oneline(简介)
只显示最近x条 git log --nx
-
查看当前环境下的用户名 git config --local user.name
-
更改当前环境下的用户名 git config --local user.name 'xx'
-
git checkout切换分支，使用后进入分离头指针的状态。视下文
-
git checkout -b <new> <分支/ commit>用于生成新的分支 -
查看分支列表 $ git branch -av
-
删除分支git branch -d /D <名字>
-
变更/修改最近一次提交的消息 git commit --amend
-
git rebase，实现变基操作
-
git diff 命令比较文件的不同，即比较文件在暂存区和工作区的差异。
- 尚未缓存的改动：git diff
- 查看已缓存的改动： git diff --cached
- 查看已缓存的与未缓存的所有改动：git diff HEAD
- 显示摘要而非整个 diff：git diff --stat
- git reset HEAD 取消暂存区的所有文件，运行完这个指令你再试试运行git diff --cached，进行一个暂存区（已缓存的）与工作区的对比，此时发现已经便会工作区的了
- 如果你工作区里的内容搞砸了，或者是出现了某些怪的改动，找不出来，或者是太烂了想复原会暂存区的内容，使用git checkout --xxxx.xxx（暂存区里的某个文件）
- 设置代理（为什么懂得懂得）：git config --global http.proxy http://127.0.0.1:7890
git目录中的文件详情
首先cd .git进入文件目录后，或者 windows直接点进去可以很多的内容，这里进行简要的了解
-
其中config文件存放配置信息
-
ref文件夹中包括heads和tags ,tags标签又有种说法叫里程碑，heads为分支 。不同分支间运行互不影响，最后可以合并。进入heads文件夹，可以看到master和temp缓存，mater文件内部存在一个哈希值，相当于一个指针，指向某个commit，temp中的哈希指向暂存的版本
-
git文件夹中的objects文件夹中，有多字符的文件（2字符）和pack，pack中打包了松散的文件，2字符文件夹的名字和里面文件的名字拼接起来构成了一个40位的哈希值，git cat-file一下，获得一个tree类型，其对应的是一个文件树，对应着一个文件和该文件的哈希。该文件是个blob二进制对象。
使用git输入指令 git cat-file -t加上该文件的哈希值 就能看到其中对应的内容了 。
在git的设计中，任何两个完全相同的文件，视为同一个blob
鼠鼠我已经晕头转向了，又吃了不懂开发的亏，不如在座的各位实习科研项目全栈算法设计模式保研爷
commit tree blob三者关系
commit->tree=>blob
- 每一次使用git commit都会创建一个commit对象，对应着一棵树，树相当于一个快照，记录该时间点的文件信息和状态，树里也可以有树，子树对应的是子文件夹
分离头指针
git checkout后取出进入分离头指针状态，如果在此情况下进行修改后没有把它挂载到某个branch上，再切之后就会被当成垃圾清理掉，（悲
git checkout 并修改后和某个分支挂钩后就不会被清除了，使用git branch <新分支名字>
git rebase
当执行rebase操作时，git会从两个分支的共同祖先开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面。
rebase，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B。而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交先暂存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（接上去是逐个和新基底处理冲突的过程），如此feature分支的基底就相当于变成了M而不是原来的B了。（注意，如果master上在B以后没有新提交，那么就还是用原来的B作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）
HEAD 与MASTER与分支
在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支”。在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支”
- 分支：
- 我们可以把分支看作 是一条线段， 上面刻画有每次事件发生时的时间标记。
- git可以有很多分支。 不仅包括master分支，而且还可以包括任何你想要的分支 。
- 以树比喻， 可以把master看作是本地的必须存在的主干或者主分支，其他分支可以看作是master的分支或者分枝， 但其他分支最终都会合并至master分支
- 当前分支：
- 任何时候 ，HEAD所指向的分支就是当前分支。
- 在无任何新建分支情况下，也就是只有master分支，HEAD所指向的分支就是当前分支master。
- 在新建分支New_Branch并指向后，HEAD所指向的分支就是当前分支New_Branch。
- 分支变化：
- 执行git commit命令 ， HEAD指向当前分支（不一定是master分支）最近一次提交commit后的时间标记点
- 执行git reset命令 ， HEAD指向reset命令后的事件的时间标记点
- git commit命令，可以更改（准确地说，是通过添加新的时间标记点来增长）当前分支线，同时使HEAD指向当前分支线上最新的时间标记点
- git reset命令 ， 可以使HEAD重新指向当前分支线上的某个时间标记点，同时更改（ 准确地说，是缩短或者回退）当前分支线， 并同时更新工作区内容为相应的版本
