覆盖场景的模拟
准备环境
<!--[endif]-->
这里有2个本地库,模拟2个人(user1/user2)协助开发
并分别导入IDE中
<!--[endif]-->
2个文件的初始化内容
<!--[endif]-->
user1对2个文件进行编辑提交(push)
<!--[endif]-->
<!--[endif]-->
<!--[endif]-->
此时user1已经修改了2个文件并push到远程库
user2对其中一个文件(a.txt)进行修改
此时user2并不知道user1的提交,他只是在埋头干自己的活。活干完了准备提交了。
修改文件a.txt
<!--[endif]-->
准备提交前首先更新
<!--[endif]-->
发现有冲突
<!--[endif]-->
此时发现该情况,我们目前的做法是:
发现有冲突,首先commit到本地库,从而进行合并
<!--[endif]-->
<!--[endif]-->
此时我们再次进行pull动作
<!--[endif]-->
<!--[endif]-->
发现有一个文件冲突
<!--[endif]-->
解决冲突文件
<!--[endif]-->
把冲突文件add index
<!--[endif]-->
仅选择自己修改的文件进行提交(问题出在这里!!)
<!--[endif]-->
只选择a.txt进行提交,感觉没啥问题,其实问题就处在这里!!
user1更新后发现自己修改的文件被还原了!
<!--[endif]-->
为什么会覆盖
要明白需要了解GIT的工作原理,可能有点深,这里大概说下。
git的版本管理不想svn通过一个版本号递增的形式来维护版本的前后顺序。
git通过版本号通过md5码进行编号,没有顺序,git是通过对象链来维护版本的。
为什么这么设计,这个分布式有关系。
此时在user2 pull时,实际上有merge合并的动作,此时合并有3中情况。
1中发现本地没有commit,直接把远程库的修改合并到本地库中(从日志的角度看本地库没有任何修改)
2: 发现本地库已经有commit了,此时merge把远程库的内容合并到本地库最后的commit中,并做一次提交,此时改commit有2个parent(一个远程库最后的commit、一个本地库最后的commit)。
3:当发现本地库已经有commit了,此时merge时,有发现有冲突,这时合并动作终止。
仅仅把远程库的内容合并到了本地库的工作区中,此时本地库的b.txt还是旧的。所以这个时候还需要手工的进行commit(必须包含b.txt文件,可能这个有点打破svn的使用习惯,该文件并不是我修改的呀?)
如果防止覆盖
正确的解决冲突(保持目前操作)
如果发现冲突,解决完冲突后必须把所有变更全部commit,不能够挑选
为什么要commit自己并没有修改的文件?
因为从远程库中合并的这些内容(b.txt),相对于你本地库的最新commit(最终要push到远程库的)确实算修改了,但相对于远程库的最新commit却没有修改。所有我们合并后的commit会有2个parent commit。
冲突后本地库保持与远程库版本一致(保持目前操作)
如果不想提交我们未修改的文件内容,可以重置下我们的本地库与远程库保持一致。
git reset origin/master (--hard 这个千万不要加)
可视化操作
<!--[endif]-->
采用stash(建议命令行中使用)
在user2编辑完文件后,在pull更新代码的时候如果有冲突,不要把本地的修改
进行commit,而是stash暂存起来,在此pull,然后在还原之前的修改。
这样就避免过多的commit及merge。从逻辑的角度更直观些。
介于该方式会导致文件内容频繁修改,IDE频繁编译效率问题,建议业务人员使用前2种方式。
总结
首先要承认GIT 从功能的角度强与SVN,就看你能否驾驭得了,
感觉像个宝藏需要你慢慢挖掘。
我们之前用的很不顺有很大的原因:拿SVN的经验在使用GIT(这样会搞死你!
),并没有花时间去学习GIT。
当然GIT的概念比较多,要搞清楚弄明白其原理!否则出点问题你就乱了!
相关推荐
### Git使用教程核心知识点 #### 一、Git简介与应用场景 **Git** 是一款开源的分布式版本控制系统,用于跟踪在软件开发过程中对文件所做的更改。它最初由Linus Torvalds于2005年创建,目的是为了更高效地管理Linux...
2. **仓库权限(Repository Permissions)**:每个Git仓库都有自己的权限设置,允许管理员为特定用户或用户组赋予对仓库的不同操作权限。这些权限包括读取、写入(推送)、克隆、管理等。 3. **用户权限(User ...
解释了Git为代表的分布式版本控制系统的概念,每个克隆不仅包含项目的所有文件和完整的历史版本,还包括完整的版本库。 **1.2 Git的历史** 简述了Git的起源和发展历程,包括Linus Torvalds创建Git的背景及其成为...
小乌龟的图标覆盖系统是其特色,它会在文件和文件夹上显示状态图标,以表明它们在Git仓库中的状态。 在安装这两个工具时,首先应安装Git,因为它为小乌龟提供了基础环境。在安装Git时,记得选择“Add Git to PATH”...
Git是世界上最流行的分布式版本控制系统,广泛应用于软件开发和项目协作中。Git-2.18.0-64-bit是Git的一个稳定版本,专为64位操作系统设计,提供了高效、可靠的版本控制功能。这个安装包包含了Git的核心功能,允许...
- `HEAD <文件>`: 使用当前分支的HEAD版本覆盖工作区中的文件; - `--patch <文件>`: 交互式检查文件的差异,并决定哪些部分要检出; - `--track <远程分支名>`: 创建并跟踪远程分支; - `--file <文件>`: 使用...
### Git Extensions:提升Windows下Git使用体验的工具包 #### 概述 Git Extensions是一款针对Windows用户设计的增强型Git工具包,旨在提供更直观、更便捷的Git使用体验。该工具不仅支持基本的Git功能,还提供了...
- 安装完成后,在开始菜单中找到“Git Bash”,运行后输入`git --version`命令查看版本信息。 #### 四、Git基本操作 ##### 1. 创建版本库 - **概念**: 版本库是一个包含项目文件及其版本历史的特殊目录。 - **...
- `-c <name>=<value>`:此选项用于传递配置参数到Git命令中,覆盖配置文件中的值。 - `git <command> []`:这是Git的基本命令格式,其中`<command>`代表具体的Git操作,如`init`、`commit`、`push`等,而`<args>`为...
一个 Git 仓库是一组文件的集合,包括一个隐藏目录 `.git`,其中存储了所有关于项目历史和配置信息的数据。Git 通过快照而非差异来管理数据,每一次提交都会创建一个包含项目文件的快照,并用 SHA-1 哈希函数来为...
这已更新为使用更现代和 人类可读的输出仍然很简洁。 *“git rebase --rebase-merges”取代旧的“--preserve-merges” 选项; 后者现在标记为已弃用。 *使用--recurse-submodules进行克隆时给出的错误消息 已...
Git 迁移脚本通常用于将项目从一个Git仓库迁移到另一个Git仓库,可能是为了迁移代码托管平台,或者为了重组项目结构。在IT行业中,这种操作可能会遇到多种情况,如团队协作环境的变化、代码库的合并或拆分,或者是...
Git是一款强大的分布式版本控制系统,广泛应用于软件开发和项目管理中,它允许用户追踪代码的修改历史,协同工作,并实现版本的回溯。TortoiseGit是Git的一个图形化界面工具,专为Windows用户设计,使得在Windows...
安装过程中,确保选择正确的Git安装路径,这样TortoiseGit才能正确关联和使用Git。 TortoiseGit的汉化工具对于非英语使用者来说是个福音,它使得软件的菜单、提示和帮助文档都能显示为中文。通常,你可以找到汉化包...
*“git fetch”从一组遥控器中获取学会运行的 auto-gc只在最后一次。 *少数Windows构建补丁已经被上流。 *用于读取序列器机器使用的状态文件的代码 对于腐败或陈旧,“git status”已变得更加强大 州档案。 ...
当Maven与TestNG结合使用时,可以在Jenkins构建过程中运行测试,并将结果输出为XML格式。这为生成详细的测试报告铺平了道路。 4. **HTML报表插件**: HTML报表插件可以将测试结果、代码覆盖率和其他分析数据转换为...
Git是一种分布式版本控制系统,它通过特定的机制实现对代码的版本管理。这些机制主要体现在版本库本地化、快照保存、基于...通过这些机制,Git为现代软件开发提供了强大的版本控制工具,极大地促进了开发者的生产力。
`git push`还有一些特殊用法,比如使用`-u`选项指定默认主机,`--all`选项推送所有分支,以及`--force`选项强制推送,但需谨慎使用,因为`--force`可能会覆盖远程仓库的最新更改。 `git pull`则是将远程仓库的更改...