博客
博客
文章目录
  1. 背景
  2. 分布式的版本库
    1. 基本概念
    2. git 命令简介
      1. 初始化 git 配置
      2. 初始化 git 仓库
      3. 修改文件并提交到暂存区
      4. 提交代码到版本库
      5. 同步远程版本库到本地版本库
      6. 同步本地版本库到远程版本库
  3. git 分支
    1. 何为分支
    2. 合并分支
      1. merge 的特殊情况:冲突
      2. 常见的 git 分支管理模式:gitflow
  4. 参考

git 快速入门

背景

git 作为现在最为流行的版本管理系统,大部分公司都使用 git 进行版本控制,
并且最大同性交友网站 github 也是在 git 的基础上建立的。
很多人认为 git 难,在于它的一些概念与之前流行的集中化的版本管理系统有所出入,
只要通过熟悉 git 的基本概念,以及 git 分支切换的流程,想要上手还是很容易的。

这篇文章将介绍 git 的一些基本概念以及 git 常用的一些命令。github 官方提供了一套 git 学习教程,感兴趣可以 去看看

分布式的版本库

基本概念

首先,看看官网是怎么介绍 git 的。

Git is a free and open source distributed version control system.
Git 是一个免费并且开源的分布式版本管理工具。

重点就在于 git 的分布式,只需要在项目根目录执行 git init 你就拥有了一个 git 版本库,
同时在该目录下会生成一个 .git 文件夹,该文件夹用来记录你所有的提交信息,类似与 .svn 文件夹。
该文件夹会存储你每次提交的文件的全部信息,只是会经过压缩,具体内容这里不做深入展开。
如果你对 git 的内部原理感兴趣可以看
这里

与集中式的版本管理工具不同,git 的 commit 之后提交到本地的版本库,
像 svn 的 commit 则是直接提交到服务器的中央版本库。
这就意味这我们都在本地具有一个版本库,那么多人开发时,我们需要如何管理我们的版本库呢?

这里 git 就引入了一个远程版本库的概念,远程版本库并不会记录我们的代码文件,
只是一个裸仓库,也就是说远程版本库只会保存 .git 目录下的东西,这也相当于间接的记录我们的代码文件。
每个人都能让远程版本库同步你本地的 commit 信息,但是同步之前会检查你本地的版本库是否与远程版本库的提交信息一致,
如果不一致会提醒你先从远程版本库进行更新。唉,千言万语不如一张图。

同步到远程版本库

  1. 当我们告诉远程版本库,我有一个新的提交需要你同步,它会拒绝你。
  2. 因为在你之前有一个人先同步了提交到远程分支,你必须更新他的提交到你本地,你才能继续同步你的提交。

git 在提交到版本库之前,还有一个步骤,那就是添加到暂存区,至于 git 为什么会存在暂存区,知乎上有个回答我觉得说得挺好的(传送门)。

大致意思是说,早期的版本管理工具有成熟的 gui,比如用 svn,每一次提交都能让你自由选择需要提交哪些文件的修改。

小乌龟

而在命令行下面,这些操作比较麻烦,为了解决这个问题,于是在 commit 之前增加了一个暂存区,用来存放我们需要提交的文件。好了,我们再回过头来看看 git 在版本管理上分了哪些部分。

git 命令简介

了解了这些概念,我们再来看看,如何初始化一个 git 仓库,并且在修改代码后将提交同步给远程版本库。

初始化 git 配置

该配置是用来告诉版本库是谁提交代码。

# 全局设置用户名 
git config --global user.name "your name"

# 全局设置邮箱
git config --global user.email "xxxxxxxxx@qq.com"

初始化 git 仓库

这里有两种方式,一种是新建一个本地版本库,然后手动连接远程版本库,还一种是直接获取远程版本到本地。

  1. 新建本地仓库,并与远程版本库进行连接
mkdir hub && cd hub

git init # 初始化 git 仓库

git remote add origin git@github.com:github/hub.git # 关联远程版本库,并取名为 origin

git pull origin master # 获取名为 origin 的远程版本库的提交信息到本地版本库
  1. 获取远程的版本库到本地

git clone git@github.com:github/hub.git # 该命令相当于上面三步的缩写

修改文件并提交到暂存区

我们可以新建一个文件(eg. reamde.md),然后通过 add 命令,将该文件添加到暂存区,表示该文件是我们要提交到版本库的文件。

# 将一个修改后的文件添加到暂存区 
git add readme.md


# gitadd 其他用法

# 添加所有修改、删除或新建的文件到暂存区
git add .
# 添加所有以 js 结尾的文件到暂存区
git add *.js
# 添加所有修改、删除或新建的文件到暂存区
# 除了。开头的文件,比如 .gitignore
git add *
# git add --update 的缩写
# 如果再次修改了在暂存区中的文件,可以通过该命令进行更新
git add -u
# 作用与 git add . 相同
git add -A

提交代码到版本库

我们现在已经把代码添加到了暂存区,接下来就需要把暂存区的代码提交到版本库。

# 提交暂存区的代码到版本库 
git commit -m 'commit message'

# 如果你重新编辑了一些文件,添加到暂存区,想把这些修改合并到上一次提交
# 然后会出现一个编辑框,让你修改上次的提交信息
git commit --amend
# 如果不想修改上次的提交信息
git commit --amend --no-edit

同步远程版本库到本地版本库

最好每次把自己的提交信息同步给远程版本库之前,先把远程版本库同步到本地。
这里会涉及到分支的概念,我们先放到一边,本地版本库默认默认为 master 分支
(ps. 也就是我们常说的主干)。

# 将名为 origin 的远程版本库的 master 分支同步到本地的当前分支 
git pull origin master

# git pull 命令其实是如下两个命令的简写
git fetch origin master
git merge origin/master

同步本地版本库到远程版本库

git 将本地版本库同步到远程版本库使用 push 命令,但是每次都需要指定同步给哪个版本库的哪一个分支,
这时,你可以使用 -u 参数将本地版本库与远程版本库绑定,以后提交就不需要指定,默认提交到那个版本库。

# 将本地的提交同步给远程版本库 
git push origin master

# 绑定默认提交的远程版本库
git push -u origin master
# 下次提交只需要使用 git push 就可以了
git push

git 分支

git 的分支是 git 版本管理的重点,git 的分支对比 svn 十分轻量级。

注意,前方高能!!!

为了讲清楚这些概念得画一些图,没办法美术功底太好,话又不会说,只好画图写教程了。

何为分支

要搞清楚 git 的分支概念,首先需要知道 git 是如何区分不同的分支的。
在 git 中,一个分支就会存在有一个指针,该指针指向一个 commit。
每次拉分支就会在当前 commit 上创建一个新的指针,而且分支的指针每次都会跟随 commit 前移。

# 查看当前分支 
git branch # 刚刚初始化的版本库默认在 master 分支上
# 新建分支
git branch branch # 新建一个名为 branch 的分支

新建分支

那么现在有个问题,在新建一个分支之后,两个分支指向同一个 commit,到底怎么区分现在哪个分支上呢?
这里就要引入一个新的指针 HEAD,用来指向当前所处的分支。

# 切换分支 
git checkout branch # 切换到 branch 分支

# 创建分支与切换分支可以简写为一个命令
gti checkout -b branch

HEAD 指向当前分支

现在在 branch 分支上进行了一次 commit,然后 branch 指针就像向前移动。

vim xxx.txt
git add.
git commit -m 'modify xxx.txt'

branch 分支前移

然后再切换到 master 分支,进行一次提交,看下图就会发现,这里会出现分支。
master 分支表示的是 commit1、2、3、5,而 branch 分支 commit1、2、3、4。
到这里就很容易理解为什么说 git 的分支很轻量级,因为对 git 来说一个分支只是会新建一个指针,
并指向一个提交,而不是拷贝所有的代码文件到另一个目录。

git checkout master # 切换到 master 分支 
vim yyy.txt
git add.
git commit -m 'modify yyy.txt'

不同分支的提交不会相互影响

合并分支

天下三分,分久必合,合久必分。
有分支就会有合并,举个例子,项目中突然来了个 bug,但是手头的代码还没写完,不可能直接提交。所以你要先从 master 分支拉出一个 Fix-Bug 分支,在分支上修改好之后再进行提交。最后这个提交需要 merge 回 master 分支。

#1. 先创建 feature 分支,将手头的代码提交到 feature 分支上 
git checkout -b feature
git add .
git commit -m 'feature branch commit'

#2. 切换回 master 分支,从 master 拉一个新的分支
git checkout master
git checkout -b Fix-Bug

#3. bug 修改完毕后,提交代码到 Fix-Bug 分支
git add .
git commit -m 'fixed bug'

#4. 把修复了 bug 的代码 merge 到 master 分支
git checkout master # 重新切换回 master 分支
git pull origin master # 把同事提交的代码先更新到本地
git merge Fix-Bug
git push origin master # 将 merge 的代码同步到线上,进行 bug 修复
git branch -d Fix-Bug #bug 修复后将 Fix-Bug 分支删除

merge

上面只是进行了简单的演示,真实情况比这更加复杂。

观察上图,可以发现在 merge 操作后,自动会生成一个新的 commit。如果你不想生成这个 commit,
merge 之后还有其他修改,或者想要自己写 commit 的 message,也可以使用如下命令来取消自动 commit。

git merge --no-commit branch

merge 的特殊情况:冲突

有时候远程版本库和本地版本库进行 merge 的时候,你和你的同事可能同事修改了同一个文件的同一个位置,这就会出现冲突。
出现冲突怎么办,当然是解决冲突。解决冲突你可以自己一个个手动去解决,当然你也可以使用一些工具,比如下图使用 vscode 来解决冲突。

vscode 解决冲突

可以通过 git status 查看哪些文件出现了冲突,通过编辑器将所有冲突解决后就可以进行提交了。

发生冲突的文件

常见的 git 分支管理模式:gitflow

这里主要涉及常用的分支的命名规范:

  1. master 主干,用来存放最稳定的代码
  2. hotfix,用来紧急修改 bug 的分支
  3. release,用来发布上线的分支
  4. feature,特性分支,每一个新功能都应该有一个特性分支
  5. develop,开发分支,当特性开发完毕后,将特性分支合并到 develop 分支

参考

这里只是介绍了 git 中最基本的一些概念,git 还有很多高级命令待大家去发现,比如 rebase、reset、stash。

最后给大家推荐一些 git 的好教程。

  1. pro git
  2. git 常用命令汇总
  3. git push 与 pull 的默认行为
支持一下
扫一扫,支持一下
  • 微信扫一扫
  • 支付宝扫一扫