Git 的正确使用姿势与最佳实践：团队协作和版本控制的最佳实践 | 青训营

用户3055523521338
96 阅读5分钟

1. Git的简介和基础用法

Git的含义： GIT，全称是分布式版本控制系统，git通常在编程中会用到，并且git支持分布式部署。

Git的作用： 可以有效、高速的处理从很小到非常大的项目版本管理。分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆(git clone)，在本地机器上拷贝一个完整的Git仓库。

Git的好处： 1.本地拥有版本库，随时进行版本后退； 2.非常简单的建立分支； 3.速度更快，特别是熟悉git命令后； 4.指定和若干不同的远端代码仓库进行交互；

SVN与Git的最主要的区别？

SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就纳闷了。

Git是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上。既然每个人的电脑都有一个完整的版本库，那多个人如何协作呢？比如说自己在电脑上改了文件A，其他人也在电脑上改了文件A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

0501.png

基本操作

创建版本库

什么是版本库？版本库又名仓库，英文名repository,你可以简单的理解一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改，删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻还可以将文件”还原”。

通过命令 git init 把这个目录变成git可以管理的仓库;

用命令 git commit告诉Git，把文件提交到仓库

把文件添加到版本库中;

git diff xxx 查看文件修改的内容;

git add 提交修改 ;

git commit 提交文件;

git log 查看历史记录；

git reset --hard HEAD^ 版本回退到上一个版本； git reset --hard HEAD^^ 版本回退到上两个版本； git reset --hard HEAD~100 版本回退到上100个版本； git reset --hard xxx版本号；

使用git log 或者 git reflog 查看版本记录，使用版本号回退到指定版本;

git fetch 只下载远程库的内容，不做任务的合并；

2. 安装Git

在 Linux 上安装 如果你想在 Linux 上用二进制安装程序来安装基本的 Git 工具，可以使用发行版包含的基础软件包管理工具来安装。 以 Fedora 为例，如果你在使用它（或与之紧密相关的基于 RPM 的发行版，如 RHEL 或 CentOS），你可以使用 dnf：

$ sudo dnf install git-all

如果你在基于 Debian 的发行版上，如 Ubuntu，请使用 apt：

$ sudo apt install git-all

要了解更多选择，Git 官方网站上有在各种 Unix 发行版的系统上安装步骤，网址为 git-scm.com/download/li…。

3. 实现Centos7 上安装git

001.png

002.png

在线安装

$ yum install -y git

或者

源码安装

1)需要提前下载依赖包

yum install -y wget (wget工具) yum install -y gcc-c++ (C++环境) yum install -y zlib-devel perl-ExtUtils-MakeMaker (make 编译器)

2)去官网下载最新版本git源码包

wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.9.0.tar.gz

3)接下来就是解压，配置，安装

tar -zxvf git-2.9.0.tar.gz
cd git-2.9.0
./configure --prefix=/usr/local
make
sudo make install

./configure后面的–prefix=/usr/local，指定安装路径为usr/local

4)查看git版本 git --version

2Git命令

$ git init    
$ git add .    
$ git commit
  1. github 的研发流程

github flow 只有一个主干分支，基于 Pull Request 往主干分支中提交代码

选择团队合作方式 owner 创建好仓库后，其他用户通过Fork 的方式来创建自己的仓库，并在fork的仓库上进行开发；

或者，owner 创建好仓库后，统一给团队成员分配权限，直接在同一个仓库内进行开发；

0503.png

Gitlab 推荐的工作流实在GitFlow 和 Github Flow 上做了优化，既保持了单一主分支的简洁，又适应了不同的开发环境；

原则：upstream first 上游优先 只有在上游分支才能的代码才可以进入到下游分支，一般上游分支就是 master;

代码合并 fast-forward 不会产生一个merge 节点，合并后保持一个线性历史，如果target 分支有了更新，则需要通过 rebase 操作更新 source branch 后才可以合入;

Three-Way Merge 三方合并，会产生一个新的merge 节点

合适的工作流

对于小型团队

推荐使用Github 工作流； 尽量保持少量多次，最好不要一次性提交上千行代码；提交 Pull Request 后最少需要保证有CR后再合入；主干分支尽量保持简洁，使用fast-forward合入方式，合入前进行rebase;

对于大型团队

根据自己的需要指定不同的工作流；

常见问题的解答

1）在Gerrit 平台上使用Merge 的方式合入代码

Gerrit 是集中式工作流，不推荐使用Merge 方式合入代码，应该是在主干分支开发后，直接 Push;

2)不了解保护分支，Code Review, CI 等概念，研发流程不规范

保护分支：防止用户直接想主干分支提交代码，必须通过PR 来进行合入；Code Review: CI: 都是在合入前的检查策略， Code Review 指的是人工进行检查，CI 指的是通过一些定制的脚本来进行一些校验；

3）代码历史混乱，代码合并方式不清晰

不理解fast-forward 和 Three-way merge 的区别，本地代码更新频繁的使用Three-way merge 的方式，导致生成过多的Merge 节点，使提交历史变得复杂不清晰；

avatar
文章
阅读
粉丝