Git是一个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种项目。
Git易于学习，占地面积小，性能极快。它具有廉价的本地库（在本地磁盘上），方便的暂存区域和多个工作流分支等特性。其性能优于Subversion、CVS、Perforce和ClearCase等版本控制工具。
版本控制介绍
版本控制是一种记录文件内容变化，以便将来查阅特定版本修订情况的系统。
版本控制其实最重要的是可以记录文件修改历史记录，从而让用户能够查看历史版本，方便版本切换。
Q：为什么需要版本控制？
A：个人开发过渡到团队协作。
版本控制工具
集中式版本控制工具
CVS、SVN(Subversion)、VSS…
集中化的版本控制系统，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。
这种做法带来了许多好处，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统，要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。这么做显而易见的缺点是中央服务器的单点故障。如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。
分布式版本控制工具
Git、Mercurial、Bazaar、Darcs…
分布式的版本控制系统，客户端提取的不是最新版本的文件快照，而是把代码仓库完整地镜像下来（本地库）。这样任何一处协同工作用的文件发生故障，事后都可以用其它客户端的本地仓库恢复。因为每个客户端的每一次文件提取操作，实际上都是一次对整个文件仓库的完整备份。
分布式的版本控制系统出现之后，解决了集中式版本控制系统的缺陷：
- 服务器断网的情况下也可以进行开发（因为版本控制是在本地进行的）
- 每个客户端保存的也都是整个完整的项目（包含历史记录，更加安全）
Git工作机制
工作区（写代码） ––> 暂存区（临时存储） ––> 本地库（历史版本） ––> 远程库
工作区和暂存区的东西是可以删除的，但是一旦提交本地库生成历史版本后，该版本将无法被单独删除（除非删除整个库重新开始）。
Git和代码托管中心
代码托管中心是基于网络服务器的远程代码仓库，一般简称为远程库。
局域网：
- GitLab
互联网：
- GitHub（外网）
- Gitee码云（国内网站）
设置用户签名
- => 设置用户名
- => 设置邮箱
说明：签名的作用是用来区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到，以此确认本次提交是谁做的。Git首次安装必须设置一下用户签名，否则无法提交代码。
注意： 这里设置的用户签名和将来登录GitHub（或其它代码托管中心）的账号没有任何关系。
初始化本地库
查看本地库状态
=> 查看状态
键入命令回车后将会显示三块内容：
- 当前所处的分支
- 目前是否有提交的内容（本地库没有版本信息）
- 目前是否有需要提交的内容（工作区、暂存区相关）
此时，新建文件后再次执行命令，第三块内容将提示该文件未被追踪（仅仅存在于工作区），并且提醒你让你使用命令让该文件被追踪（添加暂存区）。
添加暂存区
=> 将当前目录下的文件添加到暂存区
=> 将当前目录下的所有（未被追踪的）文件都添加到暂存区
此时，再次执行查看本地库状态的命令，第三块内容将提示Git已经追踪到了该文件（暂存区），并且提醒你如果你需要移出暂存区，可以使用
注意： 这条删除命令只是移出暂存区，该文件依旧保存在工作区
这个时候，继续查看本地库状态，相关提示将会与上一小节一致。
为了与下一小节内容接壤，请重新将移出暂存区的文件添加进去。
提交本地库
成功后可以从输出信息中得知一个7位的字符码，也就是该历史版本的版本号。
此时，执行查看本地库状态的命令会得到两块内容：
- 当前所处的分支
- 当前工作树是干净的（没有需要再次提交的东西）
=> 查看简略版本信息
=> 查看详细版本信息（不止7位的完整版本号）
修改文件
修改文件后查看状态，会得到两块内容：
- 当前所处的分支
- 当前有需要提交的内容（工作区、暂存区相关）
不难发现，相较于最初的三块内容，这里少了一块，因为本地库已经有了版本信息。
此时，可以通过来重复前几节内容，并且可以在途中查看本地库状态来加深理解。
最后，查看版本信息，会发现有两条历史版本的记录，指针指向最新提交的记录。
穿梭历史版本
=> 找到想要穿梭的版本的版本号复制
=> 穿梭历史版本
此时会自动添加一条穿梭版本的记录，同时指针指向了指定的版本，这一点可以通过查看当前目录下的文件的内容进行核对确认。
什么是分支
在版本控制过程中，同时推进多个任务，可以为每个任务创建每个任务独立的分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开，开发自己分支的时候，不会影响主线分支的运行。
对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本。（分支底层其实也是指针的引用）
分支的好处
并行推进多个功能开发，提高开发效率。
各个分支在开发过程中，如果某一个分支开发失败，不会对其它分支有任何影响。失败的分支删除重新开始即可。
分支的操作
查看分支
创建分支
=> 创建分支
切换分支
=> 切换分支
修改分支
在新分支下修改文件，添加暂存区并且提交本地库。
正常合并分支
切换回原分支，查看文件，发现内容复原了。（因为原分支并没有被修改）
=> 将指定分支合并到当前分支
再次查看文件内容，发现被修改成了新分支下变化后的内容。
冲突合并分支
在两个分支分别修改文件内容，刻意制造冲突（比如同一个文件同一个位置都有变化），记得都得在各自分支上添加暂存区并提交本地库。
尝试用上一小节的命令合并，报错有冲突，并且会注明是哪个文件有冲突。此时打开文件，会发现冲突位置有类似如下符号：
其中，与之间为当前分支内容，与之间为将要合并过来的分支的内容。
修改冲突也很简单，只需要删除不想要的，保留想要的，当然，特殊符号也需要删除，例如：
保存文件后，将该文件添加暂存区，然后提交本地库。
注意： 这里提交本地库的时候不能写文件名，因为当前处于状态，需要对合并过来的内容一并操作而不只是解决冲突的文件。同时，合并成功后只针对当前分支，另一个分支的内容不会被修改。其本质是指针指向切换。
团队内协作
员工1和员工2都拥有代码托管中心中某一个远程库的权限（视为在同一个团队），他们可以分别将这一个远程库到自己的本地库。
在各自的本地库，员工1和员工2分别开发新的功能，任何一方将自己的功能完善之后就可以到远程库。
此时，另一方就可以通过将代码拉取到本地，使自己的本地库与远程库的版本同步。反之同理。
通过这一系列循环往复地操作，员工1和员工2开发的功能都将存储在同一个远程库中。
跨团队协作
书接上回，一个开源项目爱好者发现了这个远程库中存在一个bug，但是，他没有这个库的权限（与员工1员工2不在一个团队），即使修改了bug也没办法直接操作这个远程库存储的内容。
于是，他先将这个远程库出一份新的远程库，而他拥有这个新远程库的权限。
所以，这位开源项目爱好者通过将新的远程库下载到本地，修改完bug之后回去。
这个时候，在这个新的远程库向员工1员工2所在的团队的远程库创建一个，简称为。之后，那个团队的负责人就可以看到这个申请，如果他审核完觉得这个开源项目爱好者改得好，就可以将他提的合并进团队的远程库中。
到此这篇git服务器端（git服务器默认端口）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-yjs/21464.html