优化:将各分类菜单聚合到一个导航菜单下
This commit is contained in:
104
repos/categories/fragments/2022/03/25.合并两个Git仓库的历史提交记录.md
Normal file
104
repos/categories/fragments/2022/03/25.合并两个Git仓库的历史提交记录.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: 合并两个Git仓库的历史提交记录
|
||||
author: 查尔斯
|
||||
date: 2022/03/25 21:30
|
||||
categories:
|
||||
- 杂碎逆袭史
|
||||
tags:
|
||||
- Git
|
||||
---
|
||||
|
||||
# 合并两个Git仓库的历史提交记录
|
||||
|
||||
## 前言
|
||||
|
||||
**C:** 最近在下班的时间一直在维护一个基于 EL-Admin 这个开源后台管理系统的衍生开源项目。EL-Admin 这个项目是采用前后端分离架构开发的,所以在开源平台上是分为了两个项目库,一个前端的,一个后端的。
|
||||
|
||||
这本无可厚非,分成两个项目库,在开发时还是挺友好的,公司内部基本也是这个模式,但对于一个开源项目来说,分散为两个库还是有一些不利的方面。
|
||||
|
||||
1. 在管理 issue 上不太方便,项目作者要兼顾查看两个项目,而且有些小伙伴在提出 issue 时并不会管你这是前端库还是后端库,提就完事了。在这方面,EL-Admin 项目的作者应该也发现了这个问题,所以直接干脆的关闭了前端库的 issue 功能,集中在后端库一起管理。
|
||||
2. 在 star 方面会造成分流,前段时间看了看微博,在不知什么时候,竟然加入了一个明星超话,意外就看到置顶帖里标注了一点禁止创建其他小号超话,现在想想这不是一个意思吗?
|
||||
3. ...
|
||||
|
||||
本来笔者最开始也是按原项目形式创建了两个 Git 仓库,但最近更换设备开发时单独要拉两次仓库,觉得很麻烦,思索了下突然意识到上述问题,干脆趁着这热乎劲儿,以后端仓库为主,把两个仓库合并一下。
|
||||
|
||||
## 解决方案
|
||||
|
||||
### 将前端项目提交到后端库
|
||||
|
||||
这是笔者首先想到的方法,即将前端项目拉下来,然后将前端项目的源码放到后端库里,提交一下。很简单粗暴,但是这种方法会造成之前前端项目历史提交记录的丢失。
|
||||
|
||||
### 不影响提交记录,合并仓库
|
||||
|
||||
笔者当然不希望将前端项目的历史提交记录丢失了,所以最终采用了下方的方案,完整步骤如下:
|
||||
|
||||
::: tip 笔者说
|
||||
|
||||
提示说明一下,后端仓库名叫:eladminx,前端仓库名叫:eladminx-web
|
||||
|
||||
:::
|
||||
|
||||
1. 克隆后端项目仓库到本地(笔者没有在 git bash 中操作,而是在 cmd 中进行的)
|
||||
|
||||
```bash
|
||||
git clone https://gitee.com/Charles7c/eladminx.git
|
||||
cd eladminx
|
||||
```
|
||||
|
||||

|
||||
|
||||
2. 将前端仓库作为后端仓库的远程仓库,起别名为 frontend(这个随便起)
|
||||
|
||||
```bash
|
||||
git remote add -f frontend https://gitee.com/Charles7c/eladminx-web.git
|
||||
```
|
||||
|
||||

|
||||
|
||||
3. 将前端仓库的 master 分支(自己选择哪个分支)合并到后端仓库
|
||||
|
||||
```bash
|
||||
git merge --strategy ours --no-commit frontend/master
|
||||
```
|
||||
|
||||

|
||||
|
||||
想法很美,但是报错了:
|
||||
|
||||
```
|
||||
fatal: refusing to merge unrelated histories
|
||||
```
|
||||
|
||||
这是因为后端仓库的本地分支历史记录和前端仓库的历史记录不匹配,人家 Git 怀疑你是不是合并错了,但咱们知道就是要合并,写个声明 “表明出事儿与人家无关”就可以了。
|
||||
|
||||
```bash
|
||||
git merge --strategy ours --allow-unrelated-histories --no-commit frontend/master
|
||||
```
|
||||
|
||||

|
||||
|
||||
4. 将前端仓库的 master 分支内容放到在后端仓库内刚建好的 eladminx-web 文件夹中
|
||||
|
||||
```bash
|
||||
mkdir eladminx-web
|
||||
git read-tree --prefix=eladminx-web/ -u frontend/master
|
||||
```
|
||||
|
||||
5. 提交刚才的修改(毕竟你刚才又合并又创建文件夹的,肯定要提交修改啊)
|
||||
|
||||
```bash
|
||||
git commit -m "迁移前端项目仓库,与后端项目仓库合并"
|
||||
```
|
||||
|
||||
6. 最后将本地的修改强制推送到远程仓库即可
|
||||
|
||||
```bash
|
||||
git push --force
|
||||
```
|
||||
|
||||
到此为止,笔者这两个项目的 master 分支就合并完了,如果你想合并其他分支,例如:dev,那就首先把后端仓库的分支切换到 dev,然后将上述中的 master 这个分支名换为 dev 就可以了。
|
||||
|
||||
## 后记
|
||||
|
||||
**C:** 关于这个合并,你以哪个仓库为主都可以。最后合并的提交记录是以历史提交时间进行降序排列的。
|
||||
|
43
repos/categories/fragments/2022/03/26.修改Git最后一次提交记录的作者和邮箱.md
Normal file
43
repos/categories/fragments/2022/03/26.修改Git最后一次提交记录的作者和邮箱.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: 修改Git最后一次提交记录的作者和邮箱
|
||||
author: 查尔斯
|
||||
date: 2022/03/26 10:30
|
||||
categories:
|
||||
- 杂碎逆袭史
|
||||
tags:
|
||||
- Git
|
||||
---
|
||||
|
||||
# 修改Git最后一次提交记录的作者和邮箱
|
||||
|
||||
## 前言
|
||||
|
||||
**C:** 今天周末了,抽出了一点时间继续维护下之前提到过的衍生开源项目。修了一个 bug 后,提交了一下。但是突然想起来,今天开发用的是工作本,工作本中的 Git author、email 是配的真实姓名和公司邮箱,提交前忘了修改,现在已经推送到开源平台了,这肯定不行啊。
|
||||
|
||||
但是现在即使修改了本地的 Git author、email 配置,历史提交记录也改变不了啊。别着急,看看怎么解决的。
|
||||
|
||||
## 问题解决
|
||||
|
||||
如果你确定是和笔者一样的情况,即确保是要修改最后一次提交记录,无论有没有推送到远程仓库都没问题。解决方法就两步,是不是很简单?
|
||||
|
||||
1. 修改最后一次提交的作者和邮箱信息
|
||||
|
||||
```bash
|
||||
git commit --amend --author="Charles7c <charles7c@126.com>"
|
||||
```
|
||||
|
||||
2. 最后将本地的修改强制推送到远程仓库即可(如果你没推送到远程仓库,这步就不需要执行了)
|
||||
|
||||
```bash
|
||||
git push --force
|
||||
```
|
||||
|
||||
## 后记
|
||||
|
||||
**C:** 另外说一下,如果你要修改最后一次提交记录的 commit message,执行下面的命令就可以了。
|
||||
|
||||
```bash
|
||||
git commit --amend -m "要修改为的提交信息"
|
||||
```
|
||||
|
||||
上方修改作者和邮箱信息的命令,还可以继续加参数 `--date` 来修改提交时间,有需要的话去试试去吧。
|
52
repos/categories/fragments/2022/03/27.修改Git所有提交记录中的作者和邮箱.md
Normal file
52
repos/categories/fragments/2022/03/27.修改Git所有提交记录中的作者和邮箱.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: 修改Git所有提交记录中的作者和邮箱
|
||||
author: 查尔斯
|
||||
date: 2022/03/27 13:00
|
||||
categories:
|
||||
- 杂碎逆袭史
|
||||
tags:
|
||||
- Git
|
||||
---
|
||||
|
||||
# 修改Git所有提交记录中的作者和邮箱
|
||||
|
||||
## 前言
|
||||
|
||||
**C:** 上一篇,笔者介绍了怎么修改 Git 最后一次提交的作者和邮箱信息。那如果你是已经提交了很多次的记录,难道一个个的回退过去修改吗?显然不可能,所以本篇笔者带着大家认识一下如何批量修改 Git 提交记录中的作者和邮箱信息。
|
||||
|
||||
## 问题解决
|
||||
|
||||
解决方法其实就是编写一个脚本来进行批量替换。
|
||||
|
||||
1. 新建一个 sh / bat 格式的脚本文件(如果你是在 cmd 中执行,那就用 bat 格式,如果是在 git bash 中执行就用 sh)
|
||||
|
||||
2. 复制下方脚本内容到脚本文件中,然后编辑替换好错误邮箱、正确作者和邮箱(如果是在 cmd 中执行,#!/bin/sh 就替换为 #!/bin/bat)
|
||||
|
||||
```shell
|
||||
#!/bin/sh
|
||||
|
||||
git filter-branch --env-filter '
|
||||
WRONG_EMAIL="错误的邮箱"
|
||||
NEW_NAME="正确的作者名"
|
||||
NEW_EMAIL="正确的邮箱"
|
||||
|
||||
if [ "$GIT_COMMITTER_EMAIL" = "$WRONG_EMAIL" ]
|
||||
then
|
||||
export GIT_COMMITTER_NAME="$NEW_NAME"
|
||||
export GIT_COMMITTER_EMAIL="$NEW_EMAIL"
|
||||
fi
|
||||
if [ "$GIT_AUTHOR_EMAIL" = "$WRONG_EMAIL" ]
|
||||
then
|
||||
export GIT_AUTHOR_NAME="$NEW_NAME"
|
||||
export GIT_AUTHOR_EMAIL="$NEW_EMAIL"
|
||||
fi
|
||||
' --tag-name-filter cat -- --branches --tags
|
||||
```
|
||||
|
||||
3. 保存脚本
|
||||
|
||||
4. 将脚本文件放到要批量修改提交记录的 Git 仓库中(根目录就行)
|
||||
|
||||
1. 执行脚本
|
||||
|
||||
随后你就会看到,先是提示一个 warn 警告,然后它会一条条的修改以往提交记录,如果错误的提交比较多,那就耐心等一会儿吧。
|
Reference in New Issue
Block a user