[Todo] Git & 版本控制学习

Posted 2020-08-14 笨鸟居士的博客

下面这篇写的非常好。git分支介绍，有图。好好看这一篇，就懂了：

http://www.open-open.com/lib/view/open1328069889514.html

该系列还有不少文章，在页面下面的列表里，有时间可以看看（Todo）。

 

 下面是一些笔记：

通过此语法，你可以把本地分支推送到某个命名不同的远程分支：若想把远程分支叫作awesomebranch，
可以用 git push origin serverfix:awesomebranch 来推送数据 （本地serverfix，远程awesomebranch）。

比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，
根据最新的origin/master 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作
（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），
（主干维护者）只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。

呃，奇妙的衍合也并非完美无缺，要用它得遵守一条准则：
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。

在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。如果你把原来分支中的提交对象发布出去，
并且其他人更新下载后在其基础上开展工作，而稍后你又用git rebase 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，
你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。

如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。
如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。

下面是一些从文中摘录出的能够帮助理解的图：

 

几个注意点：

1. 修改了文件的时候，必须要 git add，不add的话commit提交的文件就不对。git add 和 git stage是一个意思，是把文件提交到中间的stage区（注：git文件有三个区：working, stage, repository）.

可以用 git diff --cached 或 git diff --staged 来查看stage中的文件diff，两个命令同一个意思。

 

2. 这篇文章讲了比较详细的和远程repository冲突的问题。

http://www.cnblogs.com/cj2014/p/5557654.html

当没有对本地进行 git fetch 或 git pull的时候（git pull = git fetch + merge to local，而git fetch指的是同步到本地repository，而不是working directory），如果远端有改动，本地也有改动，就会发生冲突，就要进行冲突解决。

一般来讲，都是需要人为解决的。

解决的方法就是 git pull, add, commit, mergetool等命令的组合。

1). git pull: 提示冲突

    2). 提交(git add --all; git commit)

    3). git pull

    4). git mergetool

    5). git pull
    6). git commit 
         [216-fixed-area-walk d228a46] Merge branch \'216-fixed-area-walk\' of 192.168.1.51:IGV/IGV01-SW into 216-fixed-area-walk

    7). git add --all
    8). git commit
    9). git push origin 216-fixed-area-walk

 

再复习一下普通的提交到远端的方式（注意不要忘了git add）

1. git pull

2. git add --all

3. git commit

4. git push origin 216-fixed-area-walk

 

下面这篇文章写的不错：

http://blog.csdn.net/kesenhoo/article/details/7654351

分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，诸如Git，Mercurial，Bazaar 还有 Darcs 等，
客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。

文章列表在这里：

http://blog.csdn.net/kesenhoo/article/category/1165624

 

git分支的介绍(但是图不清楚)，其实复制了第一篇文章，可以忽略：

http://blog.csdn.net/wh_19910525/article/details/7470964

里面提到：Git 又是如何创建一个新的分支的呢？答案很简单，创建一个新的分支指针。

在 Git 中，它是一个指向你正在工作中的本地分支的指针（译注：将 HEAD 想象为当前分支的别名。）。

 

关于fast-forward, no-ff, squash等的解释，下面写的不错

http://blog.csdn.net/chen930724/article/details/50174657

fast-forward方式就是当条件允许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，不过这种情况如果删除分支，则会丢失分支信息。
因为在这个过程中没有创建commit

squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，
于是使用--squash进行合并，此时文件已经同合并后一样了，但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。

--no-ff指的是强行关闭fast-forward方式。