Git基础

  • Nigdle
  • 更新于 2024-11-08 22:13
  • 阅读 290

Git基础!

Git

Git概述

Git是一个免费的、开源的分布式版本控制系统,可以快速高效地处理从小型到大型的各种项目。

Git易于学习,占地面积小,性能极快。它具有廉价的本地库(在本地磁盘上),方便的暂存区域和多个工作流分支等特性。其性能优于Subversion、CVS、Perforce和ClearCase等版本控制工具。

版本控制介绍

版本控制是一种记录文件内容变化,以便将来查阅特定版本修订情况的系统。

版本控制其实最重要的是可以记录文件修改历史记录,从而让用户能够查看历史版本,方便版本切换。

Q:为什么需要版本控制?

A:个人开发过渡到团队协作。

版本控制工具

集中式版本控制工具

CVS、SVN(Subversion)、VSS......

集中化的版本控制系统,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法。

这种做法带来了许多好处,每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限,并且管理一个集中化的版本控制系统,要远比在各个客户端上维护本地数据库来得轻松容易。

事分两面,有好有坏。这么做显而易见的缺点是中央服务器的单点故障。如果服务器宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。

分布式版本控制工具

Git、Mercurial、Bazaar、Darcs......

分布式的版本控制系统,客户端提取的不是最新版本的文件快照,而是把代码仓库完整地镜像下来(本地库)。这样任何一处协同工作用的文件发生故障,事后都可以用其它客户端的本地仓库恢复。因为每个客户端的每一次文件提取操作,实际上都是一次对整个文件仓库的完整备份。

分布式的版本控制系统出现之后,解决了集中式版本控制系统的缺陷:

  1. 服务器断网的情况下也可以进行开发(因为版本控制是在本地进行的)
  2. 每个客户端保存的也都是整个完整的项目(包含历史记录,更加安全)

Git工作机制

工作区(写代码) --git add--> 暂存区(临时存储) --git commit--> 本地库(历史版本) --git push--> 远程库

工作区和暂存区的东西是可以删除的,但是一旦提交本地库生成历史版本后,该版本将无法被单独删除(除非删除整个库重新开始)。

Git和代码托管中心

代码托管中心是基于网络服务器的远程代码仓库,一般简称为远程库

局域网:

  • GitLab

互联网:

  • GitHub(外网)
  • Gitee码云(国内网站)

Git常用命令

设置用户签名

  • git config --global user.name <用户名> => 设置用户名
  • git config --global user.email <邮箱> => 设置邮箱

说明:签名的作用是用来区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到,以此确认本次提交是谁做的。Git首次安装必须设置一下用户签名,否则无法提交代码

注意: 这里设置的用户签名和将来登录GitHub(或其它代码托管中心)的账号没有任何关系。

初始化本地库

git init => 让Git获取目录的管理权<br>它会在当前目录下初始化一个隐藏文件.git

查看本地库状态

git status => 查看状态

键入命令回车后将会显示三块内容:

  1. 当前所处的分支
  2. 目前是否有提交的内容(本地库没有版本信息)
  3. 目前是否有需要提交的内容(工作区、暂存区相关)

此时,新建文件后再次执行命令,第三块内容将提示该文件未被追踪(仅仅存在于工作区),并且提醒你让你使用git add命令让该文件被追踪(添加暂存区)。

添加暂存区

git add &lt;file_name> => 将当前目录下的文件添加到暂存区

git add . => 将当前目录下的所有(未被追踪的)文件都添加到暂存区

此时,再次执行查看本地库状态的命令,第三块内容将提示Git已经追踪到了该文件(暂存区),并且提醒你如果你需要移出暂存区,可以使用git rm --cached &lt;file_name><br>注意: 这条删除命令只是移出暂存区,该文件依旧保存在工作区<br>这个时候,继续查看本地库状态,相关提示将会与上一小节一致。

为了与下一小节内容接壤,请重新将移出暂存区的文件添加进去。

提交本地库

git commit -m "日志信息" &lt;file_name> => 将暂存区的文件提交到本地库,并且附上对应的日志信息<br>如果没有用-m参数注明日志信息,后续依旧会提示你本次提交需要日志信息;如果不指定文件名,将提交暂存区的所有文件。

成功后可以从输出信息中得知一个7位的字符码,也就是该历史版本的版本号。

此时,执行查看本地库状态的命令会得到两块内容:

  1. 当前所处的分支
  2. 当前工作树是干净的(没有需要再次提交的东西)

git reflog => 查看简略版本信息

git log => 查看详细版本信息(不止7位的完整版本号)

修改文件

修改文件后查看状态,会得到两块内容:

  1. 当前所处的分支
  2. 当前有需要提交的内容(工作区、暂存区相关)

不难发现,相较于最初的三块内容,这里少了一块,因为本地库已经有了版本信息。

此时,可以通过git add, git commit来重复前几节内容,并且可以在途中查看本地库状态来加深理解。

最后,查看版本信息,会发现有两条历史版本的记录,指针HEAD指向最新提交的记录。

穿梭历史版本

git reflog => 找到想要穿梭的版本的版本号复制

git reset --hard &lt;版本号> => 穿梭历史版本

此时git reflog会自动添加一条穿梭版本的记录,同时指针指向了指定的版本,这一点可以通过查看当前目录下的文件的内容进行核对确认。

Git分支操作

什么是分支

在版本控制过程中,同时推进多个任务,可以为每个任务创建每个任务独立的分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开,开发自己分支的时候,不会影响主线分支的运行。

对于初学者而言,分支可以简单理解为副本,一个分支就是一个单独的副本。(分支底层其实也是指针的引用)

分支的好处

并行推进多个功能开发,提高开发效率。

各个分支在开发过程中,如果某一个分支开发失败,不会对其它分支有任何影响。失败的分支删除重新开始即可。

分支的操作

查看分支

git branch -v => 查看分支<br>如果有多个分支,分支名前打星号的为当前所在分支

创建分支

git branch &lt;branch_name> => 创建分支

切换分支

git checkout &lt;branch_name> => 切换分支

修改分支

在新分支下修改文件,添加暂存区并且提交本地库。

正常合并分支

切换回原分支,查看文件,发现内容复原了。(因为原分支并没有被修改)

git merge &lt;branch_name> => 将指定分支合并到当前分支

再次查看文件内容,发现被修改成了新分支下变化后的内容。

冲突合并分支

在两个分支分别修改文件内容,刻意制造冲突(比如同一个文件同一个位置都有变化),记得都得在各自分支上添加暂存区并提交本地库。

尝试用上一小节的命令合并,报错有冲突,并且会注明是哪个文件有冲突。此时打开文件,会发现冲突位置有类似如下符号:

&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
line1 head
line2
=======
line1
line2 test
>>>>>>> hot-fix

其中,HEAD=之间为当前分支内容,=hot-fix之间为将要合并过来的分支的内容。

修改冲突也很简单,只需要删除不想要的,保留想要的,当然,特殊符号也需要删除,例如:

line1 head
line2 test

保存文件后,将该文件添加暂存区,然后提交本地库。<br>注意: 这里提交本地库的时候不能写文件名,因为当前处于MERGING状态,需要对合并过来的内容一并操作而不只是解决冲突的文件。同时,合并成功后只针对当前分支,另一个分支的内容不会被修改。其本质是指针指向切换。

团队内协作

员工1和员工2都拥有代码托管中心中某一个远程库的权限(视为在同一个团队),他们可以分别将这一个远程库git clone到自己的本地库。

在各自的本地库,员工1和员工2分别开发新的功能,任何一方将自己的功能完善之后就可以git push到远程库。

此时,另一方就可以通过git pull将代码拉取到本地,使自己的本地库与远程库的版本同步。反之同理。

通过这一系列循环往复地操作,员工1和员工2开发的功能都将存储在同一个远程库中。

跨团队协作

书接上回,一个开源项目爱好者发现了这个远程库中存在一个bug,但是,他没有这个库的权限(与员工1员工2不在一个团队),即使修改了bug也没办法直接操作这个远程库存储的内容。

于是,他先将这个远程库fork出一份新的远程库,而他拥有这个新远程库的权限。

所以,这位开源项目爱好者通过git clone将新的远程库下载到本地,修改完bug之后git push回去。

这个时候,在这个新的远程库向员工1员工2所在的团队的远程库创建一个Pull request,简称为pr。之后,那个团队的负责人就可以看到这个申请,如果他审核完觉得这个开源项目爱好者改得好,就可以将他提的pr合并(merge)进团队的远程库中。

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Nigdle
Nigdle
0xa745...Fe19
江湖只有他的大名,没有他的介绍。