git常见操作与实践总结

作为一名开发者，熟悉使用 git 代码管理工具是一项必备的基本技能。

git 相较 SVN 而言，其优点不言而喻。git 的功能非常强大，其包括的操作命令也非常的多，但是从实用性而言，很多命令可能我们平时也用不到，这里只记录一些经常使用的命令。

熟练使用这些操作，就可以完全得心应手的使用 git 工具了。

安装git命令

在 Linux 系统上安装，有多种方式比如 yum、apt、src 等方式

1
2
3
4
5
6
7
8

# 在 centos、redhat 可以使用 yum 方式安装
$ yum install git

# 在 ubuntu、debian 可以使用 apt 方式安装
$ apt install git

# 有时候二进制方式不满足时，可以用源码方式安装
$ ./configure && make && make install

源码安装git

有时通过二进制方式安装的 git 命令满足不了当前需求，比如系统自带的版本太低等问题。

典型的，在 go get 安装包时，会用到 git fetch --unshallow 命令，我们需要安装更高版本的 git 才支持 --unshallow 参数

具体安装方法和过程总结如下

1
2
3
4
5
6
7
8
9
10
11
12
13

$ cd /tmp
$ curl -O https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.36.1.tar.gz
$ tar -xvzf git-2.36.1.tar.gz && cd git-2.36.1
$ ./configure && make && make install

# 编译好的二进制加入PATH
$ tee -a $HOME/.bashrc <<'EOF'
export PATH=/usr/local/libexec/git-core:$PATH
EOF

# 检验确认 git 版本
$ source $HOME/.bashrc && git version
git version 2.36.1

常见基本配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 设置用户名和邮箱

$ git config --global user.name "name"
$ git config --global user.email "mail@163.com"

# 设置 git 保存用户名和密码
$ git config --global credential.helper store

# 解决 git 中 'Filename too long' 的错误
$ git config --global core.longpaths true

# 默认 git 会把非 ASCII 字符用 8 进制转义字符输出（以防乱码）
# 现代的终端都支持非 ASCII 字符，所以可以关闭这个特性
$ git config --global core.quotepath off

# GitHub 限制最大只能克隆 100M 的单个文件，为了能够克隆大于 100M 的文件
# 我们还需要安装 Git Large File Storage
$ git lfs install --skip-repo

• --global：为全部仓库设置生效，如果是自己的私有开发环境，可以加此参数；
• --local：只为当前仓库设置生效；

初始化仓库

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

1
2
3
4
5
6

$ mkdir learngit
$ cd learngit
$ git init
Initialized empty Git repository in /root/learngit/.git/
$ ls -a
.  ..  .git

可以发现当前目录下多了一个 .git 的目录，这个目录是 git 来跟踪管理版本库的，千万不要手动修改这个目录里面的文件，否则就把 git 仓库给破坏了

关于文件变动跟踪

首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如 TXT 文件、网页、代码等等， git 也不例外。

版本控制系统可以告诉你每次的改动，比如在第 5 行加了一个单词 “Linux” ，在第 8 行删了一个单词 “Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从 100KB 改成了 120KB，但到底改了什么，版本控制系统不知道，也没法知道。

关于编码

因为文本是有编码的，如果没有历史遗留问题，一定要使用标准的 UTF-8 编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

代码提交

查看repo状态

1

$ git status

添加文件到缓存区

1
2

$ git add file1.txt
$ git add file2.txt

提交到版本库

1
2

$ git commit -m "message"
# 一定要写提交信息, 便于后续查看版本信息

管理修改

丢弃工作区的修改

1
2
3
4

$ git checkout -- file.txt

# 如果工作区的文件未被 git 管理，上述命令是不管用的，需要使用 clean 子命令
$ git clean -f

丢弃暂存区的修改

1
2

$ git reset HEAD file.txt
# 丢弃暂存区的修改, 完毕后工作区内容未撤销

撤销提交(版本回退)

1

$ git reset --hard HEAD^

修改最后提交的commit信息

如果需要修改 commit 提交信息，可以通过 --amend 选项进行修改

1

git commit --amend

管理修改的举例

• 场景1
  • 当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
• 场景2
  • 当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
• 场景3
  • 已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

查看工作区与版本库的差异

1

$ git diff HEAD -- file.txt

查看提交版本日志

1

$ git log --pretty=oneline    # --pretty选项更清晰显示

远程库操作

克隆远程库

1

$ git clone http://gitlab.com/chopin/gitver

添加远程库(给本地库)

1

$ git remote add origin git@gitlab.staff.sina.com.cn:chopin/gitver.git

推送远程库

1

$ git push -u origin master    # 第一次推送加'-u'选项, 关联本地与origin的master分支

拉取远程库

1

$ git pull <远程主机名> <远程分支名>:<本地分支名>

在默认模式下，取回远程主机某个分支的更新，再与本地的指定分支合并。git pull 是 git fetch 后跟 git merge 的缩写。

比如，要取回 origin 主机的 next 分支，与本地的 master 分支合并，需要写成下面这样

1

$ git pull origin next:master    # 如果要与当前分支合并, 则冒号后面的部分可以省略

相当于:

1
2

$ git fetch origin
$ git merge origin/next

手动建立追踪关系:

1

$ git branch --set-upstream master origin/next

上面命令指定 master 分支追踪 origin/next 分支。如果当前分支与远程分支存在追踪关系，git pull 就可以省略远程分支名

1

$ git pull origin    # 如果当前分支只有一个追踪分支，连远程主机名都可以省略

分支管理

创建分支

1

$ git branch b1

切换分支

1
2

$ git checkout b1    # 切换到b1分支
$ git checkout -b b2 # 创建并切换到b2分支

合并分支

1
2
3

$ git merge dev           # 合并dev分支到当前分支
$ git merge dev master    # 合并dev分支到master分支(可能当前分支并没有在master上)
$ git --no-ff merge dev   # 合并时不使用ff方式, 这样会在合并分支上保留提交的版本信息

分支策略

主分支master

代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

开发分支develop

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在 master 分支上，对 develop 分支进行”合并”

临时性分支

• feature：功能分支
• release：预发布分支
• fixbug：修补问题分支

功能分支

它是为了开发某种特定功能，从 develop 分支上面分出来的。开发完成后，要再并入 develop。

预发布分支

它是指发布正式版本之前(即合并到 master 分支之前)，我们可能需要有一个预发布的版本进行测试。预发布分支是从 develop 分支上面分出来的，预发布结束以后，必须合并进 develop 和 master 分支。它的命名，可以采用 release-x 的形式。

修补问题分支

软件正式发布以后，难免会出现 bug。这时就需要创建一个分支，进行 bug 修补。修补 bug 分支是从 master 分支上面分出来的。修补结束以后，再合并进 master 和 develop 分支。它的命名，可以采用 fixbug-x 的形式。

上一篇 « 使用GDB调试程序 下一篇 » 如何理解密码技术之数字信封