配置同时使用 Gitlab 和 Github 的开发环境

Git 客户端与服务器端的通信支持多种协议，ssh 最常用。ssh的公钥登录流程：用户将自己的公钥存储在远程主机，登录时，远程主机会向用户发送一条消息，用户用自己的私钥加密后，再发给服务器。远程主机用事先存储的公钥进行解密，如果成功，就证明用户可信。

image

生成公私密钥

用户必须事先提供自己的公钥给服务器，如果没有，可以用 ssh-keygen 命令生成。该命令会生成两个文件（公钥 and 私钥）,默认路径在用户根目录下的.ssh文件夹中。

注意： 默认生成的文件名是 id_rsa/id_rsa.pub，由于这里需要两套密钥，所以需为它们分别命名，以防止互相覆盖。

执行下面命令生成密钥：

ssh-keygen -t rsa -C "注册 gitlab 账户的邮箱"

提示要输入名称时输入 id_rsa_gitlab

ssh-keygen -t rsa -C "注册 github 账户的邮箱"

提示要输入名称时输入 id_rsa_github

提供公钥给服务器

复制 ~/.ssh/id_rsa_gitlab.pub文件内容，进入gitlab / profile / SSH Keys，将公钥内容添加至 gitlab 。
复制 ~/.ssh/id_rsa_github.pub文件内容，进入github / setting / SSH and GPG keys / New SSH key 将公钥内容添加至 github 。

更新SSH配置

SSH 配置信息加载顺序如下：

命令行配置参数
用户级别的配置文件~/.ssh/config
系统级别的配置文件 /etc/ssh/ssh_config

根据我们实际情况，更新用户级别配置信息即可，打开 SSH 客户端配置文件 ~/.ssh/config 增加配置项，如果没有就创建一个（是文本文件）。

SSH配置项有很多，详见：https://man.openbsd.org/ssh_config 或r https://www.ssh.com/ssh/config/

在配置文件中加入以下内容

Host github.com
    HostName github.com
    User githubuser@xyz.com
    IdentityFile ~/.ssh/id_rsa_github

Host gitlab.com
    HostName gitlab.com
    User gitlabuser@xyz.com
    IdentityFile ~/.ssh/id_rsa_gitlab

配置仓库用户信息

Git 配置信息也有三个地方可以存储，根据加载顺序依次为：

/etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。如果使用带有 --system 选项的 git config 时，它会从此文件读写配置变量。
~/.gitconfig 或 ~/.config/git/config 文件只针对当前用户。可以传递 --global 选项让 Git 读写此文件。
当前使用仓库的 Git 目录中的 config 文件（就是 .git/config）

不同仓库链接不同的服务器，所用的git用户信息也不同。可以把常用的git用户信息配置到 ~/.gitconfig 中，不常用的我们在仓库中单独配置。以常用 gitlab 为例：

git config --global user.name "githubuser"
git config --global user.email "githubuser@xyz.com"

进入本地 github 仓库配置 git 用户信息

~/github$ git config --local user.name "githubuser"
~/github$ git config --local user.email "githubuser@xyz.com"

Git版本管理及工作流规范

1、首先介绍下git的主要区域：

image

2、为规范源代码版本管理，现将各分支表述如下：

a.master分支
存放的应该是随时可供在生产环境中部署的代码
当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。
分支命名：master
该分支，由管理员负责维护，其它人只有拉取权限。来自于release分支的合并，供发版使用
生命周期：伴随着整个项目的生命周期，项目结束时结束。

b.develop分支
develop分支是每次迭代版本的共有开发分支，从最新的master分支派生（管理员操作）
当develop分支上的代码已实现了软件需求说明书中所有的功能，派生出release分支（管理员操作）
分支命名：dev-版本号
该分支，由开发人员在各自的feature分支开发完成后，合并至该分支。
生命周期：一个阶段功能开发开始到本阶段结束

c.release分支
从develop分支派生（管理员操作）
测试环境中出现的bug，统一在该分支下进行修改，并推送至远程分支。修改内容必须合并回develop分支和master分支。
分支命名惯例：release-版本号
生命周期：一个阶段功能开发结束开始，完成阶段功能测试并修复所有发现bug，合并会develop分支结束。

d.feature分支
在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支
分支命名惯例：feature-姓名全拼-分支说明-日期 / feature-分支说明-日期
例：接到一个开发关于cc视频点播替换的任务，你需要从develop分支拉出一个分支，并命名为：release-yuruixin-ccVideo-20171117。然后在该分支下进行开发，开发结束，将该分支合并至develop分支（此时的代码必须为可运行的，不能影响到他人），合并完成删掉该特性分支。
开发人员的每一个新功能开发都应该在该类分支下进行。
生命周期：开发一个新功能开始，完成新功能开发并合并回develop分支结束。

e.hotfixes分支
在master分支发现bug时，在master的分支上派生出一个hotfixes分支，修改完成后，合并至master分支以及develop分支，合并完成，删除该hotfixes分支。
分支命名惯例：hotfixes-姓名全拼-分支说明-日期
示例：hotfixes-yuruixin-cclivebug-20171117
生命周期：发现master分支bug开始，完成master分支bug结束。
整个流程可以下图展示:

image

3.工作流：

Git工作流你可以理解为工作中团队成员遵守的一种代码管理方案

a.集中式工作流:

这种工作方式跟svn类似，它只有一个master分支，开发者会先把远程的仓库克隆到本地，之后的修改和提交都在本地操作，直到在某个合适的时间点将本地的代码合入到远程master。这种工作流比较适合小团队，因为小团队可能不会太多的协作和合流的动作。

image

b、功能分支工作流

这种工作流关注功能开发，不直接往master提交代码保证它是稳定并且干净的，而是从master拉取feature分支进行功能开发，团队成员根据分工拉取不同的功能分支来进行不同的功能开发，这样就可以完全隔离开每个人的工作。当功能开发完成后，会向master分支发起Pull Request，只有审核通过的代码才真正允许合入master，这样就加强了团队成员之间的代码交流，也就是我们常说的Code Review

image

c、****Gitflow工作流：****

、master分支主分支

保持稳定，不允许直接往这个分支提交代码，只允许往这个分支发起merge request，只允许release分支和hotfix分支进行合流

、develop分支开发分支

相对稳定的分支，用于日常开发，包括代码优化、功能性开发

、feature分支特性分支

从develop分支拉取，用于下个迭代版本的功能特性开发，功能开发完毕合并到develop分支

、release分支发布分支

从develop分支拉取，用于回归测试，bug修复，发布完成后打tag并合入master和develop

、hotfix分支热更新分支

从develop分支拉取，用于紧急修复上线版本的问题，修复后打tag并合入master和develop，

工作方式图参考第二张图

d、Forking工作流

Forking工作流对于开源项目贡献者一定不陌生了，它有一个公开的中央仓库，其他贡献者可以Fork（克隆）这个仓库作为你自己的私有仓库，开源项目维护者可以直接往中央仓库push代码，而代码贡献者只能将代码push到自己的私有仓库，只有项目维护者接受代码贡献者往中央仓库发起的pull request才会真正合入。

image

git常用命令

git checkout

git status

git checkout -b

git commit

git diff

git add

git clean -fdx

git fetch --prune

git pull --ff-only

git branch -D

git push

git merge

git rm

git rebase

git reset

git revert

git push origin :yourbranch

配置命令别名

[color]    
    ui = auto
[alias]    
    st = status    
    pl = pull --ff-only    
    ps = push    
    co = checkout    
    ci = commit    
    df = difftool    
    cp = cherry-pick    
    ca = commit --amend    
    br = branch    
    l = log --stat    
    last = log -1    
    lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit    
    up = push origin    
    lf = log --follow -p    
    aa = ls-files --modified    
    su = status -uno    
    cm = commit -m    
    uf = push origin -f    
    cl = clean -fdx    
    fe = fetch --prune    
    cf = clean -fdx    
    bd = branch -D    
    cb = checkout -b
[push]    
    default = simple
[core]    
    editor = vim    pager = less -+F
[diff]    
    tool = meld
[difftool]    
    prompt = false
[merge]    
    tool = meld
[init]    
    templatedir = ~/.git_template

参考链接：
大道至简
 程序员联盟

git版本控制流程和配置多个SSH-key

git版本控制流程和配置多个SSH-key

配置同时使用 Gitlab 和 Github 的开发环境

生成公私密钥

提供公钥给服务器

更新SSH配置

配置仓库用户信息

Git版本管理及工作流规范

、master分支主分支

、develop分支开发分支

、feature分支特性分支

、release分支发布分支

、hotfix分支热更新分支

git常用命令

git版本控制流程和配置多个SSH-key

配置同时使用 Gitlab 和 Github 的开发环境

生成公私密钥

提供公钥给服务器

更新SSH配置

配置仓库用户信息

Git版本管理及工作流规范

、master分支 主分支

、develop分支 开发分支

、feature分支 特性分支

、release分支 发布分支

、hotfix分支 热更新分支

git常用命令

、master分支主分支

、develop分支开发分支

、feature分支特性分支

、release分支发布分支

、hotfix分支热更新分支