SVN

SVN是subversion的缩写，是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理。通俗的讲，就是用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理

注意：这里，我只做了基础的了解，了解一些概念和看了一些操作，实操没有，等到需要我会再来补全

具体学习：菜鸟教程 - SVN 教程

解决以下问题

  1. 保存项目历史记录
  2. 提供多人协作

功能

  • 记录一款软件添加或更改源代码的过程
  • 回滚到特定阶段，恢复误删除的文件
  • 合并多人协作的文件等
  • 多人协同，文件传输

集中式的优缺点

集中式

  • 优点：每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。
  • 缺点： 过分依赖中央处理器，若中央处理气出现问题，则会导致整个项目的停滞甚至丢失，所以，为了以防中央处理器出现问题，数据还是得做好备份

SVN的一些术语

  • repository（源代码库）:源代码统一存放的地方
  • Checkout（提取）:当你手上没有源代码的时候，你需要从repository checkout一份
  • Commit（提交）:当你已经修改了代码，你就需要Commit到repository
  • Update (更新):当你已经Checkout了一份源代码， Update一下你就可以和Repository上的源代码同步，你手上的代码就会有最新的变更

SVN服务端版本（VisualSVN）

官网：https://www.visualsvn.com/

下载：下载server版本

image-20200630155127616

SVN客户端版本（TortoiseSVN）

基础操作

使用教程：https://www.runoob.com/svn/svn-tutorial.html

  • 检出项目：checkout
    • 在没有源代码的前提下，需要通过 tortoise-svn 客户端下载
  • 提交修改：commit
    • 帮你记录当前开发的软件的状态
  • 更新文件或目录：update（更新）
    • 别的开发人员在已有源代码的前提下可以通过 update 更新服务器上最新的版本
  • 查看版本日志：show log（日志）
  • 锁定文件： totoriseSVN → Get Lock，若修改完文件不想让他人修改可使用该选项

关于冲突

当两个程序员在同时修改同个版本号的代码时

  1. 当修改的是不同代码时，可以通过SVN的update自动合并修改
  2. 当修改的是同行代码时，可以通过SVN的提示文件conflict，手动确定
    • 操作：update→双击报错的同行代码信息→和另一位程序员讨论确定

良好的习惯：

  • 提交之前，先更新（每次 commit 之前都要 update）
  • 一个文件最好同一时间只被一个人修改提交
  • 多跟团队成员沟通
  • 不要随便去修改别人的文件
  • 每次 commit 的时候都务必要写提交日志
  • 不要频繁的提交版本
    • 一般有比较成熟的功能模块的时候，再去提交
    • 修复了功能性 bug 的时候再去提交，最好不存在其它bug

Git

cmd操作

  • mkdir 目录名（在当前目录创建文件夹）
  • cd 目录名 （转到指定目录）
  • ls （查看当前目录文件）
  • ls -a （查看当前目录包含隐藏文件）
  • clear （清屏）
  • rmdir 空目录名（移除空目录）
  • rm -rf 目录名 （移除目录，包括里面的数据）
  • rm 文件 （移除文件）

Git操作

基础操作

  • git init （初始化仓库）
  • git status （检查文件，仓库状态）
  • git add 文件名.文件后缀（添加文件至暂存区）
  • git commit -m “更新记录” （提交）
  • git log （查看日志）
  • gitk （图形界面）-patch（差异）

远程仓库操作

  • git config –global user.name “账户名” （绑定账户）
  • git config –global user.email “绑定邮箱” （绑定账户）
  • git clone GitHub仓库地址 （加载到本地仓库）
  • git remote add 自定义仓库标识名 仓库地址 （连接GitHub仓库）
  • git remote show （显示连接的仓库）
  • git remote show 仓库标识名 （显示仓库信息）
  • git push 仓库标识名 main（推送到远程仓库）
  • git push –set -unstream 仓库名 main（设置默认push仓库名）
  • git remote remove 仓库标识名 （移除仓库）
  • git pull 仓库标识名 分支名 （从远程仓库获取代码并合并版本）
  • git push -f (强制上传)

文件编辑操作

  • vi 文件名 （用vi文本编辑器打开当前文件）
    • :q（退出该编辑器）
    • :光标+i（在光标处开启编辑）
    • ESC （退出编辑）
    • :w （保存）
    • :wq（保存并退出）
  • git commit –amend（修改最近一次历史版本提交日志）
  • git add 文件夹名/ （将该文件夹所有文件放入暂存区）
  • git add –all （将当前目录下所有文件放入暂存区）
  • git rm 文件名 （从本地仓库移除文件）
  • git mv 原文件名 新文件名 （修改文件名）
  • git rm –cashed 文件名
  • git commit -a （越过暂存区直接到仓库）
  • git checkout – 文件 （恢复并覆盖最近一次暂存区的文件到工作区）
  • git reset –hard 版本id号（回退版本）

分支管理

  • git branch （查看分支）
  • git branch 分支名 （新建分支）
  • git ·checkout -b 分支名 （新建并切换到该分支）
  • git checkout 分支名 （切换分支）
  • git checkout - （切换到上个分支）
  • git merge 分支名 （合并指定分支到当前分支）
  • git branch -d 分支名 （删除分支）
  • git branch 新分支 已存在分支 （基于分支创建新分支）

.gitignore

过滤

1
2
3
4
/mtk/ 过滤整个文件夹
*.zip 过滤所有.zip文件
/mtk/do.c 过滤某个具体文件
mtk 直接过滤该文件夹

忽略过滤

1
2
3
!src/   不过滤该文件夹
!*.zip   不过滤所有.zip文件
!/mtk/do.c 不过滤该文件

git（本地）推送远程仓库流程

  1. 首先，绑定github（gitee）账户

    1
    2
    git config –global user.name “账户名” （绑定账户）
    git config –global user.email “绑定邮箱” （绑定账户）

  2. 初始化要push的文件夹

    1
    git init （初始化仓库）

  3. 添加文件至暂存区并提交，注意这里还是在本地进行

    1
    git add 文件名.文件后缀 /git add . （提交全部）
    1
    git commit -m “更新记录” （提交）

  4. 更改分支名为main

    1
    git branch -m main

  5. 连接github仓库

    1
    git remote add 自定义仓库标识名 仓库地址

  6. 推送（必须在有网的前提下）

    1
    git push 仓库标识名 main

    git分支管理策略

一般大型项目的维护、开发以及发布过程会遵循以下的策略（结合图来理解）

粉色模块Master是项目用来发布重大版本的分支，它是一个项目的主分支，日常开发所进行的分支则应在develop上进行，相应的功能模块会在基于develop分支上进行创建，功能模块实现并完成了它的任务（功能）并和develop分支合并（merge）后，则可清除该分支（红色曲线）。

在develop开发到一定程度决定发布后，则可以通过release-（橙色，\代表版本号）分支进行测试，release分支进行项目的运行测试并修改相应bug并确认无误后则可在Master主分支上对release进行合并（merge），同时将无bug版本在develop上也进行合并（merge），之后它便可以光荣退休（红线）了，等待下一个重大的日常版本来再出现。

Maste主分支在对外发布并运行的过程多多少少（当然能尽量避免就尽量避免）可能会出现一些测试未发现的bug，这时，则可以在它上面新建分支，用来解决对应bug，名称为fixbug-bug名，在对bug进行解决后则可继续合并到主分支，同时合并到develop上去，这时的fixbug也可以退休（红线）啦。

git分支管理策略

可以同时参考这篇博客http://www.ruanyifeng.com/blog/2012/07/git.html

下图是另外一种结构图（图源网络）

git分支结构图

总结：如果要清晰完整的开发好一个大型多人合作的项目，做好以下几点

  • 列好分支清单，统一好分支的命名，不要使分支混乱
  • 定时合并和清理分支，保证分支的简洁度和项目功能的完整度
  • 在一个大版本即将发布之时，检查好该版本的功能完整性以及测试是否可以正常运行，尽量少做在发布之时修改bug。
  • 提交每个版本时要做好清晰的备注

git工作流程

参考博客：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

以后有用到我会回来补齐，包括Git flow、GitHub flow（更多为开源项目采用）以及GitLab flow（京东、淘宝等大型项目更多采用）

遇到的问题

  1. git 提示：error: unable to rewind rpc post data - try increasing http.postBuffer

    解决：大概意思是http.postBuffer太小，需要设置更大的值，项目文件太多太大

    在终端执行

    git config –global http.postBuffer 524288000

  2. error: RPC failed; curl 56 OpenSSL SSL_read: error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac, errno 0

    解决：git config http.sslVersion tlsv1.2