Web/00-前端工具/02-Git的使用.md

282 lines
8.4 KiB
Markdown
Raw Normal View History

2021-07-29 11:05:48 +08:00
---
title: 02-Git的使用
---
<ArticleTopAd></ArticleTopAd>
2018-06-08 22:49:58 +08:00
2018-06-11 21:11:23 +08:00
## 常见操作
2019-03-13 17:59:25 +08:00
### 全局配置用户信息
2018-06-11 21:11:23 +08:00
```
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'
```
上面这行命令,相当于:
```bash
$ git branch feature_item_recommend // 创建新的分支
$ git checkout feature_item_recommend //切换到新的分支
```
2在新的分支`feature_item_recommend`上,完成开发工作,并 commit 、push。
3将分支`feature_item_recommend`上的开发进度**合并**到master分支
```bash
$ 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`的时候,也是采用同样的步骤。
### 合并分支时,如果存在分叉
2018-10-02 22:10:26 +08:00
![](http://img.smyhvae.com/20180610_1650.png)
2018-06-11 21:11:23 +08:00
比如说上面这张图中最早的时候master分支是位于`C2`节点。我基于`C2`节点new出一个新的分支`iss53`,我在`iss53`上提交了好几个commit。
现在,我准备把`iss53`上的几个commit合并到master上此时发现master分支已经前进到C4了。那该怎么合并呢
合并的命令仍然是:
```bash
$ git checkout master
$ git merge iss53
```
**解释**
这次合并的实现,并不同于简单的并入方式。这一次,我的开发历史是从更早的地方开始分叉的。
由于当前 master 分支所指向的commit (C4)并非想要并入分支iss53的直接祖先Git 不得不进行一些处理。就此例而言Git 会用两个分支的末端C4 和C5和它们的共同祖先C2进行一次简单的三方合并计算。
Git 没有简单地把分支指针右移而是对三方合并的结果作一新的快照并自动创建一个指向它的commitC6如下图所示。我们把这个特殊的commit 称作合并提交mergecommit因为它的祖先不止一个。
值得一提的是Git 可以自己裁决哪个共同祖先才是最佳合并基础这和CVS 或Subversion1.5 以后的版本不同它们需要开发者手工指定合并基础。所以此特性让Git 的合并操作比其他系统都要简单不少。
2018-10-02 22:10:26 +08:00
![](http://img.smyhvae.com/20180610_1710.png)
2018-06-11 21:11:23 +08:00
### 解决合并时发生的冲突
2018-10-02 22:10:26 +08:00
![](http://img.smyhvae.com/20180610_1740.png)
2018-06-11 21:11:23 +08:00
如果 feature1和feature2修改的是同一个文件中**代码的同一个位置**那么把feature1合并到feature2时就会产生冲突。这个冲突需要人工解决。步骤如下
1手动修改文件手动修改冲突的那个文件决定到底要用哪个分支的代码。
2git add解决好冲突后输入`git status`,会提示`Unmerged paths`。这个时候,输入`git add`即可,表示:**修改冲突成功,加入暂存区**。
3git commit 提交。
然后,我们可以继续把 feature1 分支合并到 master分支最后删除feature1、feature2。
**注意**两个分支的同一个文件的不同地方合并时git会自动合并不会产生冲突。
比如分支feture1对index.html原来的第二行之前加入了一段代码。
分支feature2对index.html在原来的最后一行的后面加入了一段代码。
这个时候在对两个分支合并git不会产生冲突因为两个分支是修改同一文件的不同位置。
git自动合并成功。不管是git自动合并成功还是在人工解决冲突下合并成功提交之前都要对代码进行测试。
2018-06-08 22:49:58 +08:00
## 日常操作积累
2018-10-02 22:10:26 +08:00
### 修改密码(曲线救国)
2018-06-10 14:26:30 +08:00
2018-10-02 22:10:26 +08:00
> 网上查了很久没找到答案。最终在cld童鞋的提示下采取如下方式进行曲线救国。
2018-06-10 14:26:30 +08:00
2018-10-02 22:10:26 +08:00
```bash
# 设置当前仓库的用户名为空
git config user.name ""
```
然后,当我们再输入`git pull`等命令行时,就会被要求重新输入*新的*账号密码。此时,密码就可以修改成功了。最后,我们还要输入如下命令,还原当前仓库的用户名:
```
git config user.name "smyhvae"
```
2018-06-10 14:26:30 +08:00
2018-07-01 09:48:21 +08:00
### 修改已经push的某次commit的作者信息
2018-10-02 22:10:26 +08:00
已经push的记录如果要修改作者信息的话只能 通过--force命令。我反正是查了很久但最终还是不敢用公司的仓库尝试。
2018-07-01 09:48:21 +08:00
参考链接:
- [git 修改已提交的某一次的邮箱和用户信息](https://segmentfault.com/q/1010000006999861)
看最后一条答案。
- [修改 git repo 历史提交的 author](http://baurine.github.io/2015/08/22/git_update_author.html)
2018-06-08 22:49:58 +08:00
### 将 `branch1`的某个`commit1`合并到`branch2`当中
切换到branch2中然后执行如下命令
```
git cherry-pick commit1
```
### 20190118-修改GitHub已提交的用户名和邮箱
参考链接:(亲测有效)
- [修改Git全部Commit提交记录的用户名Name和邮箱Email](https://cloud.tencent.com/developer/article/1352623)
- [Mac 运行sh文件也就是传说中的shell脚本](https://blog.csdn.net/yusufolu9/article/details/53706269)
2020-03-19 18:03:03 +08:00
在执行`./email.sh`后,如果出现`permission denied`的错误,可以先执行`chmod 777 email.sh`,修改文件的权限。
2020-05-30 23:24:59 +08:00
### 20200520-将Git 项目迁移到另一个仓库
我们假设旧仓库的项目名称叫`old-repository`,新仓库的项目名称叫`new-repository`。操作如下:
1创建旧仓库的裸克隆
```bash
git clone --bare https://github.com/exampleuser/old-repository.git
```
执行上述命令后,会在本地生成一个名叫 `old-repository.git`的文件夹。
2迁移到新仓库
```bash
cd old-repository.git
git push --mirror https://github.com/exampleuser/new-repository.git
```
这样的话,项目就已经迁移到新仓库了。
注意,我们**不需要**手动新建一个空的新仓库,当我们执行上述命令之后,新仓库就已经自动创建好了。
参考链接:
- [复制仓库](https://help.github.com/cn/github/creating-cloning-and-archiving-repositories/duplicating-a-repository)
- [Git 本地仓库和裸仓库](https://moelove.info/2016/12/04/Git-%E6%9C%AC%E5%9C%B0%E4%BB%93%E5%BA%93%E5%92%8C%E8%A3%B8%E4%BB%93%E5%BA%93/)
2021-11-11 16:17:53 +08:00
### 2021-11-10-提交代码时,绕过 eslint 检查
需求:提交代码时,绕过 eslint 检查
2022-03-03 14:52:46 +08:00
解决办法:用命令行提交,末尾追加`--no-verify`。例如:
2021-11-11 16:17:53 +08:00
```bash
2022-03-03 14:52:46 +08:00
# 提交代码
2021-11-11 16:17:53 +08:00
git commit -m '千古壹号的commit备注' --no-verify
2022-03-03 14:52:46 +08:00
# 推送到远程时,也可以追加 --no-verify以免远程仓库做了 eslint 限制。
git push origin --no-verify
2021-11-11 16:17:53 +08:00
```
2022-01-14 16:43:23 +08:00
### 2021-12-29-切换仓库的源地址
查看源地址:
```
git remote -v
```
切换源地址:
```bash
git remote set-url origin https://xxx.git
```
2020-05-30 23:24:59 +08:00
## git客户端推荐
2019-08-07 14:57:03 +08:00
市面上的Git客户端我基本都用过了我最推荐的一款Git客户端是[Tower](https://www.git-tower.com) 或者 [Fork](https://git-fork.com)。
- GitUp<https://gitup.co/>
20180623时网上看了下Git客户端的推荐排名
2018-10-02 22:10:26 +08:00
![](http://img.smyhvae.com/20180623_1210.png)
2018-10-02 22:10:26 +08:00
**SmartGit**
商业用途收费, 个人用户免费:
2020-05-30 23:24:59 +08:00
2018-10-02 22:10:26 +08:00
![](http://img.smyhvae.com/20180623_1305.png)
2019-04-15 14:27:16 +08:00
2018-06-11 21:11:23 +08:00
## 推荐书籍
- 《pro.git中文版》
2018-06-08 22:49:58 +08:00
## 推荐连接
### 2018-06
- [聊下git pull --rebase](https://www.cnblogs.com/wangiqngpei557/p/6056624.html)
2018-06-11 21:11:23 +08:00