如何使用git等工具进行项目和项目代码管理

一： 代码管理工具，将本地项目同步至新建的git仓库

对于一个使用过SVN, TFS, GIT等多种常用代码管理工具的开发者来说，个人还是更钟情于GIT。

其中基于git的平台又有很多，gitButket（需翻墙），github（需翻墙），gitlab, 码云（支持git和svn）等。

基于当前情况，这里着重讲讲gitlab这个平台，当然除了平台自己个性化的一些操作，git命令当然是通用于git的各大平台的。

1.安装git环境，注册gitlab账号

这个就不多说了，git官网下载对应的git安装包安装就好了。

gitlab的话在官网注册账号，然后创建一个新项目仓库。

创建项目的时候你可以选择这个项目是属于group还是user，团队项目建议选择group(group需要提前创建),个人项目建议选择user。

项目的可见等级（就是权限）也可以选择：private/internal/public, 当然创建完之后可以修改。

 

创建完毕，页面如下。

现在进行第二步 =》

2.将本地项目文件提交到已经创建好的git项目仓库

对于新的git项目仓库，有三种情况：

1, 创建新版本库(没有本地项目文件夹，也没有之前创建过的git仓库);

2,已存在的文件夹（本地已经有了项目文件夹，但没有同步到git，需要将本地的项目文件夹同步至新创建的git仓库）;

3,已存在的 Git 版本库（本地已经有之前同步到别的git仓库的项目文件夹，需要将它同步到新的git仓库）(或者直接clone新的代码仓库到本地，然后对该仓库的代码进行修改)

通常，我们都是第二种情况。将本地已经存在的项目文件夹同步到新的git仓库，所以这里以第二种来讲解：

1，首先要做的，是对git进行git账号的全局配置“：

git config --global user.name "your userName" // 设置账号名
git config --global user.name "your password" // 设置密码
git config --global user.email "your email account" // 设置账号对应邮箱
git config --global credential.helper store  //保存账号信息到git配置文件
git config --list // 查看git配置信息

2，按顺序执行下列命令：

cd existing_folder //切到项目文件夹
git init //初始化git 生成。在项目文件夹中生成.git文件夹
git remote add origin http://192.168.16.58:9000/chengrong.luo/test.git 关联到远程仓库地址
git add . // 将项目文件夹下所有文件添加进git缓存区，准备commit
git commit -m "Initial commit" // 将所有已经state的待commit的文件commit到已经关联的远程仓库, 并添加注释：Initial commit
git push -u origin master // 将commit 推送到已经关联的远程仓库的master主分支下

同步完成，在gitlab中已经能看到所有推送的记录了：

 

至此，本地项目文件夹已经全部同步到了新建的gitlab仓库。

tips:

(1): 本地项目同步至git仓库之后，本地会生成一个.gitignore文件，在这个文件里，你可以将项目文件夹中不需要同步到git远程仓库的文件或者文件夹标记出来，这样如果你修改了这些文件，它也不会出现在你的commit里面。

(2): 尽量给每个项目添加README.md文件，并且同步到git远程仓库。

 

3. 通过ssh的方式管理git仓库代码

git 管理项目代码通常有两种方式： ssh协议和http协议，http协议上面已经介绍过，下面简单再介绍下ssh协议的方式。

一般在gitlab首页，创建一个新的项目仓库之后，它都会给你上面的提示，为你的项目添加一个ssh key。

一般你clone一个仓库代码到本地，你可以选择http协议的克隆地址，也可以选择ssh的克隆地址。http协议的地址，只要你配置好账号密码和邮箱，就能正常工作了。

但是ssh协议的地址，你需要配置ssh key，也就是ssh 公钥，这是git ssh协议一种比较安全的认证方式。

点击上面的 add a ssh key 链接，进入配置主页。

点击生成密钥，里面有具体的生成密钥的方式。

复制到了生成的密钥字符串之后，把它粘贴到生成密码的主页的密钥输入框，取个标题，然后点击增加密钥，就ok了，现在ssh协议的地址就能使用了。

 

二，使用gitlab和git 命令进行项目分支和代码管理

1. git branch（分支） 管理

当你将一个本地项目完全同步至git远程仓库之后，你就可以开始放心地coding了。

首先，每个项目都默认会有一个名叫‘master’的主分支，所谓主分支，也就是所有git分支的主干。

然后，我们可以base 主分支 master 创建任何分支。

创建分支的原则：

(1): 命令规范

尽量在每个分支前加上类别，一般分为：

feature/ : 功能性分支，当你添加一个功能或者一个功能模块的时候，创建这类分支；

bugfix/ （hotfix）: bug修复性分支，当你需要修复某个或者某几个分支的时候，创建这类分支；

develop/:  单纯的开发分支，比如一些你觉得不算是feature也不算bugfix的分支，就可以在这个分支下；

release/：当项目已经到了release的阶段, 可以创建对应的release版本的分支对不同的release版本进行维护

分支名尽量用关键词描述出该分支的主要用途或目的，如：

feature/loginUIApiImplement

bugfix/loginFailedIssueFixing

 

(2):尽量减少分支之间的依赖

如果是单人开发项目，那么分支比较好管理，一般只需要保持一个或两个分支即可，一个feature分支，一个bugfix分支。

如果是团队开发项目，则尽量避免多人在同一个分支上开发的情况。一个人保持一个或两个分支。

保持分支独立的好处就是减少代码冲突的出现，避免不合适的代码影响其他分支或者主分支

 

(3): 永远尽量避免在master主分支上直接开发，master作为主分支，要保持最稳定。如果有release的版本，那么也避免直接在release分支上直接开发，应当base release创建新分支，然后合并分支到release,然后再决定要不要将release上的改动合并到master上。

 

分支代码管理

(1)创建新分支：

gitlab: 可以基于master或者其他分支创建新的分支，但一般都是基于master创建分支，或者基于release版本分支

gitlab上创建完分支之后，在本地git terminal终端运行： git fetch, 获取创建的分支，然后运行: get checkout 分支名，将当前本地工作分支切换到新创建的分支，在分支上进行工作。

git：当然也可以直接在git terminal终端运行： git branch 分支名 直接在本地创建新分支，当然也是需要基于master(先checkout master)

需要注意的是，这种方法创建的分支，最后在你提交修改的代码之前，你需要发布该分支，运行命令： git publish

tips：

尽量在每次创建分支之前，pull 最新的master主分支上的代码到本地，保证你目前创建的分支已经拥有了master上最新的代码

(2):提交分支代码

在你觉得已经完成某个分支的代码修改或者部分代码修改之后，运行git add . 和 git commit 提交本地修改的代码，然后再运行git push， 将commit push到git远程仓库对应的分支上。

tips:

1，尽量及时提交代码更新到git仓库，意外引起修改的代码丢失或者被回滚

2，尽量在每次commit的时候，填写本次提交更新的内容描述

 

(3):合并分支到master主分支

在你已经完成了该分支的所有修改或者阶段性的修改之后，且经过初步测试之后，及时合并分支至主分支。

gitlab: 创建pull request, 将子分支以pull请求的方式，merge到master

选择来源分支，当然就是你想要合并的那个分支，再选择目标分支，默认就是master了,

点击比较分支后继续，进入pull request详情页面。

填写pull request 标题和描述，然后再关注一下下面的几个可选项：

其中指派这个选项值得一提，如果是团队开发项目，一般这个指派可以指派给相关的项目同事，让他们对你即将合并到主分支的代码进行review和comment，如果对方觉得你提交的代码有问题，或者代码会影响到主分支的其他功能，添加原因之后可以拒绝你的pull 请求，你需要重新对有问题的代码进行优化，然后再次提交你的代码。你可以删除之前的pull request，新建一个pull request，再次指派给相关人员，也可以在原来的pull request，让相关人员第二次审查你改进的代码，再决定该pull  reqeust 能不能合并到master。

当然，你还可以在这个页面再次修改目标分支。

特别地，如果你在此次pull request 合并完之后，不再需要再这个分支上工作了，建议勾选选项：接收合并请求后删除来源分支。

这样，保持分支树的干净和简洁。

点击提交合并请求之后，被你指派过的同事，就能在他的gitlab上收到通知，然后开始review你提交的代码。

这里，可能会碰到的问题：代码冲突。

如果有新的代码在你之前合并到了master主分支，且该代码修改的地方和你在这次pull request中要合并的代码有重叠的地方，那就会产生代码冲突，那么你需要先解决冲突才进行pull request的合并操作。

你可以按照如下步骤解决冲突，然后将解决完冲突的代码重新提交：

当然，你还可以在本地使用git图形化工具（推荐sourceTree）或者IDE自带git插件进行手动解决代码冲突。

其实，我们是最不想在合并pull reqeust的时候看到代码冲突这种情况出现的，那么如何避免这种情况出现呢？

1：在你推送完本地代码更新到远程git仓库对应的分支之后，在创建pull request 之前，我们先进行 git rebase master 的操作，当然你要保证已经获取到了最新的master到本地。

也就是说，你把别人已经提交到master的新代码，也获取到你的分支上来，或者换一种说法，把你在分支上的修改提交到已经被别人修改过的master上去，但是不会改动master，而是基于你自己的分支。

这个时候，也有可能会存在冲突，但是没关系，这个时候你在本地解决掉冲突，然后 git add .   再git rebase --continue，这样解决冲突之后的你的分支，已经可以合并到master了，合并的过程中不可能再产生冲突。

注意：如果你在手动解决冲突的时候由于各种原因没有解决成功，导致重新提交的代码不对，没关系，你随时可以执行 git rebase --abort 种植本次git rebase， 再重新执行 git rebase。

执行 git rebase的操作还有一个很重要的好处就是， 保证分支的合并历史不分叉，在一条直线上。

2：如果不可避免地，多个人同时工作在了一个分支上，那么你需要在每次git commit之后，执行git pull， 有冲突再解决冲突，然后再git push。或者你可以在git commit之后，直接执行 git pull --rebase，这样能保证分支的提交历史树在一个直接上，不会存在分叉。

所以，尽量做完上面的1或者2的步骤之后，再进行分支的合并操作。

 

git: 当然，纯git 命令操作，进行分支的合并也是可以的。

git commit 之后，如果有别人和你工作在同一个分支

再执行 git pull --rebase（有冲突解决冲突，然后 git push）;

如果有别人在master上在你之前提交过，执行git rebase master, 有冲突解决冲突， 再git rebase --continue。

最后:

git checkout master

git merge feature

 

总结：

1，尽量避免多人在同一个分支工作

2，尽量在合并分支之前，获取到分支和master最新的代码

3，尽量让分支树在一条直线上

 

tips：

可以使用git cherry pick , 将某个分支上的某个commit 复制到别的也需要应用此次commit的分支上

 

历史提交/合并请求查看

gitlab上，你可以查看所有提交历史，也可以查看所有创建过的pull requst，进行代码的回滚查看。如果碰到某个bug重复出现或者某些已经有的功能突然缺失，可以通过查看提交历史或者历史 pull请求，快速定位到有问题的提交历史上。

 

三.使用sourceTree(Git GUI)进行代码管理

sourceTree是一个非常好的Git GUI工具，而且是免费的。基本上可以操作任何git命令，也可以非常简便地管理远程和本地的仓库分支，清晰的查看分支树，完成整个git工作流。

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

不过，注册sourceTree，一般都需要绑定对应的bitbucket账号，但是bitbucket又需要VPN。

所以注册sourceTree的时候，需要跳过绑定bitbucket的步骤进行注册。

方法：

关闭注册窗口，打开sourceTree安装目录 \AppData\Local\Atlassian\SourceTree，创建accounts.json文件，并修改accounts.json内容如下：

[
  {
    "$id": "1",
    "$type": "SourceTree.Api.Host.Identity.Model.IdentityAccount, SourceTree.Api.Host.Identity",
    "Authenticate": true,
    "HostInstance": {
      "$id": "2",
      "$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountInstance, SourceTree.Host.AtlassianAccount",
      "Host": {
        "$id": "3",
        "$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountHost, SourceTree.Host.AtlassianAccount",
        "Id": "atlassian account"
      },
      "BaseUrl": "https://id.atlassian.com/"
    },
    "Credentials": {
      "$id": "4",
      "$type": "SourceTree.Model.BasicAuthCredentials, SourceTree.Api.Account",
      "Username": "",
      "Email": null
    },
    "IsDefault": false
  }
]

接着 \AppData\Local\Atlassian这个目录下，

第二个目录，接着进入"3.1.3.3158"目录，打开user.config文件，在里面加入六行代码：

<setting name="AgreedToEULA" serializeAs="String">
   <value>True</value>
</setting>
<setting name="AgreedToEULAVersion" serializeAs="String">                        
   <value>20160201</value>
</setting>

保存，然后重启sourceTree，打开之后自动就能跳过注册界面了。

如果再弹出Mercurial询问窗口，可以根据实际情况做相应的选择，比如使用默认选项下载Mercurial，或者使用第四个选项“我不想使用Mercurial”。

 

四：使用Jira, 禅道等协同办公平台进行项目管理

曾经用过三个平台进行bug管理： Woktile, Jira, 禅道，其中最好用的是Jira，但是是国外的平台，所以也需要VPN。

所以主要还是说说禅道。

1，任务创建

一般一个项目创建之后，项目负责人或者其他相关人员可以进行根据需求或者功能模块，创建相关的任务。

一个任务可以是一个大的功能模块，也可以是一个小接口的开发，尽量让任务之间相对独立，这样不同的任务可以分配给不同的人员开发。

创建任务的时候，可以关联相关功能需求；

可以添加相关附件图片等，让接收任何的人清楚该任务要达到 的目的和效果；

也可以创建任务的优先级，这样开发人员可以根据任务优先级顺序选择任务进行开发。

2, bug处理

一般bug由测试人员创建，然后bug指派给相关开发人员。

开发人员领到bug之后，在我的地盘-我的bug看到bug数量会增加，然后在‘指派我的bug’面板中，看到具体的bug列表。开发人员可以根据bug优先级去激活bug。

如果开发人员对bug没有疑问，可以点击确认bug，并在备注框中输入你针对该bug给出的解决方案。

如果你对bug有疑问，可以对bug进行编辑，添加你的疑问，抄送给提bug的测试人员。

如果你觉得bug不该指派给你，你可以指派回相关测试人员或者你觉得该负责解决该bug的开发人员，并在备注中说明理由。

在你解决完bug之后，你可以点击已解决，确认你的解决方案，必要时上传Bug解决完之后的效果图。

再有必要，你还可以贴出你解决该bug的pulll request的链接，这样如果相关人员对该bug的解决方案有疑问，也可以直接浏览你解决该bug时修改的代码。

 

3，看板

你可以在项目有的看板页面，查看所有bug的状态。

 

五，使用jenkins对项目工程自动化部署

Jenkins是一个开源的、可扩展的持续集成、交付、部署（软件/代码的编译、打包、部署）的基于web界面的平台。允许持续集成和持续交付项目，无论用的是什么平台，可以处理任何类型的构建或持续集成。

官网：https://jenkins.io/ 官方文档：https://jenkins.io/doc/

 

六，接口可视化管理平台

1，OpenApi

2，Swagger

3，YApi

4，EoLinker

 

七，开发人员常用社区推荐

1，官网+官方文档  （这个是最重要的，接触任何一个新平台或者新技术，一定要从官方文档入手，开发过程中很多疑难杂症觉得很难解决，往往就藏在文档中被你忽略的角落）

2，Github 

3，Stack Overflow

4，segmentfault

5，CSDN

6, 平台或技术自有的社区或论坛

等，欢迎补充。