linux下git的使用

smilejiasmile

已于 2022-08-23 17:33:13 修改

阅读量2.7k

点赞数 3

分类专栏：工具 Linux学习文章标签： git linux

于 2017-08-19 19:00:17 首次发布

本文链接：https://blog.youkuaiyun.com/smilejiasmile/article/details/77414915

版权

Linux学习同时被 2 个专栏收录

36 篇文章

订阅专栏

工具

6 篇文章

订阅专栏

文章目录

git的使用

git的使用

1、初始化一个Git仓库，使用git init命令。

添加文件到Git仓库，分两步：
- 第一步，使用命令git add ，注意，可反复多次使用，添加多个文件；
- 第二步，使用命令git commit，完成。
要随时掌握工作区的状态，使用git status命令。
- 如果git status告诉你有文件被修改过，用git diff可以查看修改内容。
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
- 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
- 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
合并分支： git merge （合并）与 git rebase（变基）
- 假设目前我们工程的 local git tree 如下图中的 NOW 所示： git merge 工作流程则如下：
- 如果在合并issue3分支的时，想使提交的历史记录显得更简洁，则可以使用 git rebase。
  - 我们可以先使用 git reset --hard HEAD~ 撤销回到 NOW 的状态。然后开始 git rebase工作流如下示：
  - 注意：如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基 rebase 操作。
  - Reset错误的时候，在ORIG_HEAD上reset 就可以还原到reset前的状态。
  - git reset --hard ORIG_HEAD
  - 更多相关 rebase 内容，可参见 git rebase
git pull 与 git fetch 的区别
- 执行pull就可以进行合并。如果没有冲突的修改，会自动创建合并提交。如果发生冲突的话，要先解决冲突，再手动提交。
- pull，远程数据库的内容就会自动合并。fetch 不会自动提交，它会拉取到一个叫 FETCH_HEAD 的分支。若你不想合并，从分支中退出即可。若你想合并，可再执行 git pull.
- 合并后，历史记录会和 pull 相同。实际上 pull 的内容是 fetch + merge 组成的。

执行fetch就可以取得远程数据库的最新历史记录。取得的提交会导入到没有名字的分支，这个分支可以从名为FETCH_HEAD的退出。

2、暂存区stage是Git非常重要的概念，Git跟踪并管理的是修改，而非文件。

Git是如何跟踪修改的，每次修改，如果不add到暂存区，那就不会加入到commit中。
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容

3、要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

关联一个远程 origin 库

关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
如果想要提交某一次指定的 commit 而不是本地最新的 commit，可以使用如下命令：

$ git push <remote name> <commit hash>:<remote branch name>
 
# Example:
$ git push origin 2dc2b7e393e6b712ef103eaac81050b9693395a4:master

关联多个远程 origin 库 ( 即 Git 如何同步上游分支代码)

当我们参与开源项目或者采用 Fork 模式来协同开发时，常常会在自己的 Fork 分支上提交各种修改。但是有一个问题? 上游仓库，也就是源分支代码更新了，我们 Fork 的下游分支，怎么同步上游仓库的更新呢？
可按照如下几步来操作：

第一步：查看所有远程库的远程地址
git remote -v

第二步：添加源分支 URL
git remote add upstream [源项目 URL]

第三步：检查所有远程库的远程地址
git remote -v

第四步：从源分支获取最新的代码
git fetch upstream /  git fetch upstream [特定分支]

第五步：切换到主分支
git checkout master

第六步：合并本地分支和源分支
git merge upstream/master

第七步：Push 到 Fork 分支
git push

4、要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。

Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快

查看某个文件的历史提交的版本代码

1、可以先使用 git log 找到该个文件提交的历史版本
2、然后使用 git show <git提交版本号> <文件名> 查看历史版本

5、git 的版本切换

一般会，先使用 git log或者 git log --pretty=oneline 找出 commit_id 。之后，便可以使用命令git reset --hard commit_id 切换版本了
或者使用签出一个新的分支的方法，用git checkout -b commit_id 的方法，创建一个新的分支，并切换到新的分支
使用git branch 可以查看有哪些分支，注意看 master 分支前的 * 字符：它表示当前所在的分支。也就是说，如果现在提交更新，master 分支将随着开发进度前移。若要查看各个分支最后一个提交对象的信息，运行 git branch -v，然后可以用 git checkout 切换到对应的分支
要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用 --merged 和 --no-merged 选项。比如用 git branch --merged 查看哪些分支已被并入当前分支（译注：也就是说哪些分支是当前分支的直接上游。）
一般来说，列表中没有 * 的分支通常都可以用 git branch -d 来删掉。原因很简单，既然已经把它们所包含的工作整合到了其他分支，删掉也不会损失什么。
另外可以用 git branch --no-merged 查看尚未合并的工作：它会显示还未合并进来的分支。由于这些分支中还包含着尚未合并进来的工作成果，所以简单地用 git branch -d 删除该分支会提示错误，因为那样做会丢失数据。
打标签 git tag -a <版本号> -m "<备注信息>"
将本地标签提交到远程仓库
前面所提到的创建标签，只是将标签添加到了本地的版本管理，我们需要在创建之后将本地标签同步到远程仓库，如Github。

推送所有标签

git push origin --tags

推送指定版本的标签

git push origin <版本号>

删除远程仓库的标签
同创建本地标签一样，删除了本地标签之后也要同时删除远程仓库的标签。

新版本Git (> v1.7.0)
git push origin --delete <版本号>

6、fork别人的代码后如何保持和原作者同步的更新

在GitHub上我们会去fork别人的一个项目，这就在自己的Github上生成了一个与原作者项目互不影响的副本，自己可以将自己Github上的这个项目再clone到本地进行修改，修改后再push，只有自己Github上的项目会发生改变，而原作者项目并不会受影响，避免了原作者项目被污染。但经过一段时间，有可能作者原来的代码变化很大，你想接着在他最新的代码上修改，这时你需要合并原作者的最新代码过来，让你的项目变成最新的。

1、先克隆项目到本地：
Git clone https://github.com/iakuf/mojo
cd mojo

2、添加原作者项目的 remote 地址，然后将代码 fetch 过来
git remote add sri https://github.com/kraih/mojo
git fetch sri
‘sri’相当于一个别名
查看本地项目目录： git remote -v

3、合并
git checkout master
git merge sri/master
如果有冲突的话，需要丢掉本地分支：
git reset –hard sri/master

4、这时你的当前本地的项目变成和原作者的主项目一样了，可以把它提交到你的GitHub库
git commit -am ‘更新到原作者的主分支’
git push origin
git push -u origin master -f –强制提交

7、.gitignore规则不生效的解决办法

把某些目录或文件加入忽略规则，按照上述方法定义后发现并未生效，原因是.gitignore只能忽略那些原来没有被追踪的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。那么解决方法就是先把本地缓存删除（改变成未被追踪状态），然后再提交：

git rm -r --cached .
git add .
git commit -m 'update .gitignore'

8、GIT 查看/修改用户名和邮箱地址

用户名和邮箱地址的作用

用户名和邮箱地址是本地git客户端的一个变量，不随git库而改变。
每次commit都会用用户名和邮箱纪录。每次commit都会用用户名和邮箱纪录。
github的contributions统计就是按邮箱来统计的。

查看用户名和邮箱地址：

$ git config user.name

$ git config user.email

修改用户名和邮箱地址：

$ git config --global user.name "username"

$ git config --global user.email "email"

其中，加上 --global 是全局设置的意思，不加是局部设置的意思。

git push 报错 403：

The requested URL returned error:
403

可以清楚缓存后，在尝试。命令如下：

git config --local --unset credential.helper
git config --global --unset credential.helper
git config --system --unset credential.helper

关于 credential 可以参见：

https://blog.youkuaiyun.com/u012163684/article/details/52433645

9、git 对比两个分支差异

比如我们有 2 个分支：master, dev，现在想查看这两个 branch 的区别，有以下几种方式：

1.查看 dev 有，而 master 中没有的：

git log dev ^master

同理查看 master 中有，而 dev 中没有的内容：

git log master ^dev

这里写图片描述

2 查看 dev 中比 master 中多提交了哪些内容：

git log master..dev

注意，列出来的是两个点后边（此处即dev）多提交的内容。同理，想知道 master 比 dev 多提交了什么：

git log dev..master

3 不知道谁提交的多谁提交的少，单纯想知道有什么不一样：
git log dev…master

4.在上述情况下，再显示出每个提交是在哪个分支上：
git log --left-right dev…master

10、改写提交 (commit)

git commit --amend : 该命令可以使将这一次的提交合并到上一次最后的提交 commit 里。
git revert HEAD: 通过修改 HEAD 的指向就可以实现撤销恢复。HEAD 表示工作区当前指针。
git reset --hard HEAD~~ : 如果想删除当前分支最前面的两个提交, 可以使用该命令。如果撤销失败，可以使用 git reset --hard ORIG_HEAD 恢复到原来的状态。
git cherry-pick 99daed2: git cherry-pick 可以将任意分支上的指定的 hash commit (如 99daed2) 合并导入到当前操作（如 master）分支。
rebase -i：合并过去的几个提交成一个提交。如 git rebase -i HEAD~~。这样两个提交就合并成一个提交了。可以用 log命令确认历史记录。若其中还要修改某些文件内容，则可以修改后使用 git commit --amend 合并至上一次提交后，在执行 git rebase --continue.
merge --squash: 本地端的历史记录的状态如下图显示。把issue1分支的所有提交合并成一个提交，并导入到master分支。
切换到master分支后，指定 --squash选项执行merge。git checkout master , git merge --squash issue1 . 若有冲突，解决后， add 冲突文件后，再 commit 即可。

11、git 中 submodule 子模块的使用

背景：我们经常会遇到：某个工作中的项目需要包含并使用另一个项目。也许是第三方库，或者你独立开发的，用于多个父项目的库。现在问题来了：你想要把它们当做两个独立的项目，同时又想在一个项目中使用另一个。

如果将这个库包含进来，那么无论用何种方式都很难定制它，部署则更加困难，因为你必须确保每一个客户端都包含该库。如果将代码复制到自己的项目中，那么你做的任何自定义修改都会使合并上游的改动变得困难。

Git 通过子模块来解决这个问题。子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立。git 提交日志的独立，代码管理的独立性。从而避免将主项目和子项目混成一谈，从而避免 git 代码管理的混乱。

下面我们介绍子模块相关的基础命令，详细使用请参考 man page。

子模块的添加

添加子模块非常简单，命令如下：

git submodule add <url> <path>

其中，url为子模块的路径，path为该子模块存储的目录路径。执行成功后，git status会看到项目中修改了.gitmodules，并增加了一个新文件（为刚刚添加的路径）

git diff --cached 查看修改内容可以看到增加了子模块，并且新文件下为子模块的提交hash摘要
git commit提交即完成子模块的添加

子模块的使用

克隆项目后，默认子模块目录下无任何内容。需要在项目根目录执行如下命令完成子模块的下载：

git submodule init
git submodule update

或：

git submodule update --init --recursive

执行后，子模块目录下就有了源码，再执行相应的makefile即可。

子模块的更新

子模块的维护者提交了更新后，使用子模块的项目必须手动更新才能包含最新的提交。
在项目中，进入到子模块目录下，执行 git pull更新，查看git log查看相应提交。

完成后返回到项目目录，可以看到子模块有待提交的更新，使用git add，提交即可。

删除子模块

有时子模块的项目维护地址发生了变化，或者需要替换子模块，就需要删除原有的子模块。

删除子模块较复杂，步骤如下：

rm -rf 子模块目录 删除子模块目录及源码
vi .gitmodules 删除项目目录下.gitmodules文件中子模块相关条目
vi .git/config 删除配置项中子模块相关条目
rm .git/module/* 删除模块下的子模块目录，每个子模块对应一个目录，注意只删除对应的子模块目录即可
执行完成后，再执行添加子模块命令即可，如果仍然报错，执行如下：

git rm --cached 子模块名称

完成删除后，提交到仓库即可。

12、git batch 打补丁

根据 commit 记录生成的 patch，一般我们可以通过 git log 查看有哪一些 commit

1、使用git format-patch生成所需要的patch

当前分支所有超前master的提交：git format-patch -M master
某次提交以后的所有patch: git format-patch 4e16 --4e16指的是commit名
从根到指定提交的所有patch: git format-patch --root 4e16
某两次提交之间的所有patch: git format-patch 365a..4e16 --365a和4e16分别对应两次提交的名称
某次提交（含）之前的几次提交：git format-patch –n 07fe --n指patch数，07fe对应提交的名称
故，单次提交即为：git format-patch -1 07fe

git format-patch 生成的补丁文件默认从1开始顺序编号，并使用对应提交信息中的第一行作为文件名。如果使用了-- numbered-files选项，则文件名只有编号，不包含提交信息；如果指定了–stdout选项，可指定输出位置，如当所有patch输出到一个文件；可指定-o <dir>指定patch的存放目录；

2、应用patch

先检查patch文件：git apply --stat newpatch.patch
检查能否应用成功：git apply --check newpatch.patch
打补丁：git am --signoff < newpatch.patch
(使用-s或–signoff选项，可以commit信息中加入Signed-off-by信息)

如果应用patch出现问题，发生冲突：

最简单方法是先使用 git am --abort，然后手动的添加此patch, patch -p1 < PATCH，手动解决掉代码冲突，最后使用 git commit -a 提交代码。但是这样做有个问题就是你会失去PATCH中原本包含的commit信息（比如From，Date，Subject，Signed-off-by等）
更多详细可参见： http://linux.die.net/man/1/git-format-patch