git

about git

git add 添加内容到下一次提交中

要养成一开始就设置好.gitignore的习惯。

git diff将通过文件补丁的格式显示具体哪些发生了改变。

提交时记录的是放在暂存区的快照,任何还未暂存的仍然保持已修改状态。

跳过使用暂存区

使用暂存区域可以更加精心的准备要提交的数据。

git commit -a 可以跳过暂存的步骤直接提交

在git中任何已提交的东西几乎总是可以恢复的,但是任何未被提交的东西丢失后

很可能再也找不到了。

git remote  列出你指定的每一个远程仓库服务器的简写

如果你已经克隆了自己的远程仓库,那么至少可以看到origin—这是
git给你克隆的仓库服务器的默认名字。

如果要查看哪些分支已经合并到当前分支

git branch --merged

列表中分支名字前没有*号的分支通常可以用git branch -d 删除掉;你已经将它们的工作整合到另一个分支上,所以并不会失去任何东西。

查看所有包含未合并工作的分支

git branch --no-merged

因为它包含了还未合并的工作,当尝试git branch -d 命令删除它时会失败。

如果真的想要删除分支并丢掉那些工作,可以通过-D选项强制删除它。

分支开发工作流

只在master分支上保留完全稳定的代码。
稳定分支的指针总是在提交历史中落后一大截,而前沿分支的指针往往比较靠前。

变基

在git中整合来自不同分支的修改主要有两种方法:merge和rebase.

merge 会把两个分支的最新快照c3, c4,以及二者最近的共同祖先c2进行三方合并,合并的结果是生成一个新的快照并提交。

其实还有另一种方法:你可以提取在c4中引入的补丁和修改,然后在c3的基础上应用一次。

在git中这种操作就就做变基,你可以使用rebase命令将提交到某一分支上的所有修改都

移至另一个分支上,这就好像“重新播放”一样。

它的原理是首先找到这两个分支(当前test分支,以及变基操作的目标基底分支master)的最近的共同祖先c2,然后对比当前分支相对于改祖先分支的历次提交,提取相应的修改作为临时文件,然后将当前分支指向目标基底c3,最后以此将之前另存为临时文件的修改依次应用。

这两种整合方法的最终结果没有任何区别,但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现,尽管实际的开发工作是并行的,但它们看上去就像是串行的一样,提交历史是一条直线没有分叉。

一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁。

变基是将一系列提交按照原有次序应用到另一个分支上,而合并是把所有最终结果合在一起。

不要对在在你的仓库外有副本的分支执行变基。

如果你遵循这条金科玉律,就不会出差错,否则,人民群众会仇恨你,你的朋友和家人也会嘲笑你,唾弃你。

变基的操作实质上是丢弃一些现有的提交,然后相应的新创建一些内容一样,但是实际上不同

的提交。

用变基解决变基。

服务器上的git协议

git 支持四种主要的协议来传输资料: 本地协议 local

http协议

ssh协议

git协议

自定义git -配置git

git 钩子

git 在特定的重要动作发生时触发自定义的脚本。有两组钩子: 客户端的和服务器端的。客户端钩子由提交/合并这些操作所调用,而服务端钩子作用与诸如接受被推送的提交这样的联网操作。

安装一个钩子

钩子都被存储在git中目录的hooks字目录中。

post-commit钩子在整个提交过程完成之后运行,它不接受任何参数,但是你可以很容易地通过运行git log -l HEAD来获得最后一次的提交信息。

git rev-list获取推送到服务器的所有提交。

内部原理

从根本上讲git是一个内容寻址文件系统,并在此基础之上提供了一个版本控制系统的用户界面。

git 打包对象时,会查找命名及大小相近的文件,并只保存文件不同版本之间的差异内容。

git 时常会自动对仓库进行重新打包以节省空间。当然你也可以随时手动执行git gc命令来这么做。

git gc –auto

这个命令通常并不会产生效果,大约需要7000个以上的松散对象或者50个的包文件才能让git启动一次真正的gc命令。

git 有很多很棒的功能,但是其中有一个特性会导致问题,git clone会下载整个项目的历史,包括每一个文件的每一个版本,如果某个人在之前向项目添加了一个大小特别大的文件,即使你将这个文件从项目中删除了,每次克隆还是要强制的下载这个大文件,之所以会出现这个问题,是因为这个文件在历史中是存在的,他会永远在那里。

世界上的事哪有什么对与错,我只想守护我想守护的人而已