GIT 基本语句
提供的练习通道
https://oschina.gitee.io/learn-git-branching/
找建分支，多用分支
Git commit :提交信息
Git Branch : 创建分支 ：git branch newImage 创建一个newImage这个分支且这个分支的指向在创建分支的分支位置上
Git Checkout <name> ：切换分支： gti checkout newImage 在切换分支上之后就会在分支指定的标记点上 ，另一个更简洁的方式：如果你想创建一个新的分支同时向切换到新创建的分支的话，可以通过：git checkout -b <your-branch-name> 实际操作 git checkout -b newImage
git merge <分支> ：首先你得找住master分支中使用这个语句 git merge 分支，是吧分支合并到master分支中，分支合并后会修改代码内容，合并后会出现一个新的提交节点。且两个分支都指向这个节点。 如果分支在一条线上，那么就不会产生新的节点，如果分支在一个位置上会产生新的节点. 是吧<分支 >合并到本线路上
git rebase :第二种合并分支的方法。 Rebase 实际上就市取出一系列的提交记录，”复制“他们，然后在另外一个地方逐个的放下去，Rebase的优势就是可以创造更线性的提交历史，这听上去有些难以理解，如果只允许使用Rebase的话，代码库的提交历史将变的更的更清晰。使用后就如同，就是说你可以把本地分支代码合并你想要合并的代码之后在下边延续，原来的分子不会动。 意思是：把当前节点复制到那个节点上 git rebase 复制到什么节点《写那个节点》，还有如果两个节点都在一条线上，这样合并不会出现新的节点，而是本节点到合并的节点上
git check c1 c2 这种（应该是指向的地址名(哈希值)）之后调用head的走向，说名 head--> mester-->c1
git log 是查看哈希值 ,查看历史
使用^ 向上移动一个提交，实际代码 git checkout 分支^ 但是指向的却是相对引用的哈希地址值
使用~<number>向上提交多个记录 如 ~3
git branch -f master HEAD~3 :直接使用-f 选项让分支指向另一个提交 这个命令将master分支强制指向HEAD的第3级父提交。 HEAD 代表的是哈希值的地址
git 里的撤销分两种 一种是git reset 还有就是git revert
git reset 这个撤销是很方便但是 但是 但是 对打家远程一起使用的分支是无效的！为了撤销更改并分享给别人，我们需要使用给 git revert
git reset HEAD ~number这个方法，记住就好, 必须带有数值要不就不好使
git revert HEAD 这个方法的更改方式是提交的形式，产生一个节点，但是这个节点却和撤销后的节点内容是一样的。记住是一样的，这样推送给别人，就方便很多（设计方案的脑回路真的可以）
以上就是基本语法：够用
以下就是高级语法：解决难题
git cherry-pick 命令形式为：git cherry-pick <提交号> 不揍就如同，分支（master） 复制节点，提交， 就是这样
如果向将一些提交复制到当前所在的位置（HEAD）下面的话 cherry-pick是最直接的方式
git cherry -pick c2 c4 就如同把其余更改的节点 直接合并到当前分支 c2 c4 这是代表hash值的地址值
交互式 rebase 指 的是使用参数 --interactive 的rebase 命令，简写为 -i 相当于复制一样 git rebase -i HEAD~4 就是把往上4个节点在顶节点复制4个一样的节点出来 首先这个是HEAD 相当于分当前节点 是HEAD不是分支，记住：用HEAD和用分支是不一样的效果，主要HEAD和分支的位置得想清楚
git rebase -i 将提交重新排序 就是说当按顺序提交 突然发信以前提交的节点上图片要更改了，之后用这个语句改变节点顺序 记住：首先在什么节点上复制什么节点，其次
你复制到什么节点上 是将本上的往上的所有节点复制到，什么节点上第几个上，，，如:git rebase -i se~2 的意思是把本节点网上的几个节点都复制到se分支的往上两个节点
git commit --amend 重新提交本地的节点 ，修改当时节点，把图片修改正确。
git rebase -i 来将顺序调回原来的顺序 ，修改完事后，把顺序调节回来。
设置标记 git tag 标记 节点地址
git bescribe 由于标签在代码库中起着”锚点“的作用，Git还为此专门设计了一个命令用来描述离你最近的锚点（也就是标签）,他就是git bescribe
Git Describe 能帮你在提交历史中移动了多次以后找到方向，当你用 git bisect (一个查找产生BUG 的提交记录的指令) 找到某个提交记录。会用到这个命令
git describe <ref> <ref>可以时任何能被git识别成提交记录的引用，如果你没有指定的话，git会以你目前所检除的位置（HEAD）。结果就是会根据提交的<ref>分支找到最近的<TAG>标签的值是什么？在那时什么位子
输出结构：
<tag>_<numCommits>_g<hash>
tag 表示 离ref 最近的标签，numCommits 表示这个 ref与tag 相差有多少个提交记录
操作符^于~符一样，后面也可以根一个数值
但是该操作符后面的数字于~ 后面的不同，并不是用来指定向上返回几代，而是指定合并提交记录的某个父提交，还记得前面提到过的一个合并提交有两个父提交把。所以遇到这样的节点时。选择哪条路径就不是很清晰了
git默认选择和斌提交的”第一个“父提交，在操作符^后跟一个数字可以改变这个一默认行为。这个是用分支找节点，感觉不如用哈希地址码（哈哈） ,而且查找行一次性方便但是复杂，如果要是不是一次性的，第二步就会产生一个问题 就不能用分支了，只能用HEAD这个分子地址。
删除分支：分支2
首先切换到别的分支上： git checkout 分支1
在删除分支 git branch -d 分支2
如果删除不聊可以强制删除：git branch -D 分支2
有必要的情况下，删除远程分支（慎用）：git push origin --delete 分支2（没测试过）
复制仓库 git clone
当绑定远程分支的时候，添加新的提交时，远程分支不会动，而是分离了HEAD的状态位置，这是因为0/master只有在远程创库中响应的分支更新了才会更新
git Fetch 就是获取远程仓库的数据 ：如同把远程仓库的内同获取到本地,,但是git fetcch 不会改变master分支，也不会修改磁盘文件，很多人误以为用了git fetch 以后，本地仓库和远程仓库同步了，，他可能已经将行这一操作所需要的所有数据都下载下来，但是并没有修改你本地文件，所以git fetch只是单纯的下载,而且时非常全面的下载。
git pull 下拉到本地仓库：相当于啊 git fetch 下载后，在把下载后的代码合并在一起出现新的节点
(云端的操作不是本地的)git fakeTeamwork 分支 数量 就是远程分支的模拟提交 git fakeTeamwork foo 3 这种就是提交3个节点
git push 变更上传到远程仓库：注意给 git push 不带任何参数时的行为与Git的一个名为Push default 的配置有关，他的默认值取决于你正在使用的GIt的版本，但是在教程中我们使用的时upstream，，在自己的项目中进行推送治安，最好检查下这个配置
git push 会提交不上去，，就时历史问题，例如：你pull下来代码，之后开发新功能，之后同事更改了代码并提交完成，你在提交代码，基本上就GG了
解决方案，就是，
第一步，先下载下来代码并不是pull下来如果pull下来就把把自己的代码全部都覆盖了（这种情况发生过，没整好），先用git fetch 下载
第二步，在本地合并代码显然你时知道的 git rebase <分支> 对吧
第三步，就时push上传代码了，这样就ok了
（没用过） git pull --rebase 是 fetch 和rebase的简写
讨论merge与rebase
优点：
rebase 使你的提交树变得很干净，所有的提交都在一条线上
缺点：
rebase修改了提交树的历史
开发人员喜欢保留提交历史可以用merge （仁者见仁，智者见智）
远程跟踪
直接了当地讲，master 和 o/master 的关联关系就是由分支的“remote tracking”属性决定的。master 被设定为跟踪 o/master —— 这意味着为 master 分支指定了推送的目的地以及拉取后合并的目标。
你可能想知道 master 分支上这个属性是怎么被设定的，你并没有用任何命令指定过这个属性呀！好吧, 当你克隆仓库的时候, Git 就自动帮你把这个属性设置好了。
当你克隆时, Git 会为远程仓库中的每个分支在本地仓库中创建一个远程分支（比如 o/master）。然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为 master。
克隆完成后，你会得到一个本地分支（如果没有这个本地分支的话，你的目录就是“空白”的），但是可以查看远程仓库中所有的分支（如果你好奇心很强的话）。这样做对于本地仓库和远程仓库来说，都是最佳选择。
这也解释了为什么会在克隆的时候会看到下面的输出：
local branch "master" set to track remote branch "o/master"
我能自己指定这个属性吗？
当然可以啦！你可以让任意分支跟踪 o/master, 然后该分支会像 master 分支一样得到隐含的 push 目的地以及 merge 的目标。 这意味着你可以在分支 totallyNotMaster 上执行 git push，将工作推送到远程仓库的 master 分支上。
有两种方法设置这个属性，第一种就是通过远程分支检出一个新的分支，执行:
git checkout -b totallyNotMaster o/master
就可以创建一个名为 totallyNotMaster 的分支，它跟踪远程分支 o/master。
第一种方法：git checkout -b <要创建的跟踪分支> <远端分支> 不管使提交还是下在 跟中分支都会跟随他们，这样主分支就不会在动（意思使这个而已）
第二种方法 另一种设置远程跟踪分支的方法就使 git branch -u 命令 执行为： git branch -u o/master foo o/master:云上主分支，foo分支，如果就在foo分支上就可以省略foo；
git push <remote> <place> place :分支 例子 git push origin master 就是说切换本地长裤中的master分支，获取所有提交，在到远程仓库origin中找到master分支，将远程仓库中没有的提交记录添加上去，实际上要同步两个仓库的位置，（上传远程仓库的时候HEAD必须在某一个分支当中，只有分子才能上传：猜想） 这个remote他不是分支，他使仓库
ORIGIN 仓库
git push <remote> source:分支 source 使位置，分支使说这个分支放到的位置上 如果分支不存在，git帮你创建一个分支
git fetch origin foo git 会到远程长裤的foo分支上，然后获取本地不存在的提交，放到本地o/foo上
git fetch <仓库> <source>:<destination> 例如：给git fetch origin foo~1:bar 的意识就使说，下载origin 云上的foo分支的上一个节点为止的所有分支，之后把bar分支标记在本地的节点上。
git push origin <空值>：foo 会删除远程仓库的分支 (云端)例子：git push orgin :foo
git fetch origin <空值>：bar 会在本地建立一个（本地）分支bar 云端没有注意
git等效命令：
git pull origin foo：相当于 git fetch origin foo; git merg o/foo
git pull origin bar~1:bugFix 相当于：
git fetch origin bar~1:bugFix; git merge bugFix
git pull 实际上就是 fetch + merge 的缩写, git pull 唯一关注的是提交最终合并到哪里（也就是为 git fetch 所提供的 destination 参数）
显然：git pull <仓库> <><> 和 git fetch <仓库> <><> 一样，但是多一样merge合并
