目录
例:将 “ OLED文件夹 ” 添加到笔者的 gitee仓库中。
一、需求的产生
在软件开发过程中,每实现一个功能,每前进一步,都要赶紧存档备份,保存为一个版本,然后以这个版本为基点进行下一个版本的开发。客户不停地提需求,改需求,你就不停地备份版本。这就像写毕业论文一样,你不停地改论文,导师不停地打回来,到最后就变成了这个样子。
不同版本的论文之间 到底修改了哪些东西 ?时间久了,可能也就 慢慢忘记了。有没有更好的方法去 记录这些详细的变化呢 ? 答案是有的。我们可以 使用 版本控制 系统来记录每一次的 修改和变化。
二、版本控制系统理解
1. 认识版本控制系统
版本控制系统会跟踪并记录一个项目中每一个文件的变化:谁创建了它,谁修改了它,又是谁删除了它,是什么时候,修改了什么内容,都一一记录在案。有了版本控制系统,工程师之间互相推卸责任的机会大大减少了,你修改了什么,都有详细的记录在案,都保存在版本库中,铁证如山,随便翻一翻就可以查得到。
2. 版本控制系统分类
版本控制系统一般分为:集中式版本控制系统和分布式版本控制系统。
(1)集中式版本控制系统
其软件的各个版本快照只保存在服务器上,服务器中包含各个版本的软件代码。用户如果想要观看某个版本的代码, 首先要从版本库中将该版本的代码拉取到本地的计算机上,然后才能查看和修改,最后将自己的修改保存到服务器上。
缺点:
① 数据存储在 服务器上,使用时要 联网:员工直接登录服务器 删库 跑路,如果数据没有备份,问题就很严重,基本上就 很难恢复了。
② 收费:远远 没有免费的分布式版本控制 系统受 欢迎。
(2)分布式版本控制系统
不再将整个版本库保存在一个服务器上,而是保存在每个员工的计算机中。
好处:
即使服务器 崩溃了,或者离职的员工删除了服务器的代码,只要 数据在任何一个员工的计算机中有 备份,都可以 直接恢复,因为 每个计算机保存的版本库数据 都是一样的。
集中式 和 分布式版本 控制系统 典型的代表就是 小乌龟和 Git 。
三、初识 git
学习git,首先要明白几个重要的基本概念:工作区(Working Directory)、暂存区(Staging Area) 和版本库(Repository)。
版本库 里保存的是我们提交的 多个版本的代码快照,如果想查看某个版本的代码,可以通过 git checkout命令将版本库里这个 版本的代码拉取出来,释放到 工作区。
在工作区,可以浏览某一个版本的代码、修改代码。如果想 把自己修改保存到版本库中,可以先将修改保存到 暂存区,接着修改,再保存到暂存区,直到 真正完成修改,再统一将暂存区里所有的修改提交到 版本库中。
为什么还需要一个暂存区呢?将工作区的修改直接提交(Commit),保存到版本库中岂不是更方便?
答:
对于一个版本库来说,你的 任何一个提交,包括修改、添加文件、删除文件等 操作都会有一个记录,而在 实际工作中,对于一个 工程师来说,在 开发一个功能时,可能会分成很多步,如果每一小步都去 提交一次,意义不是很大,而且 不是一个 完整的功能,别人可能就 搞不懂你的提交到底实现了 什么功能。所以将每次 很小的修改都做一次提交,就不是很合适。
从原则上讲,我们的 每一次提交,都是一个 里程碑:要么新增了一个功能,要么修改了一个 Bug,要么优化了一个功能。在实际开发中的 每一小步,都可以 先保存到暂存区,等整体功能 完成后,再统一 提交比较合理。
四、git 的使用
例:将“OLED文件夹”添加到笔者的gitee仓库中。
1. 在此文件路径下打开命令。
2. git init :在此路径下初始化Git仓库。
如果初始化成功,将会生成 .git 目录。这个 .git 目录 里存储着 管理当前目录内容所需的仓库数据。在 Git中,这个目录的内容被称为 “ 附属于该仓库的工作树 ” 。文件的编辑 等操作在工作树中进行,然后 记录到仓库中,以 此管理文件的历史快照。
如果想将文件恢复到原先的状态,可以从仓库中调取之前的快照,在工作树中打开。开发者可以通过这种方式获取以往的文件。
补:此时 git status 命令查看 “ OLED文件 ” 时显示在 Untracked files 里。
3. git add OLED :将工作区的修改“OLED文件夹”添加到暂存区(提交之前的一个临时区域,即Stage 或 Index)。
补:
(1)git status 命令 的显示结果发生了变化。“ OLED文件 ” 显示在 Changes to be committed 中了。
(2)git rm --cached OLED:将 “ OLED文件夹 ” 从暂存区中 删除。
4. git commit -m “<日志信息(自写)>” OLED:将暂存区的修改提交到本地仓库,即保存仓库历史记录。(通过这些记录就可以在工作树中复原文件)
补:
(1)git status:查看文件的状态。每一步操作后,OLED 的文件状态都会发生变化 :从untracked 到 changes to be commited ,工作区的状态 也会跟着变化。
(2)git log:查看提交信息。包括提交的 ID、提交作者、提交时间、提交信息说明 等。( 后加上目录名,便会 只显示该目录下的 日志。如果 加的是 文件名,就会 只显示与 该文件相关的日志 )
5. 如果想把修改再次提交到本地仓库,可以使用下面的命令。
(1)git add OLED
(2)git commit -m “<日志信息(自写)>” OLED
git show:查看新的提交信息和修改变化。
6. git remote add origin 远程仓库地址:建立本地仓库与远程仓库的关联。
git remote rm origin:删除关联的origin的远程库。
git pull --rebase origin master:将远程仓库的内容合并到本地仓库。
7. git push -u origin master:将本地仓库的文件推送到已经建立关联的远程仓库master分支中。
基本命令整理:
五、分支操作
在进行多个并行作业时,会用到分支,每个分支中都拥有自己的最新代码。master分支是 Git 默认创建的分支,因此基本上所有开发都是以这个分支为中心进行的。不同分支中,可以同时进行完全不同的作业。等该分支的作业完成之后再与 master分支合并。
如果想让自己提交不影响整个项目,不影响其他人使用,则可以创建一个自己的分支my_branch,切换到 my_brancn分支 上,然后在这个分支上 修改代码 就可以了。提交时 再将自己修改用上面的方法 提交到 my_branch分支 上。通过这种操作,所有修改 都提交到你 自己创建的分支 my_branch 上,而不会影响 master主分支上 的代码,不会影响其他人。
(1)git branch my_ branch :创建一个新分支 my_branch。
(2)git checkout my_ branch :切换到新分支my_branch。
(3)git commit -m "on my _brach:modify OLED”:将修改提交到 my_branch。
(4)git log:查看新的提交信息。
(5)git checkout master:切换到 master 分支,在该分支上看不到新的提交信息。
(6)git merge my_branch:将 my_branch 分支上的修改合并到 master 分支。
(7)git log:查看提交信息。
后续学习再行更新。