设置HTTPS密码
HTTPS密码是使用HTTPS协议和代码托管服务端交互的凭证，设置步骤如下：
1. 进入代码托管首页，单击“设置我的HTTPS密钥”，显示“HTTPS密钥管理”页 面。
a. 如果您是第一次进行设置，则输入2次HTTPS密码保存即可。
b. 如果您不是第一次进行设置，单击“修改”，需要输入邮箱验证码，重新设 置新密码“保存”即可。
1.3 Git 本地研发场景
背景介绍
在DevCloud云端创建一个README文件的空仓库，然后架构师或者项目负责人需要把 本地框架代码推送到这个空仓库，最后，其他开发人员将云端架构代码克隆到本地，
进行增量应用开发。
说明
● Git代码传输支持SSH和HTTPS两种传输协议，本节基于SSH传输协议进行的操作。
● 如果想使用HTTPS方式，直接下载HTTPS密码，当克隆、推送代码时直接输入HTTPS用户名 密码即可。
● 同一仓库SSH和HTTPS的地址不同。
推送架构代码
1. 打开本地框架代码，确保根目录名（DevCloud）与云端创建的代码仓库名一致，
在根目录下右键打开Git bash终端，如下图所示。
2. 推送本地代码到云端。
在当前Git Bash终端依次输入如下命令：
a. 初始化本地代码仓库，执行该命令后，在“D:/code/DevCloud/”下多了一个
“.git”文件夹。
$ git init
b. 关联云端代码仓库。
$ git remote add origin CodeHubUrl
仓库地址“CodeHubUrl”如下图所示单击红色方框处获取。
c. 推送代码到云仓库。
$ git add .
$ git commit -m "init project"
$ git branch --set-upstream-to=origin/master master
$ git pull --rebase
$ git push
克隆代码
开发人员在本地准备克隆云端架构代码。
1. 在准备把代码克隆到的目标文件夹下，右键打开Git bash终端，如下图所示。
2. 克隆仓库，URL地址如下图所示单击红色方框处获取。
$ git clone CodeHubUrl //将代码从远端仓库clone到本地
代码提交
一次修改被成功提交到远端仓库会历经四个阶段：“1本地工作区 > 2缓存区 > 3版本 库 > 4远端版本库”。
通过执行相应的Git命令，文件在这四个区域跳转，并呈现不同的状态，如下图所示。
主要涉及如下三步操作：
1. #git add/rm filename //将新增、修改或者删除的文件增加到暂存区 2. #git commit –m “commit message” //将已暂存的文件提交到本地仓库 3. #git push //将本地代码仓库修改推送到远端仓库
分支操作
● 新建分支
Git新建分支的本质就是创建一个指向最后一次提交的可变指针，所以，Git分支的 创建不是复制版本库的内容，仅仅是新建了一个指针，它以40个字符长度SHA-1 字串形式保存在文件中。
#git branch branchName commitID
基于commitID即某一个全球版本号拉出新分支，如果没有commitID则基于当前 分支的HEAD拉出新分支。
例如，新建feature分支，执行的命令为git branch feature，如下图所示。
● 切换分支 命令如下。
#git checkout branchName
例如，切换到feature分支，执行的命令为git checkout feature，如下图所示。
无论哪种工作流都会涉及到分支合并（把一个分支中的修改整合到当前分支），
主要有两种方法：三方合并（merge） 和衍合（rebase）。通过对同一种场景进 行不同操作体会两种合并方法的区别。
场景：master分支新增了C4节点， hotfix分支新增了C3节点，现将hotfix分支合 并到master分支：
a. 三方包括hotfix新增节点C3，master新增节点C4，以及两者的共同祖先节点 C2。这种合并操作简单，但新增合并节点C5，形成了环形，版本记录可读性 差，如下图所示。
#git checkout master
#git merge hotfix
b. 衍合先将master分支新增节点C4以补丁形式保存在.git/rebase目录中，然后 同步hotfix分支最新代码，再应用补丁C4’，如下图所示。
#git checkout master
#git rebase hotfix
● 冲突解决
a. 场景一：两个合并分支修改了同一行代码
解决方法：
什么是Git工作流？你可以理解为代码管理的分支策略，它不仅仅是版本管理范畴，更 服务于项目流程管理和团队协同开发。所以，有必要制定适合自己研发场景的工作 流。
下面介绍四种工作流的工作方式、优缺点，以及使用中的一些注意事项。
● 集中式工作流
● 功能分支工作流
● Gitflow工作流（Devcloud推荐）
● Forking工作流
研发团队可以根据实际研发场景制定合理的工作流，能有效提高项目管理水平和团队 协同开发能力， 并通过CodeHub平台，高效、安全的管理代码资产，将更多的精力集 中在业务开发上，实现持续集成、持续交付和快速迭代的目标。
1.4.2 集中式工作流
集中式工作流适合5人左右小开发团队，或是刚从SVN工具转型为Git的团队，它只有 一个默认的maste分支（相当于svn的trunk主分支），所有人的修改都是在master分 支上进行的。但是，这种工作流无法充分发挥git优势和多人协同，不推荐使用。
工作方式
开发人员将master分支从中央仓库克隆到本地，修改完成后再推送回中央仓库master 分支。
● master分支提交频繁。
● master分支不稳定，不利于集成测试。