(项目管理 进阶篇)Git 团队版本管理 原则与思路

说起来在来到公司之前一直没有好好用 Git 来管理分支. 之前练习的时候有用到 Git, 但是也仅限于本地仓库的提交而已, 这样做更多的只是留下一个可供追寻的路径 ( History ), 没有太多的

管理

职能. 在多人协同合作的项目中, Git 终于发挥出它强大的优势.

安装

apt-get install git

准备

在看这篇文章之前你得具备

Git

的基础, 基础教程: 廖雪峰 Git.

Git 开发人员视角

开发人员来到公司第一件事情要克隆获得公司在

Git Lab

的项目.

git clone 项目地址 SSH 地址

项目拉取下来之后一般遵循新建一个自己的子分支开发.

git checkout -b dev

开发人员可以正常开发了,

程序 / 功能

开发完后.

# 查看本地仓库状态, 绿色代表添加到 Git 管理中, 红色代表没有添加到 Git 管理
git status
# 将文件添加到 Git 管理之中
git add .
# 将文件添加到本地仓库
git commit -m '本次功能说明'

Git 管理者需要合并代码的时候开发人员得推送到项目远程仓库.

# git remote 可以查看远程仓库地址
git push origin dev:dev

上面代码中是将本地 dev 分支推送到远程 dev 分支, 注意: 开发人员不要提交到远程 master 分支, 一定是远程子分支, 如果远程没有子分支, 第一次提交会自动创建远程子分支.

Git 管理者将代码合并之后, 开发者需要获取合并后的最新代码, 获取推荐使用

git fetch

, 不推荐使用

git pull

因为

git pull

会将代码获取后自动合并到当前分支并提交到本地仓库, 不利于检查冲突,

git fetch

会将远程分支存在到本地但不会合并, 只需要自己手动合并.

# 查看远程分支
git fetch
# 合并远程主分支, 一般来说不会有冲突
git merge origin/master
# 为了保持本地主分支和子分支相同版本, 切换到主分支合并刚刚从远程拉取最新代码的子分支
git checkout master
git merge dev
# 然后再切换回子分支开发
git checkout dev

开发者在项目中大致 Git 运用流程就完成了.

Git 管理人员角度

管理人员也要创建一个子分支开发, 开发人员都将自己的子分支提交到远程的子分支后, 管理人员首先查看远程分支提交的信息记录, 然后再将开发人员的远程子分支与自己本地子分支合并. 注意: 管理人员也要将本地子分支提交到本地仓库, 保证本地仓库

干净

.

# 查看远程分支提交情况
git fetch
# 拉取开发人员的远程子分支
git merge origin/开发人员远程子分支名称

没有出现冲突, 会弹出全屏英文信息, 大致内容是合并信息, 按

ctrl + c

关闭, 随后会自动提交到本地仓库, 如果有冲突会在命令行提示出来, 管理者只需要

git status

查看那些文件是

红色

的这代表有冲突有改动. 然后管理者自己打开有冲突那个文件手动解决冲突, 冲突之中

HEAD

代表自己的代码区,

==

是分界符号, 分界符号下面是开发人员的代码区, 解决完成然后再提交到本地仓库.

# 查看那些文件有冲突 ( 红色 )
git status
# 冲突解决完后
git add .
git commit -m '合并其他人代码'

依次合并其他人员代码, 合并完所有人代码后, 再把代码提交到远程主分支.

# 将代码提交到远程仓库
git push origin dev:master
# 保持主分支与子分支的一致性
git checkout master
git merge dev
# 开发一定是在子分支
git checkout dev

管理者在项目中大致 Git 管理流程就完成了.