知识点
- 版本控制
- SVN
- Git
- Github
版本控制
问题1:历史记录
问题2:多人协作
解决问题:软件
版本 用户 说明 日期
1 张三 删除了软件服务条款5 7/12 10:38
2 张三 增加了License人数限制 7/12 18:09
3 李四 财务部门调整了合同金额 7/13 9:51
4 张三 延长了免费升级周期 7/14 15:17
什么是版本控制?
版本管理就是管理更新的历史记录,
它给我们提供了一些在软件开发过程中必不可少的功能,例如:
- 记录一款软件添加或更改源代码的过程
- 回滚到特定阶段,恢复误删除的文件
- 合并多人协作的文件等
- 多人协同,文件传输
版本控制分类
- 集中式
- SVN
- 分布式
- Git
SVN
SVN 全称 Apache Subversion,是一个开放源代码的集中式版本管理系统。
在 2000 年由 CollabNet 开发,现已发展成为 Apache 软件基金会的一个开源项目。
环境安装
SVN 交互协作流程
集中式
早期的版本管理就是以 Apache Subversion
为代表的集中式版本管理,
集中式版本管理将所有的数据集中存放在服务器中,这是有便于统一管理的优点。
但是一旦开发者所处的环境不能连接服务器,就无法获取最新源代码,开发也就无法进行。
服务器宕机时也是同样的道理,而且万一服务器故障导致数据丢失,
恐怕开发者就再也见不到最新的源代码了。
简而言之:
- 中央服务器好比是一个图书馆
- 你要改一本书,必须先从图书馆借出来(checkout)
- 然后回到家自己改,改完了,再放到图书馆(commit)
一些术语
- 源代码库(repository):源代码统一存放的地方
- 检出(checkout):当你手上没有源代码的时候,就需要从 responsive checkout 一份
- 提交(commit):当你已经修改了代码,就需要 commit 到 repository
- 更新(update):当你已经 checkout 了一份源代码,Update 一下就可以和 repository 上的源代码同步,你手上的代码就会有最新的变更
使用 VisualSVN 搭建 SVN 服务器
SVN 服务器:运行 Subversion 服务的计算机。
为了方便,我们这里使用比较流行的图形化工具 VisualSVN
来搭建我们的 SVN 服务。
安装完毕之后,基本使用流程如下:
- 创建用户
- 创建版本仓库
- 设定用户权限
使用 TortoiseSVN 作为 SVN 客户端
SVN 客户端:用户通过SVN客户端同SVN服务器交互
这里我们使用最流行的 TortoiseSVN
https://DESKTOP-40UMEJI:8443/svn/jd
https://192.168.133.25:8443/svn/jd
TortoiseSVN 客户端基本操作流程
- 检出项目:
checkout
- 在没有源代码的前提下,需要通过 tortoise-svn 客户端下载
- 提交修改:
commit
- 帮你记录当前开发的软件的状态
- 更新文件或目录:
update
(更新)- 别的开发人员在已有源代码的前提下可以通过 update 更新服务器上最新的版本
- 查看版本日志:
log
(日志)
关于冲突
假设 A、B 两个用户都在版本号为 100 的时候,更新了 kingtuns.txt 这个文件,
A 用户在修改完成之后提交 kingtuns.txt 到服务器, 这个时候提交成功,
这个时候 kingtuns.txt 文件的版本号已经变成 101 了。
同时B用户在版本号为 100 的 kingtuns.txt 文件上作修改, 修改完成之后提交到服务器时,
由于不是在当前最新的 101 版本上作的修改,所以导致提交失败。
良好的使用习惯就是,提交之前,先更新。
为了避免冲突,别人的文件你最好不要动,
万一你要修改公共的文件或者是别人的文件,
跟别人最好口头沟通好,就是你改动的时候,
别人最好不要去改动,这样才能最大程度上避免冲突的问题。
多人协作时,同个目录或同个文件需要不同成员共同开发,
这个时候 commit 和 update 就可能出现冲突。
- 两个程序员只要不是修改了同一行程序,SVN 可以通过 update 自动合并修改
- 但是如果两个程序员修改了同一行程序, SVN 会提示文件 conflict,需要手动确定
如何解决?
第一种解决方法:手动合并冲突的内容
第二种解决方法:每次修改某个文件的时候对文件上锁,这样你在修改的过程中别人就无法更新这个文件
建议:
- 一个文件最好同一时间只被一个人修改提交
- 多跟团队成员沟通
- 不要随便去修改别人的文件
版本管理使用建议
- 不要频繁的提交版本
- 一般有比较成熟的功能模块的时候,再去提交
- 修复了功能性 bug 的时候再去提交
- 提交的代码最好无 bug
- 每次 commit 之前都要 update
- 因为你在编辑这个文件的时候,可能比人已经编辑并提交了某个版本
- 所以先 update,目的是为了检查一下服务器上有没有最新版,如果有,直接更新
- 更新的过程中如果遇到冲突,不要慌,去手动解决
- 每次 commit 的时候都务必要写提交日志
- 这个提交日志就好比你保存副本的时候加的一个标记
- 目的是为了日后做版本的回退查找以及查看记录更新状态
使用总结
- 版本控制管理系统
- 源代码仓库 repository
- 检出代码 checkout
- 更新最新源代码 update
- 提交修改 commit
其它
Git
学习资源介绍
Git 简介
- 是什么
- Git 也是一个版本控制管理软件
- 有什么用,可以解决什么问题
- 保存历史记录
- 多人协作
- 有了 SVN,为啥要学 Git
- Git 火
- Git 相对于 SVN 来说,更强大,用户也非常多
- 怎么用
- Git 的诞生
Git 使用交互流程
安装和配置 Git 环境
- 下载地址:https://git-scm.com/
git-bash 常用命令
- pwd
- ls
- ls -a
- cd
- mkdir
- clear
- rmdir
- 只能删除空目录
- rm
- rm 文件名
- rm -rf 目录名
- 注:很强大,可以删除非空目录,以及一些比较顽固的文件或者目录
初始化配置
# 设置用户名
git config --global user.name "你的名字"
# 配置用户邮箱
git config --global user.email "你的常用邮箱"
# 设置 gitk 图形查看工具中文显示默认编码(防止乱码)
git config --global gui.encoding utf-8
# 查看配置列表项
git config --list
基本使用
-
git init
- 初始化一个 Git 仓库
-
git status
- 查看当前工作区、暂存区、本地仓库的状态
git add
-
git commit
- 示例:
git commit -m "日志说明" --author="操作者姓名 <邮箱>"
- 执行
git commit
的时候,Git 会要求具有用户名和邮箱的参数选项 - 可以通过
git config
命令配置一下用户名和邮箱
- 示例:
git log
gitk
总结:操作 Git 的基本工作流程就是先修改文件,然后执行 git add
命令。
git add
命令会把文件加入到暂存区,接着就可以执行 git commit
命令,将文件存入文档库,
从而形成一次历史记录。
- 问题1:关于 Git-bash 中文问题
- Git for Windows Unicode Support
- 问题2:执行 commit 的时候一大堆的信息
- 问题3:配置 user.name 和 user.email 问题
工作区、暂存区、本地仓库
远程同步
- remote
- push
- pull
在线仓库托管服务
一个不知道 github、stackoverflow 的程序员想想都是可悲的
- github
- 码云
- coding
Github
Github 就是程序员的新浪微博
它可以让你使用社交化的方式进行编程协作、
- 点赞
- 评论
- 转发
- etc.
主要作用:可以免费在线托管你的仓库
可以实现多人协作
提供了一个可视化界面(Web Page)让你能直观清晰的了解你的项目源代码
基本使用
- 注册
- 登陆
- 创建远程仓库
- 通过
git clone
命令下载远程仓库到本地- git clone 会自动帮你把远程仓库下载到本地,不需要再去 git init 了
- 通过 clone 下来的仓库,git 有一个远程仓库地址列表,git 默认会把你 clone 的地址起一个别名:origin
- 然后你执行 push 的时候实际上就是将本地的版本提交到 origin 上
- 在本地进行操作,通过
git commit
形成历史记录 - 通过
git push
将本地仓库中的历史记录提交到远程仓库
本地已有仓库,需要提交到线上
如果是 git init
出来的仓库,进行 push
提交的时候就不知道要往哪里 push。
所以,这里通过 remote
相关命令进行设置:
# 查看所有的远程仓库信息
git remote show
# 根据别名查看指定的远程仓库信息
git remote show 远程仓库地址别名
# 添加远程仓库信息
git remote add 别名 远程仓库地址
通过上面的 git remote add
添加完远程仓库地址信息之后,还不能直接 git push
,必须在每一次
push
的时候加上 git push 仓库地址别名 master
就可以提交了。
如果想要省略 git push
后面需要指定的 仓库地址别名 master
可以通过下面的命令修改:
git push --set-upstream heima master
这样就可以直接使用 git pish
进行提交而不需要指定 heima master
了
目标
- 能概述什么是版本控制并举例
- 能概述 SVN 的协作交互流程(远程仓库、用户、本地仓库)
- 能掌握 SVN 基本的交互使用(checkout、update、commit)
- 能概述 Git 的协作交互流程(远程仓库、用户、本地仓库)
- 能掌握 Git 的基本使用(init、status、add、commit、log、clone、push、remote)
Git-bash 文件操作相关命令
-
touch
:创建文件 -
cat
:查看文件 -
less
:查看大文本文件 -
vi
:visual interface-
Esc
退出到命令模式 -
i
进入插入模式 - `:q 退出vi
-
:w
保存编辑 -
:wq
保存并退出 -
:q!
强制退出不保存修改 - vi 的所有操作基本全部是命令,这里掌握基本使用基于可以了
- 有时候使用 git commit 进行提交的时候希望能多写几行提交日志,这时候可以省略 -m 参数进入 vi 编辑模式
-
添加/删除文件
# 添加指定文件到暂存区
git add [file1] [file2] ...
# 添加指定目录到暂存区,包括子目录
git add [dir]
# 添加当前目录的所有文件到暂存区
git add .
# 删除工作区文件,并且将这次删除放入暂存区
git rm [file1] [file2] ...
# 停止追踪指定文件,但该文件会保留在工作区
git rm --cached [file]
# 改名文件,并且将这个改名放入暂存区
git mv [file-original] [file-renamed]
代码提交
# 提交暂存区到仓库区
git commit -m [message]
# 提交暂存区的指定文件到仓库区
git commit [file1] [file2] ... -m [message]
# 提交工作区自上次commit之后的变化,直接到仓库区
git commit -a
# 使用一次新的commit,替代上一次提交
# 如果代码没有任何新变化,则用来改写上一次commit的提交信息
git commit --amend -m [message]
# 重做上一次commit,并包括指定文件的新变化
git commit --amend [file1] [file2] ...
回退撤销
# git rm --cached <file>
# 恢复暂存区的指定文件到工作区
git checkout [file]
# 恢复某个commit的指定文件到暂存区和工作区
git checkout [commit] [file]
# 恢复暂存区的所有文件到工作区
git checkout .
# 重置暂存区的指定文件,与上一次commit保持一致,但工作区不变
git reset [file]
# 重置暂存区与工作区,与上一次commit保持一致
git reset --hard
# 重置当前分支的指针为指定commit,同时重置暂存区,但工作区不变
git reset [commit]
# 重置当前分支的HEAD为指定commit,同时重置暂存区和工作区,与指定commit一致
git reset --hard [commit]
# 重置当前HEAD为指定commit,但保持暂存区和工作区不变
git reset --keep [commit]
# 新建一个commit,用来撤销指定commit
# 后者的所有变化都将被前者抵消,并且应用到当前分支
git revert [commit]
# 暂时将未提交的变化移除,稍后再移入
git stash
git stash pop
分支管理
默认在 git 的仓库中,会有个分支的原点:master
# 列出所有本地分支
git branch
# 基于当前分支新建一个分支,但依然停留在当前分支
git branch [branch-name]
# 基于当前分支新建一个分支,并切换到该分支
git checkout -b [branch]
# 切换到指定分支,并更新工作区
git checkout [branch-name]
# 切换到上一个分支,交替和上一个分支进行切换
git checkout -
# 合并指定分支到当前分支
git merge [branch]
# 删除分支
git branch -d [branch-name]
远程操作
# 下载一个远程仓库
$ git clone [url]
# 显示所有远程仓库
git remote -v
# 显示某个远程仓库的信息
git remote show [remote]
# 增加一个新的远程仓库,并命名
git remote add [shortname] [url]
# 取回远程仓库的变化,并与本地分支合并
git pull [remote] [branch]
# 上传本地指定分支到远程仓库
git push [remote] [branch]
# 强行推送当前分支到远程仓库,即使有冲突
git push [remote] --force
Git 工作流程:分支策略
Git Flow
Develop分支不要直接合并到master,而是要经过预发布分支(release版)发布一个测试版,测试过没问题后,由预发布分支再合并到master和Develop分支,最后预发布版删除。预发布分支基于Develop分支(因为是用来测试开发结果的,不是正式版)。fixbug分支基于master分支(需修复正式版上的bug),bug修复后需要合并到master分支和Develop分支,因为这两个bug原来也存在同样的bug,因为它们基本上也保持同步的状态。
Github Collabrators
这种方式公司团队项目使用居多
Github Flow
这种方式开源项目使用居多
- fork
- clone 到你的本地
- 在clone下来的项目中拉出一个新的分支
- 修改的时候最好是基于 master 拉出一个修改的分支,例如这个分支是用来添加某个功能的
- 在新分支上开发或者修改完成之后,提交到本地仓库,然后 push 推到自己的账户中 fork 过来的仓库
- 最后,在 Github 上你 fork 过来的仓库界面中找到 New Pull Request 发起提交请求
- 对方就会在仓库的 Pull Requests 中收到你发起的提交请求
- 然后双方就可以使用社会化交流方式进行沟通协作
- 例如 Code Review 代码审查
- 最后对方审查通过没有问题之后,选择 Merge Request
- 到此,一个完整的 Github 工作流结束
- 这种方式开源项目更多一些(大家都不认识)
Gitlab flow
Gitlab
对于第三方代码仓库托管服务有很多,其中 Github 最火,但是如果想要托管私有项目收费比较高,
而且在国内受限于网络环境影响,鲜少有公司使用。
也有的公司,例如京东、淘宝这种级别的公司,也不太常用别的第三方的托管服务。
Gitlab 是一个开源的类似于 Github 的一个系统,开源免费部署到自己的公司内容。
与 Github 进行多人协作
Collaborators
Pull Request
Github Pages
Github Pages 提供了一个免费在线托管静态资源的服务,叫做:Github Pages。
使用方法如下:
- 在个人的 Github 账户中创建一个仓库
- 仓库名称必须为
个人账户名称.github.io
- 往该仓库根目录中提交一个
index.html
文件 - 然后就可以在地址栏输入
个人账户名称.github.io
地址,就可以看到index.html
网页内容了
注意:上面创建的仓库名称必须是 个人账户名称.github.io
,否则无法访问
Hexo
Hexo 是基于 Node.js 开发的一个静态博客生成器,提供本地实时预览及部署功能。
基本使用方式如下:
npm install -g hexo-cli
hexo init blog
cd blog
# 启动本地预览服务,默认是 127.0.0.1:4000
hexo server
# 新建文章
hexo new 文章标题
也可以参考 Hexo 官方文档:https://hexo.io/zh-cn/ , 里面有具体的使用方式。
自动发布 Hexo 搭建的静态博客
第一:先修改 _config.yml
配置文件,下面是一个示例:
deploy:
type: git
repo: https://aizawasayo:pwd123456@github.com/heima04/heima04.github.io.git
上面的配置选项中,一定要注意在 repo 中按照对应的格式加入 Github 用户名和密码。
第二:安装自动发布的插件:
npm install hexo-deployer-git --save
第三:使用命令一键进行发布:
hexo generate --deploy
# 或者
hexo deploy --generate
上面两条命令都可以,发布可能有延时,稍微等待即可。
目标
- 能掌握 Git-Bash 中 touch、cat、less、vi 命令的基本使用
- 能掌握 Git 中分支的基本操作(branch、checkout、merge)
- 能概述 Git-Flow 工作流(Git-Flow 分支管理策略)
- 能掌握 Github 中多人协同的两种协作方式(Collaborators 和 Pull Request)的基本操作流程