首先需要强调的是，HTTPS URLs和SSH URLs对应的是两套完全独立的权限校验方式，主要的区别就是HTTPS URLs采用账号密码进行校验，SSH URLs采用SSH秘钥对进行校验。平时使用的时候我们可以根据实际情况，选择一种即可。
HTTPS URLs
GitHub官方推荐采用HTTPS URLs的方式，因为该种方式适用面更广（即使在有防火墙或代理的情况下也同样适用），使用更方便（配置更简单）。
采用HTTPS URLs地址clone/fetch/pull/push仓库时，事先无需对本地系统进行任何配置，只需要输入GitHub的账号和密码即可。不过如果每次都要手动输入账号密码，也是一件很繁琐的事情。
好在已经有多个机制可以让 *** 作不用这么麻烦。
在Mac系统中，在启用Keychain机制的情况下，首次输入GitHub账号密码后，认证信息就会自动保存到系统的Keychain中，下次再次访问仓库时就会自动读取Keychain中保存的认证信息。
在非Mac系统中，虽然没有Keychain机制，但是Git提供了credential helper机制，可以将账号密码以cache的形式在内存中缓存一段时间（默认15分钟），或者以文件的形式存储起来（~/.git-credentials）。当然，Mac系统如果不启用Keychain机制，也可以采用这种方式。
# cache credential in memory
$ git config --global credential.helper cache
# store credential in ~/.git-credential
$ git config --global credential.helper store
在credential.helper设置为store的情况下，首次输入GitHub账号密码后，就会自动保存到~/.git-credentials文件中，保存形式为https://user:pass@github.com；下次再次访问仓库时就会自动读取~/.git-credentials中保存的认证信息。
另一个需要说明的情况是，如果在GitHub中开启了2FA（two-factor authentication），那么在本地系统中输入GitHub账号密码时，不能输入原始的密码（即GitHub网站的登录密码），而是需要事先在GitHub网站中创建一个Personal access token，后续在访问代码仓库需要进行权限校验的时候，采用access token作为密码进行输入。
SSH URLs
除了HTTPS URLs，还可以采用SSH URLs的方式访问GitHub代码仓库。
采用SSH URLs方式之前，需要先在本地计算机中生成SSH keypair（秘钥对，包括私钥和公钥）。默认情况下，生成的秘钥位于$HOME/.ssh/目录中，文件名称分别为id_rsa和id_rsa.pub，通常无需修改，保持默认即可。不过，如果一台计算机中存在多个秘钥对，就需要修改秘钥文件名，名称没有强制的命名规范，便于自己辨识即可。
如下是创建秘钥对的过程。
➜ ssh-keygen -t rsa -b 4096 -C "mail@debugtalk.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/Leo/.ssh/id_rsa): /Users/Leo/.ssh/debugtalk_id_rsa
Enter passphrase (empty for no passphrase): <myPassphrase>
Enter same passphrase again: <myPassphrase>
Your identification has been saved in /Users/Leo/.ssh/debugtalk_id_rsa.
Your public key has been saved in /Users/Leo/.ssh/debugtalk_id_rsa.pub.
The key fingerprint is:
SHA256:jCyEEKjlCU1klROnuBg+UH08GJ1u252rQMADdD9kYMo mail@debugtalk.com
The key's randomart image is:
+---[RSA 4096]----+
|+*BoBO+. |
|o=oO=** |
|++E.*+o. |
|+ooo +o+ |
|.o. ..+oS. . |
| . o. . o |
| .. |
| . . |
|.. |
+----[SHA256]-----+
在创建秘钥的过程中，系统还建议创建一个名为passphrase的东西，这是用来干嘛的呢？
首先，单独采用密码肯定是不够安全的。如果密码太简单，那么就很容易被暴力破解，如果密码太复杂，那么用户就很难记忆，记录到小本子里面更不安全。
因此，SSH keys诞生了。SSH秘钥对的可靠性非常高，被暴力破解的可能性基本没有。不过，这要求用户非常谨慎地保管好私钥，如果别人使用你的计算机时偷偷地将你的私钥拷走了，那么就好比是别人拿到了你家里的钥匙，也能随时打开你家的门。
基于以上情况，解决办法就是在SSH keys之外再增加一个密码，即passphrase。只有同时具备SSH private key和passphrase的情况下，才能通过SSH的权限校验，这就大大地增加了安全性。当然，这个passphrase也不是必须的，在创建秘钥对时也可以不设置passphrase。
另外，如果每次权限校验时都要输入passphrase，这也是挺麻烦的。好在我们不用再担心这个问题，因为ssh-agent可以帮我们记住passphrase，Mac系统的Keychain也可以记住passphrase，这样我们在同一台计算机中就不用重新输入密码了。
秘钥对创建好以后，私钥存放于本地计算机（~/.ssh/id_rsa），将公钥（~/.ssh/id_rsa.pub）中的内容添加至GitHub账户。
# copy the contents of id_rsa.pub to the clipboard
➜ pbcopy <~/.ssh/id_rsa.pub
# paste to GitHub
# Login GitHub, 【Settings】->【SSH and GPG keys】->【New SSH Key】
不过，如果此时检测本地计算机与GitHub的连接状态，会发现系统仍提示权限校验失败。
➜ ssh -T git@github.com
Permission denied (publickey).
这是因为在本地计算机与GitHub建立连接的时候，实际上是本机计算机的ssh-agent与GitHub服务器进行通信。虽然本地计算机有了私钥，但是ssh-agent并不知道私钥存储在哪儿。因此，要想正常使用秘钥对，需要先将私钥加入到本地计算机的ssh-agent中（添加过程中需要输入passphrase）。
# start ssh-agent in the background
➜ eval "$(ssh-agent -s)"
Agent pid 78370
➜ ssh-add ~/.ssh/id_rsa
Enter passphrase for /Users/Leo/.ssh/id_rsa: <myPassphrase>
Identity added: /Users/Leo/.ssh/id_rsa (/Users/Leo/.ssh/id_rsa)
添加完成后，就可以查看到当前计算机中存储的密钥。
➜ ssh-add -l
4096 SHA256:xRg49AgTxxxxxxxx8q2SPPOfxxxxxxxxRlBY /Users/Leo/.ssh/id_rsa (RSA)
再次检测本地计算机与GitHub的连接状态，校验就正常通过了。
➜ ssh -T git@github.com
Hi djileolee! You've successfully authenticated, but GitHub does not provide shell access.
后续再进行clone/fetch/pull/push *** 作时，就可以正常访问GitHub代码仓库了，并且也不需要再重新输入账号密码。
而且，将私钥加入ssh-agent后，即使删除私钥文件，本地计算机仍可以正常访问GitHub代码仓库。
➜ rm -rf ~/.ssh
➜ ssh-add -l
4096 SHA256:xRg49AgTxxxxxxxx8q2SPPOfxxxxxxxxRlBY /Users/Leo/.ssh/id_rsa (RSA)
➜ ssh -T git@github.com
The authenticity of host 'github.com (192.30.252.130)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.252.130' (RSA) to the list of known hosts.
Hi djileolee! You've successfully authenticated, but GitHub does not provide shell access.
只有执行ssh-add -D或ssh-add -d pub_key命令，将私钥从ssh-agent删除后，认证信息才会失效。
➜ ssh-add -d ~/.ssh/id_rsa.pub
Identity removed: /Users/Leo/.ssh/id_rsa.pub (mail@debugtalk.com)
➜ ssh-add -l
The agent has no identities.
➜ ssh -T git@github.com
Permission denied (publickey).
同时使用多个GitHub账号
熟悉了HTTPS URLs和SSH URLs这两种校验方式之后，我们再来看之前遇到的问题。要想在一台计算机上同时使用多个GitHub账号访问不同的仓库，需要怎么做呢？
为了更好地演示，现假设有两个GitHub账号，debugtalk和djileolee，在两个账号中各自有一个仓库，debugtalk/DroidMeter和DJIXY/MobileStore（公司私有库）。
前面已经说过，HTTPS URLs和SSH URLs对应着两套独立的权限校验方式，因此这两套方式应该是都能单独实现我们的需求的。
不过在详细讲解Git权限校验的问题之前，我们先来回顾下Git配置文件的优先级。
Git配置存储位置及其优先级
Unix-like系统中，保存Git用户信息的主要有3个地方（Mac系统多一个Keychain）：
/etc/gitconfig：存储当前系统所有用户的git配置信息，使用带有--system选项的git config时，配置信息会写入该文件；
~/.gitconfig或~/.config/git/config：存储当前用户的git配置信息，使用带有--global选项的git config时，配置信息会写入该文件；
Keychain Access：在开启Keychain机制的情况下，进行权限校验后会自动将账号密码保存至Keychain Access。
仓库的Git目录中的config文件（即repo/.git/config）：存储当前仓库的git配置信息，在仓库中使用带有--local选项的git config时，配置信息会写入该文件；
在优先级方面，以上4个配置项的优先级从上往下依次上升，即repo/.git/config的优先级最高，然后Keychain Access会覆盖~/.gitconfig中的配置，~/.gitconfig会覆盖/etc/gitconfig中的配置。
基于SSH协议实现多账号共存
先来看下如何采用SSH URLs实现我们的需求。
在处理多账号共存问题之前，两个账号均已分别创建SSH秘钥对，并且SSH-key均已加入本地计算机的ssh-agent。
➜ ssh-add -l
4096 SHA256:lqujbjkWM1xxxxxxxxxxG6ERK6DNYj9tXExxxxxx8ew /Users/Leo/.ssh/dji_id_rsa (RSA)
4096 SHA256:II2O9vZutdQr8xxxxxxxxxxD7EYvxxxxxxbynx2hHtg /Users/Leo/.ssh/id_rsa (RSA)
在详细讲解多账号共存的问题之前，我们先来回想下平时在Terminal中与GitHub仓库进行交互的场景。
➜ DroidMeter git:(master) git pull
Already up-to-date.
➜ DroidMeter git:(master) touch README.md
➜ DroidMeter git:(master) ✗ git add .
➜ DroidMeter git:(master) ✗ git commit -m "add README"
➜ DroidMeter git:(master) git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 310 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@debugtalk:debugtalk/DroidMeter.git
7df6839..68d085b master ->master
在 *** 作过程中，本地计算机的ssh-agent与GitHub服务器建立了连接，并进行了账号权限校验。
当本地计算机只有一个GitHub账号时，这个行为并不难理解，系统应该会采用这个唯一的GitHub账号进行 *** 作。那如果本地计算机中有多个Github账号时，系统是根据什么来判断应该选择哪个账号呢？
实际情况是，系统没法进行判断。系统只会有一个默认的账号，然后采用这个默认的账号去 *** 作所有的代码仓库，当账号与仓库不匹配时，就会报权限校验失败的错误。
那要怎样才能让系统正确区分账号呢？这就需要我们手动进行配置，配置文件即是~/.ssh/config。
创建~/.ssh/config文件，在其中填写如下内容。
# debugtalk
Host debugtalk
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa
# DJI
Host djileolee
HostName github.com
User git
IdentityFile ~/.ssh/dji_id_rsa
要理解以上配置文件的含义并不难，我们可以对比看下两个项目的SSH URLs：
git@github.com:debugtalk/DroidMeter.git
git@github.com:DJISZ/Store_Android.git
其中，git是本地ssh-agent与GitHub服务器建立SSH连接采用的用户名（即User），http://github.com是GitHub服务器的主机（即HostName）。
可以看出，如果采用原始的SSH URLs，由于User和HostName都相同，本地计算机并不知道应该采用哪个SSH-key去建立连接。
因此，通过创建~/.ssh/config文件，在Host中进行区分，然后经过CNAME映射到HostName，然后分别指向不同的SSH-key，即IdentityFile。由于HostName才是真正指定GitHub服务器主机的字段，因此这么配置不会对本地ssh-agent连接GitHub主机产生影响，再加上Host别名指向了不同的SSH-key，从而实现了对两个GitHub账号的分离。
配置完毕后，两个GitHub账号就可以通过Host别名来进行区分了。后续再与GitHub服务器进行通信时，就可以采用Host别名代替原先的http://github.com。例如，测试本地ssh-agent与GitHub服务器的连通性时，可采用如下方式：
➜ ssh -T git@debugtalk
Hi debugtalk! You have successfully authenticated, but GitHub does not provide shell access.
➜ ssh -T git@djileolee
Hi djileolee! You have successfully authenticated, but GitHub does not provide shell access.
可以看出，此时两个账号各司其职，不会再出现混淆的情况。
不过，我们还遗漏了很重要的一点。在本地代码仓库中执行push/pull/fetch等 *** 作的时候，命令中并不会包含Host信息，那系统怎么知道我们要采用哪个GitHub账号进行 *** 作呢？
答案是，系统还是没法判断，需要我们进行配置指定。
显然，不同的仓库可能对应着不同的GitHub账号，因此这个配置不能配置成全局的，而只能在各个项目中分别进行配置，即repo/.git/config文件。
配置的方式如下：
在debugtalk/DroidMeter仓库中：
➜ git remote add origin git@debugtalk:debugtalk/DroidMeter.git
在DJIXY/MobileStore.git仓库中：
➜ git remote add origin git@djileolee:DJIXY/MobileStore.git
配置的原理也很容易理解，就是将仓库的Host更换为之前设置的别名。添加完毕后，后续再在两个仓库中执行任何git *** 作时，系统就可以选择正确的SSH-key与GitHub服务器进行交互了。
基于HTTPS协议实现多账号共存
再来看下如何采用HTTPS URLs实现我们的需求。
有了前面的经验，我们的思路就清晰了许多。采用HTTPS URLs的方式进行Git权限校验后，系统会将GitHub账号密码存储到Keychain中（Mac系统），或者存储到~/.git-credentials文件中（Git credential helper）。
不管是存储到哪里，我们面临的问题都是相同的，即如何在代码仓库中区分采用哪个GitHub账号。
配置的方式其实也很简单：
在debugtalk/DroidMeter仓库中：
➜ git remote add origin https://debugtalk@github.com/debugtalk/DroidMeter.git
在DJIXY/MobileStore.git仓库中：
➜ git remote add origin https://djileolee@github.com/DJIXY/MobileStore.git
配置的原理也很容易理解，将GitHub用户名添加到仓库的Git地址中，这样在执行git命令的时候，系统就会采用指定的GitHub用户名去Keychain或~/.git-credentials中寻找对应的认证信息，账号使用错乱的问题也就不复存在了。
公司切入Gitlab来管理代码已经有一年多了，其中遇到很多权限问题，如没有权限clone、没有权限提交代码等等，这里做个总结. 权限分为访问权限和行为权限两个层次.访问权限 - Visibility Level
这个是在建立项目时就需要选定的，主要用于决定哪些人可以访问此项目，包含3种
Private - 私有，只有属于该项目成员才有原先查看
Internal - 内部，用个Gitlab账号的人都可以clone
Public - 公开，任何人可以clone
行为权限
在满足行为权限之前，必须具备访问权限（如果没有访问权限，那就无所谓行为权限了），行为权限是指对该项目进行某些 *** 作，比如提交、创建问题、创建新分支、删除分支、创建标签、删除标签等.
角色
Gitlab定义了以下几个角色:
Guest - 访客
Reporter - 报告者可以理解为测试员、产品经理等，一般负责提交issue等
Developer - 开发者负责开发
Master - 主人一般是组长，负责对Master分支进行维护
Owner - 拥有者一般是项目经理
权限
不同角色，拥有不同权限，下面列出Gitlab各角色权限
1. 工程权限
行为 Guest Reporter Developer Master Owner
创建issue ✓ ✓ ✓ ✓ ✓
留言评论 ✓ ✓ ✓ ✓ ✓
更新代码 ✓ ✓ ✓ ✓
下载工程 ✓ ✓ ✓ ✓
创建代码片段 ✓ ✓ ✓ ✓
创建合并请求 ✓ ✓ ✓
创建新分支 ✓ ✓ ✓
提交代码到非保护分支 ✓ ✓ ✓
强制提交到非保护分支 ✓ ✓ ✓
移除非保护分支 ✓ ✓ ✓
添加tag ✓ ✓ ✓
创建wiki ✓ ✓ ✓
管理issue处理者 ✓ ✓ ✓
管理labels ✓ ✓ ✓
创建里程碑 ✓ ✓
添加项目成员 ✓ ✓
提交保护分支 ✓ ✓
使能分支保护 ✓ ✓
修改/移除tag ✓ ✓
编辑工程 ✓ ✓
添加deploy keys ✓ ✓
配置hooks ✓ ✓
切换visibility level ✓
切换工程namespac
对gitlab的使用主要从两个角度去分析，一个是管理员，一个是开发提交者。
1.1 初始配置
浏览器访问 http://服务器IP:11000
第一次访问会默认以root管理员用户登陆，需要输入两遍密码。
登陆后，可以看到，gitlab中主要围绕着以下几个概念进行 *** 作：
group 团队
如果是作为个人使用，那么使用root用户创建project就可以实现上传下载代码了。
如果是小团队项目，就需要创建group，并在group中创建projects，添加user到group中，并给用户相应的权限。
1.1.1 关闭系统注册功能
为了便于管理，可以选择关闭gitlab的注册功能.
在主界面左边条依次选择 **Settings ->General ->Sign-up restrictions** ,点击 Expand 按钮，在 **Sign-up restrictions** 选项处将勾点掉，下拉点击 **Save changes** 就可以了。
1.1.2 修改网站logo
为了让我们的gitlab看起来更符合项目，可以对网站的logo进行调整，在 **Appearance** 中对 导航条图标（Navigation bar）、网站图标（Favicon）、登陆页图标（Sign in/Sign up pages）进行设置。
1.2 代码管理
1.2.1 团队协作方式
gitlab团队协作主要有两种方式：
使用fork
* 项目负责人在gitlab上新建一个项目，并分享URL给开发人员
* 开发人员在负责人的gitlab项目页面上点击“fork”按钮，将此项目fork到自己的gitlab上，这相当于是从负责人那拷贝了一份项目副本，无论开发人员如何修改代码都不会影响负责人那master分支上的代码
* 然后开发人员可以根据自己的项目分工，像对待普通项目一样做clone、add、commit、push等 *** 作
* 如果开发人员人为一个小模块做好了，可以点击“**New Merge Request**”按钮，向负责人发送代码合并请求，要合并的代码文件也会以列表的形式同时发送给负责人，此时负责人会看到开发人员的请求，经审核如果代码没问题则会合并模块，并向开发人员发送确认合并的通知
不使用fork
1. 负责人为开发人员分别创建开发分支（namedev_branch）
* 项目负责人在gitlab上新建一个项目，并为每一个开发人员创建一个开发分支（namedev_branch）
* 开发人员clone项目之后，经git branch检查发现本地只有master分支，因此也需要把属于自己的开发分支也一起获取下来
>`git fetch origin namedev_branch:namedev_branch`
>`#拉取远程的一个叫namedev_branch的分支，并在本地创建一个叫namedev_branch的分支和远程的分支匹配`
* 切换到namedev_branch分支
>`git checkout namedev_branch`
* 之后的 *** 作如同对待普通项目一样
>`git add hello.py`
>`git commit -m "add hello.py"`
>`git push -u origin namedev_branch #需要注意，是push到远程的namedev_branch分支`
~~这个方式感觉有风险，项目成员要注意自己的branch，很容易因为忽略branch直接向master提交变更，对代码管理会添加麻烦~~
2. 负责人不为开发人员分别创建开发分支 （开发者自己创建）
* 虽然项目负责人不分别为开发人员创建分支，但是需要把他们添加到一个group中，否则开发人员在向项目push自己的开发分支时遇到权限错误
* 开发人员在把项目clone之后需要为自己新建一个开发分支（namedev_branch），因为经由git branch查看发现本地只有master分支
>`git branch namedev_branch #新建分支`
>`git checkout namedev_branch #切换到开发分支`
>`git push origin namedev_branch #将新建的开发分支push到远程项目上`
* 之后的 *** 作如同对待普通项目一样
>`git add hello.py`
>`git commit -m "add hello.py"`
>`git push -u origin namedev_branch #需要注意，是push到远程的namedev_branch分支`
之后，两种方式下项目负责人都可以在项目的gitlab主页上看到每个开发人员的工作进度，并考虑何时merge开发人员的分支到master分支上以完善项目。
所有成员包括项目负责人除克隆、修改、提交代码这些 *** 作外，其它merge、建立分支等 *** 作都在Gitlab网页端进行。
所有分支中，master分支为主干分支，此分支的代码不允许直接修改，只能由其它分支（一般只由develop分支）发出merge请求，经项目管理员代码审查通过后合并代码，普通开发者无权执行push、merge等 *** 作，确保此分支任何时候、任何tag处导出的项目代码都是稳定可正常运行的代码；develop分支为开发分支，可以接受由其它分支发起的merge请求，同样只能经项目管理员代码审查通过后予以合并。
1.2.2 团队初始化
假设我们项目组分为两个组team1、team2，每个组有不同的组员和对应的不同的子项目,对项目组用户开放项目的访问，使用fork方式来做代码的更新和提交。
因此我们的gitlab的架构大概是这样的：
1. 创建Group，在主界面上方的加号选择**New Group**,创建Group只需要填写 Group path 、Group name、Description 几个选项就可以了。Visibility Level选项选择 Private-私有仓库
2. 创建user，对需要加进来的团员，由管理员负责给他们创建相应的用户，创建用户需要填写合法的Email地址，正常情况下会向这个Email发送登陆的初始连接，但是如果不方便的话，也可以在创建后由管理员修改这个user的初始登陆密码。
3. 选中Group添加相应的user，user的角色分以下几种：Guest、Reporter、Developer、Maintainer、owner，基本上我们只会用到guest和developer两种。
4. 在Group中创建project，选中Subgroup，点击 New project 来创建新的项目。
5. 项目完成创建后，相应的团队成员也可以使用fork来获取项目的内容,fork后属于成员自己的项目的git地址是不一样的，这个一定要注意，后面提交代码都是提交到这个fork项目的地址，只有在网页端发起merge request 以及从master更新fork项目时才会用到主项目
1.2.3 代码提交管理
当有新的代码提交请求时，项目负责人可以通过查看merge requests获取到来自fork或者branch的合并请求：
接受合并时，可以选择 Open in Web IDE 来检查审核变更的内容，确认没问题后点击Merge按钮来合并。
1.2.4 活跃度查询
右边条选择 Project ->Activity 可以看到push、merge、issue、comment（讨论）等信息
选择 Cycle Analytics 可以看到图形化的分析内容，这部分需要有足够的数据支持，还需要好好研究下。
>Cycle Analytics measures the time it takes to go from an idea to production for each project you have.
>周期分析功能是监测从每个项目一个想法到产品所需的时间。
## 项目开发方式 issue+milestone+label
如何结合gitlab提供的这些功能来完整的梳理、管理一个产品、或者一个模块的开发方式
定义一个开发任务从开始如何分配到最后如何标识完成的过程。
这一块是用好gitlab的重点，否则就是用gitlab来做一个简单的代替svn的版本管理工具
2.1 fork项目
项目成员首先利用浏览器进入gitlab的系统后，查看自己的group和project，并fork自己需要参与开发的project。
>在project的detail界面中点击fork按钮。
fork时会提示选择**Namespace**，这个选择是用来决定这个工程所属的，可以选Users,或者选择Groups，这个会影响到后面工程的url，项目成员都统一选择users本人的命名空间就可以了。
2.2 获取fork项目
项目内容获取主要使用git客户端工具来实现，项目开发人员首先要在本机安装git客户端软件，[下载地址](https://www.git-scm.com/)
安装时基本都采用默认设置就可以了。
安装完成后我们主要使用Git Bash命令行工具来工作。
2.3 设置账户信息
设置修改本地对应的gitlab用户和邮箱。
2.4 配置ssh连接信息 （windows下没调成功）
1. 创建 SSH密钥
通过下面的命令生成密钥，将命令中的YOUR_EMAIL@YOUREMAIL.COM替换为注册Gitlab时用的Email地址。
`ssh-keygen -t rsa -C "duwj@gitlab.com"`
注意：Enter passphrase (empty for no passphrase) :时，可以直接按两次回车键输入一个空的 passphrase；也可以选择输入一个 passphrase 口令，如果此时你输入了一个passphrase，请牢记，之后每次提交时都需要输入这个口令来确认。
2. 获取公钥内容
SSH密钥生成结束后，根据提示信息找到SSH目录（通常ssh密钥保存路径均为~/.ssh 目录），会看到私钥id_rsa和公钥id_rsa.pub这两个文件，不要把私钥文件id_rsa的信息透露给任何人。
用记事本打开id_rsa.pub，复制里面的所有内容以备下一步使用。
3. 将密钥中的公钥添加到Gitlab
登录Gitlab的web站点，进入个人资料设置 - SSH Keys页面，将第2步所获得的内容粘贴在文本框key内，并填写title以便记忆，而后保存。
2.5 克隆代码
在gitlab网页端进入project的detail中可以下拉看到提示的代码信息。
这样在本地就可以获取到fork的项目内容。
2.6 正常代码更新提交
2.7 更新本地仓库内容命令
2.8 请求合并到master
在网页端进入到project的detail界面后，如果fork的项目代码有变动，在界面右上角会提示**Create merge request** 来提交合并申请
点击创建后，输入本次提交的title和描述，描述要说明本次提交修改的脚本、修改的内容等信息，便于管理员审核。
2.9 【关键】同步最新master库内容
fork后的项目不会自动从master主分支获取更新，需要负责fork的开发人员自己更新版本
如何更新已经fork的代码：
* 首先要先确定一下是否建立了主repo的远程源：
在本地项目库下执行 `git remote -v`
* 如果里面只能看到你自己的两个源(fetch 和 push)，那就需要添加主repo的源：
* fetch源分支的新版本到本地
执行 `git fetch upstream`
执行后本地库的内容会更新为与master库一致的内容
* 合并本地两个版本的代码：
执行 `git merge upstream/master`
* 将在本地合并后的代码push到自己的github上去，以更新github上fork的仓库
执行 `git push origin master `
执行后网页端的仓库内容更新为合并后的新版本
对于开发人员来说，会使用fork克隆项目，会使用本地git客户端对项目内容进行更新、编辑、提交，会在网页端提交代码合并申请并且规范编写申请描述就足够了。
对管理人员来说，使用gitlab能方便的知道每个员工负责的内容的提交进度情况，方便对他们提交的代码进行质量的检查走读，还有更多统计类、开发进度管理等等功能，但是需要熟练掌握gitlab上的一些功能使用方法，比如使用issue来管理开发任务分配，使用milestone来制定和管理里程碑等等。
# 3. gitlab使用开发规范
参考：[gitlab使用开发规范](https://blog.csdn.net/ruanhao1203/article/details/80440824)
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）