共计 3417 个字符，预计需要花费 9 分钟才能阅读完成。
常见操作
全局配置用户信息
git config --global user.name "smyhvae"
git config --global user.email "smyhvae@163.com"
分支的合并
场景：基于 master 分支的代码，开发一个新的特性
如果你直接在 master 分支上开发这个新特性，是不好的，万一你在开发 特性 1 的时候，领导突然又要叫你去开发 特性 2 ，就不好处理了。难道开发的两个特性都提交到 master？一会儿提交特性 1 的 commit，一会儿提交特性 2 的 commit？这会导致 commit 记录很混乱。
所以，我给你的建议做法是：给每个特性都单独建一个的新的分支。
比如说，我专门给 特性 1 建一个分支feature_item_recommend。具体做法如下：
（1）基于 master 分支，创建一个新的分支，起名为feature_item_recommend：
$ git checkout -b feature_item_recommend
Switched to a new branch 'feature_item_recommend'
上面这行命令，相当于：
$ git branch feature_item_recommend // 创建新的分支
$ git checkout feature_item_recommend // 切换到新的分支
（2）在新的分支 feature_item_recommend 上，完成开发工作，并 commit、push。
（3）将分支 feature_item_recommend 上的开发进度 合并 到 master 分支：
$ git checkout master // 切换到 master 分支
$ git merge feature_item_recommend // 将分支 feature_item_recommend 的开发进度合并到 master 分支
合并之后，master分支和 feature_item_recommend 分支会指向同一个位置。
（3）删除分支feature_item_recommend：
既然 特性 1 开发完了，也放心地提交到 master 了，那我们就可以将这个分支删除了。
git branch -d feature_item_recommend
注意，我们当前是处于 master 分支的位置，来删除 feature_item_recommend 分支。如果当前是处于 feature_item_recommend 分支，是没办法删除它自己的。
同理，当我转身去开发 特性 2 的时候，也是采用同样的步骤。
合并分支时，如果存在分叉
比如说上面这张图中，最早的时候，master 分支是位于 C2 节点。我基于 C2 节点，new 出一个新的分支 iss53，我在iss53 上提交了好几个 commit。
现在，我准备把 iss53 上的几个 commit 合并到 master 上，此时发现，master 分支已经前进到 C4 了。那该怎么合并呢？
合并的命令仍然是：
$ git checkout master
$ git merge iss53
解释：
这次合并的实现，并不同于简单的并入方式。这一次，我的开发历史是从更早的地方开始分叉的。
由于当前 master 分支所指向的 commit (C4)并非想要并入分支（iss53）的直接祖先，Git 不得不进行一些处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）和它们的共同祖先（C2）进行一次简单的三方合并计算。
Git 没有简单地把分支指针右移，而是对三方合并的结果作一新的快照，并自动创建一个指向它的 commit（C6）（如下图所示）。我们把这个特殊的 commit 称作合并提交（mergecommit），因为它的祖先不止一个。
值得一提的是 Git 可以自己裁决哪个共同祖先才是最佳合并基础；这和 CVS 或 Subversion（1.5 以后的版本）不同，它们需要开发者手工指定合并基础。所以此特性让 Git 的合并操作比其他系统都要简单不少。
解决合并时发生的冲突
如果 feature1 和 feature2 修改的是同一个文件中 代码的同一个位置，那么，把 feature1 合并到 feature2 时，就会产生冲突。这个冲突需要人工解决。步骤如下：
（1）手动修改文件：手动修改冲突的那个文件，决定到底要用哪个分支的代码。
（2）git add：解决好冲突后，输入 git status，会提示Unmerged paths。这个时候，输入git add 即可，表示：修改冲突成功，加入暂存区。
（3）git commit 提交。
然后，我们可以继续把 feature1 分支合并到 master 分支，最后删除 feature1、feature2。
注意：两个分支的同一个文件的不同地方合并时，git 会自动合并，不会产生冲突。
比如分支 feture1 对 index.html 原来的第二行之前加入了一段代码。
分支 feature2 对 index.html 在原来的最后一行的后面加入了一段代码。
这个时候在对两个分支合并，git 不会产生冲突，因为两个分支是修改同一文件的不同位置。
git 自动合并成功。不管是 git 自动合并成功，还是在人工解决冲突下合并成功，提交之前，都要对代码进行测试。
日常操作积累
修改密码（曲线救国）
网上查了很久，没找到答案。最终，在 cld 童鞋的提示下，采取如下方式进行曲线救国。
# 设置当前仓库的用户名为空
git config user.name ""
然后，当我们再输入 git pull 等命令行时，就会被要求重新输入 新的 账号密码。此时，密码就可以修改成功了。最后，我们还要输入如下命令，还原当前仓库的用户名：
git config user.name "smyhvae"
修改已经 push 的某次 commit 的作者信息
已经 push 的记录，如果要修改作者信息的话，只能 通过 –force 命令。我反正是查了很久，但最终还是不敢用公司的仓库尝试。
参考链接：
看最后一条答案。
将 branch1的某个 commit1 合并到 branch2 当中
切换到 branch2 中，然后执行如下命令：
git cherry-pick commit1
20190118- 修改 GitHub 已提交的用户名和邮箱
参考链接：（亲测有效）
在执行 ./email.sh 后，如果出现 permission denied 的错误，可以先执行chmod 777 email.sh，修改文件的权限。
20200520- 将 Git 项目迁移到另一个仓库
我们假设旧仓库的项目名称叫old-repository，新仓库的项目名称叫new-repository。操作如下：
（1）创建旧仓库的裸克隆：
git clone --bare https://github.com/exampleuser/old-repository.git
执行上述命令后，会在本地生成一个名叫 old-repository.git的文件夹。
（2）迁移到新仓库：
cd old-repository.git
git push --mirror https://github.com/exampleuser/new-repository.git
这样的话，项目就已经迁移到新仓库了。
注意，我们 不需要 手动新建一个空的新仓库，当我们执行上述命令之后，新仓库就已经自动创建好了。
参考链接：
2021-11-10- 提交代码时，绕过 eslint 检查
需求：提交代码时，绕过 eslint 检查
解决办法：用命令行提交，末尾追加--no-verify。例如：
# 提交代码
git commit -m '千古壹号的 commit 备注' --no-verify
# 推送到远程时，也可以追加 --no-verify，以免远程仓库做了 eslint 限制。git push origin --no-verify
2021-12-29- 切换仓库的源地址
查看源地址：
git remote -v
切换源地址：
git remote set-url origin https://xxx.git
git 客户端推荐
市面上的 Git 客户端我基本都用过了，我最推荐的一款 Git 客户端是：Tower 或者 Fork。
- GitUp：https://gitup.co/
20180623 时，网上看了下 Git 客户端的推荐排名：
SmartGit：
商业用途收费，个人用户免费：
推荐书籍
- 《pro.git 中文版》
