版本控制commit和update覆盖问题分析
一、理论分析
很早就使用了git、后来还管了一个VSS,但长时间以来git和VSS基本都当ftp使用,顶多知道其有回退旧版本的功能,但对“版本控制”这个词一直以来都没领会其内含。
比如我一直担心两个问题,一是拉取下来后修改文件如果再次拉取已修改文件是否会被覆盖,二是两人拉取后对同一文件分别进行修改和提交那后提交的那个会不会覆盖前面提交的那个。
针对这两个问题,专门建了个仓库进行测试,汇总如下表。
本地文件与远程文件同一版本 (自拉取后本地未修改、远程未修改) |
本地文件落后远程文件X个版本 (自拉取后本地未修改、远程已修改) |
本地文件领先选程文件X个版本 (自拉取后本地已修改、远程未修改) |
本地文件和远程文件互相领先X个版本 (自拉取后本地已修改、远程已修改) |
|
commit | 不操作 | 不操作 | 本地代码提交到远程 | commit失败。提示本地不是最新版本需要update |
update | 不操作 | 远程代码同步到本地 | 不操作 | update成功。但报冲突、冲突处理前无法commit |
总之就是commit和update,谁版本领先就以谁为准;如果互有领先,那就是存在冲突,需要进行冲突处理。
二、冲突处理操作
使用Beyond Compare等处理冲突时,会打开四个窗口。
左上窗口代表合并过来的分支的代码,中上窗口代表两个分支最后一个共同祖先的代码,右上窗口代表当前分支的代码;下边窗口代表处理当前冲突后的文件的代码。