更新了第91天的文档和资源
This commit is contained in:
jackfrued
parent
662318eadb
commit
7847dd178f
|
|
@ -1,6 +1,6 @@
|
|||
## 团队项目开发的问题和解决方案
|
||||
|
||||
我们经常听到个人开发和团队开发这两个词，所谓个人开发就是一个人把控产品的所有内容；而团队开发则是由多个人组成团队并完成产品的开发。要实施团队开发以下几点是必不可少的：
|
||||
我们经常听到个人开发和团队开发这两个词，所谓个人开发就是一个人把控产品的所有内容；而团队开发则是由多个人组团并完成产品的开发。要实施团队开发以下几点是必不可少的：
|
||||
|
||||
1. 对开发过程中的各种事件（例如：谁到什么时间完成了什么事情）进行管理和共享。
|
||||
2. 在团队内部共享各类工作成果以及新的知识技巧等。
|
||||
|
|
@ -44,9 +44,7 @@
|
|||
|
||||
#### 问题7：无法实施代码重构
|
||||
|
||||
重构：在不影响代码产生的结果的前提下对代码内部的构造进行调整。
|
||||
|
||||
例如：在实施代码重构时可能引发退化。
|
||||
例如：在实施代码重构（在不影响代码产生的结果的前提下对代码内部的构造进行调整）时可能引发退化。
|
||||
|
||||
解决方法：大量的可重用的测试并实施持续集成。
|
||||
|
||||
|
|
@ -76,14 +74,16 @@
|
|||
|
||||
Git是诞生于2005年的一个开源分布式版本控制系统，最初是Linus Torvalds（Linux之父） 为了帮助管理Linux内核开发而开发的一个版本控制软件。Git与常用的版本控制工具Subversion等不同，它采用了分布式版本控制的方式，在没有中央服务器支持的环境下也能够实施版本控制。
|
||||
|
||||
对于有使用Subversion（以下简称为SVN）经验的人来说，Git和SVN一样摒弃了基于锁定模式的版本控制方案（早期的CVS和VSS使用的就是锁定模式）采用了合并模式，而二者的区别在于：
|
||||
对于有使用Subversion（以下简称为SVN）经验的人来说，Git和SVN的共同点是摒弃了传统的基于锁定模式的版本控制（早期的CVS和VSS使用了锁定模式，当一个开发者编辑一个文件时会锁定该文件，其他开发者在此期间无法编辑该文件），采用了更有效率的基于合并模式的版本控制，而二者的区别在于：
|
||||
|
||||
1. Git是分布式的，SVN是集中式的，SVN需要中央服务器才能工作。
|
||||
1. Git是分布式的，SVN是集中式的，SVN需要中央服务器的支持才能工作。
|
||||
2. Git把内容按元数据方式存储，而SVN是按文件，即把文件的元信息隐藏在一个.svn文件夹里。
|
||||
3. Git分支和SVN的分支不同。
|
||||
4. Git没有一个全局版本号而SVN有。
|
||||
3. Git分支和SVN的分支不同，SVN对分支的处理是相当“狗血”的。
|
||||
4. Git没有一个全局版本号，但是可以自己维护一个版本标签。
|
||||
5. Git的内容完整性要优于SVN，Git的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
|
||||
|
||||
总而言之，**Git真的非常棒！！！**
|
||||
|
||||
#### 安装Git
|
||||
|
||||
可以在[Git官方网站](http://git-scm.com/)找到适合自己系统的Git下载链接并进行安装，macOS和Windows平台下安装Git都非常简单，Linux下如果要安装官方最新的版本，建议通过官方提供的Git源代码进行构建安装，步骤如下所示（以CentOS为例）。
|
||||
|
|
@ -180,7 +180,7 @@ git config --global user.email "jackfrued@126.com"
|
|||
git commit -m '本次提交的说明'
|
||||
```
|
||||
|
||||
可以通过`git log`查看提交日志。
|
||||
可以通过`git log`查看每次提交对应的日志。
|
||||
|
||||
```Shell
|
||||
git log
|
||||
|
|
@ -189,13 +189,13 @@ git log --graph --pretty=oneline --abbrev-commit
|
|||
|
||||
#### Git服务器概述
|
||||
|
||||
Git不像SVN那样一定需要中央服务器才能工作，上面我们演示的版本控制操作都是在本地执行的，但是对于企业开发多人协作这样的环境就必须中央服务器的支持。通常，企业可以选择使用像Github这样的代码托管平台或自己搭建Git私服的方式来建立中央服务器。Github是一个基于Git的代码托管平台，创办于2008年4月，目前是全世界最大的代码托管网站，支持企业用户（可以创建私有仓库，私有仓库内容不对外界公开）和普通用户（受限的使用私有仓库，不受限的使用公开仓库，公开仓库内容对他人可见）。Github上面代码库惊人的增长速度证明了它是非常成功的，在2018年6月被微软以75亿美元的天价收购。
|
||||
Git不像SVN那样一定需要中央服务器才能工作，上面我们演示的版本控制操作都是在本地执行的，但是对于企业开发多人协作这样的场景还是需要中央服务器的支持。通常，企业可以选择使用代码托管平台（如[GitHub](https://github.com)）或自己搭建Git私服的方式来建立中央服务器（版本仓库），当然大多数的企业更倾向于后者。Github创办于2008年4月，目前是全世界最大的代码托管平台，支持企业用户（可以创建私有仓库，私有仓库内容不对外界公开）和普通用户（受限的使用私有仓库，不受限的使用公开仓库，公开仓库内容对他人可见）。Github上面代码库惊人的增长速度证明了它是非常成功的，在2018年6月被微软以75亿美元的天价收购。
|
||||
|
||||
国内也有不少类似Github的代码托管平台，最有名的当属[码云](https://gitee.com/)和[CODING](https://coding.net/)，目前码云和CODING对注册用户都提供了受限的使用私有仓库的功能，支持**Pull Request**（本质是一种对话机制，可以在提交你的工作成果时让相关人员或团队注意到这件事情），同时还提供了对**缺陷管理**、**Web Hook**等功能支持，这些使得版本控制系统还具备了缺陷管理和持续集成的能力。当然，很多公司都不愿意将自己的商业代码托管于别人的平台，对于这样的公司可以使用[Gitlab](<https://about.gitlab.com/>)来搭建公司内部的Git私服，具体的做法在下一章为大家介绍。
|
||||
国内也有不少类似Github的代码托管平台，最有名的当属[码云](https://gitee.com/)和[CODING](https://coding.net/)，目前码云和CODING对注册用户都提供了受限的使用私有仓库的功能，支持**Pull Request**（一种对话机制，可以在提交你的工作成果时让相关人员或团队注意到这件事情），同时还提供了对**缺陷管理**、**Webhook**等功能支持，这些使得版本控制系统还具备了缺陷管理和持续集成的能力。当然，很多公司都不愿意将自己的商业代码托管于别人的平台，这样的公司可以用[Gitlab](<https://about.gitlab.com/>)来搭建公司内部的Git私服，具体的做法在下一章为大家介绍。
|
||||
|
||||
|
||||
|
||||
这里我们直接以码云为例来说明Git服务器使用的一些注意事项。首先需要在码云上注册账号，当然也可以使用第三方登录（github账号、微信账号、新浪微博账号、CSDN账号等），登录成功后就可以创建项目，创建项目几乎是“傻瓜式”的，无需赘述，我们只对几个地方加以说明。
|
||||
这里我们直接以码云为例来说明使用Git服务器的一些注意事项。首先需要在码云上注册账号，当然也可以使用第三方登录（github账号、微信账号、新浪微博账号、CSDN账号等），登录成功后就可以创建项目，创建项目几乎是“傻瓜式”的，无需赘述，我们只对几个地方加以说明。
|
||||
|
||||
1. 创建项目时不建议勾选如下图所示的这些选项，编程语言可以暂时不做选择，而`.gitignore`模板也可以稍后自己编写或者通过更专业的工具（如：<http://gitignore.io/>网站）自动生成。
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ Git不像SVN那样一定需要中央服务器才能工作，上面我们演示
|
|||
|
||||
|
||||
|
||||
3. 项目的分支。创建项目后，项目只有一个默认的**master**分支，应该将该分支设置为“保护分支”来避免项目管理者之外的成员修改该分支。
|
||||
3. 项目的分支。创建项目后，项目只有一个默认的**master**分支，应该将该分支设置为“保护分支”来避免项目管理者之外的成员修改该分支。当然，如果需要我们也可以在线创建新的代码分支。
|
||||
|
||||
4. 设置公钥实现免密访问。在项目的“设置”或“管理”中我们还可以找到“部署公钥管理”的选项，通过添加部署公钥，可以通过SSH（安全远程连接）的方式访问服务器而不用每次输入用户名和口令。可以使用`ssh-keygen`命令来创建密钥对。
|
||||
|
||||
|
|
@ -213,11 +213,11 @@ Git不像SVN那样一定需要中央服务器才能工作，上面我们演示
|
|||
ssh-keygen -t rsa -b 2048 -C "your_email@example.com"
|
||||
```
|
||||
|
||||
> **说明**：上面命令生成的密钥对在`~/.ssh`目录下，公钥文件默认的名字为`id_rsa.pub`，可以通过`cat id_rsa.pub`来查看自己的公钥。Windows用户在安装Git之后，可以通过**Git Bash**来输入上面的命令。
|
||||
> **说明**：上面命令生成的密钥对在`~/.ssh`目录下，公钥文件默认的名字为`id_rsa.pub`，可以通过`cat id_rsa.pub`来查看自己的公钥。Windows用户在安装Git工具后，可以通过**Git Bash**来输入上面的命令。
|
||||
|
||||
#### Git远程操作
|
||||
|
||||
拥有了Git服务器之后，我们就可以通过Git的远程操作将自己的工作成果推到服务器的仓库中，也可以将他人的工作成果从服务器仓库更新到本地。我们还是以刚才在码云上创建的名为`python`的仓库为例来说明如何进行远程操作。可以在如下所示的页面上看到仓库的地址，如果配置了**SSH Key**就使用SSH方式访问仓库，否则就用HTTPS方式，后者需要在进行远程操作时提供用户名和口令。
|
||||
拥有了Git服务器之后，我们就可以通过Git的远程操作将自己的工作成果推到服务器的仓库中，也可以将他人的工作成果从服务器仓库更新到本地。我们以刚才在码云上创建的仓库（仓库名为`python`）为例来说明如何进行远程操作。可以在如下所示的页面上找到仓库的地址（URL），如果配置了**SSH Key**就使用SSH方式访问仓库，否则就用HTTPS方式，后者需要在进行远程操作时提供用户名和口令。
|
||||
|
||||
|
||||
|
||||
|
|
@ -235,9 +235,9 @@ Git不像SVN那样一定需要中央服务器才能工作，上面我们演示
|
|||
git push -u origin master:master
|
||||
```
|
||||
|
||||
其中，`-u`是`--set-upstream`的缩写，用来指定推送的服务器仓库，后面的`origin`就是刚才给仓库起的简短的别名，冒号前面的`master`是本地分支名，冒号后面的`master`是远程分支名，如果本地分支`master`已经和远程分支`master`建立过关联，则可以省略冒号以及后面的部分。
|
||||
其中，`-u`是`--set-upstream`的缩写，用来指定推送的服务器仓库，后面的`origin`就是刚才给仓库起的简短的别名，冒号前面的`master`是本地分支名，冒号后面的`master`是远程分支名，如果本地分支`master`已经和远程分支`master`建立过关联，则冒号以及后面的部分可以省略。
|
||||
|
||||
> **说明**：一般不能直接将工作成果push到master分支，因为它通常是一个受保护分支。
|
||||
> **说明**：一般不能直接将工作成果push到`master`分支，因为它通常是一个受保护分支。
|
||||
|
||||
3. 从远程仓库取回代码。
|
||||
|
||||
|
|
@ -292,12 +292,12 @@ Git不像SVN那样一定需要中央服务器才能工作，上面我们演示
|
|||
|
||||
```Shell
|
||||
git switch master
|
||||
git merge dev
|
||||
git merge --no-ff dev
|
||||
```
|
||||
|
||||
使用`git merge`合并分支时，默认使用`Fast Forward`合并，这意味着如果删除了分支，分支上的信息就全都丢掉了，如果希望将分支上的历史版本保留下来，可以使用`--no-ff`参数来禁用`Fast Forward`。
|
||||
|
||||
在合并分支时，没有冲突的部分Git会做自动合并。如果发生了冲突（如dev和master分支上都修改了同一个文件），会看到`CONFLICT (content): Merge conflict in <filename>. Automatic merge failed; fix conflicts and then commit the result`（自动合并失败，修复冲突之后再次提交）的提示，这个时候我们可以用`git diff`来查看产生冲突的内容。解决冲突通常需要当事人当面沟通之后才能决定保留谁的版本，冲突解决后需要重新提交代码。
|
||||
在合并分支时，没有冲突的部分Git会做自动合并。如果发生了冲突（如`dev`和`master`分支上都修改了同一个文件），会看到`CONFLICT (content): Merge conflict in <filename>. Automatic merge failed; fix conflicts and then commit the result`（自动合并失败，修复冲突之后再次提交）的提示，这个时候我们可以用`git diff`来查看产生冲突的内容。解决冲突通常需要当事人当面沟通之后才能决定保留谁的版本，冲突解决后需要重新提交代码。
|
||||
|
||||
4. 分支变基。分支合并操作可以将多个分支上的工作成果最终合并到一个分支上，但是再多次合并操作之后，分支可能会变得非常的混乱和复杂，为了解决这个问题，可以使用`git rebase`操作来实现分支变基。如下图所示，当我们希望将`master`和`dev`上的工作成果统一到一起的时候，也可以使用变基操作。
|
||||
|
||||
|
|
@ -339,11 +339,11 @@ Git不像SVN那样一定需要中央服务器才能工作，上面我们演示
|
|||
|
||||
|
||||
|
||||
5. `git cherry-pick`：挑选某个分支的单次提交。
|
||||
5. `git cherry-pick`：挑选某个分支的单次提交并作为一个新的提交引入到你当前分支上。
|
||||
|
||||
6. `git revert`：撤回提交信息。
|
||||
|
||||
7. `git tag`：打版本标签。
|
||||
7. `git tag`：经常用于查看或新增一个标签。
|
||||
|
||||
#### Git工作流程（分支管理策略）
|
||||
|
||||
|
|
@ -371,19 +371,19 @@ Git不像SVN那样一定需要中央服务器才能工作，上面我们演示
|
|||
git push origin <branch-name>
|
||||
```
|
||||
|
||||
5. 在线发起一次合并请求（通常称之为**Pull Request**，有的地方称为**Merge Request**），请求将自己的工作成果合并到master分支，合并之后可以删除该分支。
|
||||
5. 在线发起一次合并请求（通常称之为**Pull Request**，有的地方称为**Merge Request**），请求将自己的工作成果合并到`master`分支，合并之后可以删除该分支。
|
||||
|
||||
|
||||
|
||||
上面这种分支管理策略就是被称为**github-flow**或**PR**的流程，它非常简单容易理解，只需要注意以下几点：
|
||||
|
||||
1. master的内容都是可以进行发布的内容（不能直接在master上进行修改）。
|
||||
2. 开发时应该以master为基础建立新分支（日常开发任务在自己的分支上进行）。
|
||||
1. `master`的内容都是可以进行发布的内容（不能直接在`master`上进行修改）。
|
||||
2. 开发时应该以`master`为基础建立新分支（日常开发任务在自己的分支上进行）。
|
||||
3. 分支先在本地实施版本控制，然后以同名分支定期向服务器进行push操作。
|
||||
4. 开发任务完成后向master发送合并请求。
|
||||
5. 合并请求通过审查之后合并到master，并从master向正式环境发布。
|
||||
4. 开发任务完成后向`master`发送合并请求。
|
||||
5. 合并请求通过审查之后合并到`master`，并从`master`向正式环境发布。
|
||||
|
||||
当然，github-flow的缺点也很明显，master分支默认就是当前的线上代码，但是有的时候工作成果合并到master分支，并不代表它就能立刻发布，这样就会导致线上版本落后于master分支。
|
||||
当然，github-flow的缺点也很明显，`master`分支默认就是当前的线上代码，但是有的时候工作成果合并到`master`分支，并不代表它就能立刻发布，这样就会导致线上版本落后于`master`分支。
|
||||
|
||||
##### Git-flow
|
||||
|
||||
|
|
@ -391,7 +391,82 @@ Git不像SVN那样一定需要中央服务器才能工作，上面我们演示
|
|||
|
||||
|
||||
|
||||
在这种模式下，项目有两个长线分支，分别是master和develop，其他都是临时的的辅助分支，包括feature（开发特定功能的分支，开发结束后合并到develop）、release（从develop分离出来的为发布做准备的分支，发布结束后合并到master和develop）和hotfix（产品发布后出现问题时紧急建立的分支，直接从master分离，问题修复后合并到master并打上标签，同时还要合并到develop来避免将来的版本遗漏了这个修复工作，如果此时有正在发布中的release分支，还要合并到release分支）。这套分支管理策略比较容易控制各个分支的状况，但是在运用上github-flow要复杂得多，所以实际使用的时候可以安装名为`gitflow`的命令行工具或者使用图形化的Git工具（如：SmartGit、SourceTree等），这样可以大幅度的简化版本控制操作，具体的可以参考[《git-flow 的工作流程》](<https://www.git-tower.com/learn/git/ebook/cn/command-line/advanced-topics/git-flow>)一文，因为这篇文章写得已经很好了，本文不再进行赘述。
|
||||
在这种模式下，项目有两个长线分支，分别是`master`和`develop`，其他都是临时的的辅助分支，包括`feature`（开发特定功能的分支，开发结束后合并到`develop`）、`release`（从`develop`分离出来的为发布做准备的分支，发布结束后合并到`master`和`develop`）和`hotfix`（产品发布后出现问题时紧急建立的分支，直接从`master`分离，问题修复后合并到`master`并打上标签，同时还要合并到`develop`来避免将来的版本遗漏了这个修复工作，如果此时有正在发布中的`release`分支，还要合并到`release`分支）。具体的实施过程如下所示：
|
||||
|
||||
|
||||
|
||||
1. 最开始的时候只有`master`和`develop`分支，如上图左侧所示。
|
||||
|
||||
2. 从`develop`分支创建`feature`分支，工作完成后将工作成果合并到`develop`分支。
|
||||
|
||||
创建`feature`分支：
|
||||
|
||||
```Shell
|
||||
git switch -c myfeature develop
|
||||
```
|
||||
|
||||
或
|
||||
|
||||
```Shell
|
||||
git checkout -b myfeature develop
|
||||
```
|
||||
|
||||
将`feature`分支合并到`develop`分支：
|
||||
|
||||
```Shell
|
||||
git checkout develop
|
||||
git merge --no-ff myfeature
|
||||
git branch -d myfeature
|
||||
git push origin develop
|
||||
```
|
||||
|
||||
3. 从`develop`分支创建`release`分支，发布结束后合并回`master`和`develop`分支。
|
||||
|
||||
创建`release`分支：
|
||||
|
||||
```Shell
|
||||
git switch -c release-0.1 develop
|
||||
...
|
||||
git commit -a -m "... ... ... ... ..."
|
||||
```
|
||||
|
||||
将`release`分支合并回`master`和`develop`分支：
|
||||
|
||||
```Shell
|
||||
git checkout master
|
||||
git merge --no-ff release-0.1
|
||||
git tag -a 0.1
|
||||
|
||||
git checkout develop
|
||||
git merge --no-ff release-0.1
|
||||
|
||||
git branch -d release-0.1
|
||||
```
|
||||
|
||||
4. 从`master`分支创建`hotfix`分支，在修复bug后合并到`develop`和`master`分支。
|
||||
|
||||
创建`hotfix`分支：
|
||||
|
||||
```Shell
|
||||
git checkout -b hotfix-0.1.1 master
|
||||
...
|
||||
git commit -m "... ... ... ... ..."
|
||||
```
|
||||
|
||||
将`hotfix`分支合并回`develop`和`master`分支。
|
||||
|
||||
```Shell
|
||||
git checkout master
|
||||
git merge --no-ff hotfix-0.1.1
|
||||
git tag -a 0.1.1
|
||||
|
||||
git checkout develop
|
||||
git merge --no-ff hotfix-0.1.1
|
||||
|
||||
git branch -d hotfix-0.1.1
|
||||
```
|
||||
|
||||
Git-flow流程比较容易控制各个分支的状况，但是在运用上github-flow要复杂得多，因此实际使用的时候通常会安装名为`gitflow`的命令行工具或者使用图形化的Git工具（如：SmartGit、SourceTree等）来简化操作，具体的可以参考[《git-flow 的工作流程》](<https://www.git-tower.com/learn/git/ebook/cn/command-line/advanced-topics/git-flow>)一文，因为这篇文章写得已经很好了，本文不再进行赘述。
|
||||
|
||||
### 缺陷管理
|
||||
|
||||
|
|
@ -456,6 +531,11 @@ tar -xvf ZenTaoPMS.pro8.5.2.zbox_64.tar
|
|||
6. **[可选]**这个需求有哪些实现方式。
|
||||
7. **[可选]**这些可选的实现方式分别有哪些优缺点。
|
||||
|
||||
#### 其他产品
|
||||
|
||||
除了禅道和GitLab之外，[JIRA](<https://www.atlassian.com/zh/software/jira>)、[Redmine](<https://www.redmine.org/>)、Backlog等也是不错的缺陷管理系统。目前，这些系统大都不仅仅提供了缺陷管理的功能，更多的时候它们可以作为敏捷闭环工具来使用。
|
||||
|
||||
|
||||
### 持续集成
|
||||
|
||||
为了快速的产生高品质的软件，在团队开发中，持续集成（CI）也是一个非常重要的基础。按照经典的软件过程模型（瀑布模型），集成的工作一般要等到所有的开发工作都结束后才能开始，但这个时候如果发现了问题，修复问题的代价是非常具体的。基本上，集成实施得越晚，代码量越大，解决问题就越困难。持续集成将版本控制、自动化构建、代码测试融入到一起，让这些工作变得自动化和可协作。由于其频繁重复整个开发流程（在指定时间内多次pull源代码并运行测试代码），所以能帮助开发者提早发现问题。
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 504 KiB |
Loading…
Reference in New Issue