敞开成长之旅！这是我参与「日新计划 12 月更文挑战」的第1天，点击查看活动详情。
前言
尽管现在git都用可视化了，可是我仍是比较喜欢结合指令行去做一些事情，尤其是在批量操作的库房的时分。
刚好最近触摸到了一个大型项目，需求频繁的同步各个版别的库房，并在这上面浪费了很多的时刻，有一些场景仍是值得记载一下的。
正常流程
# 最基本
1- 新建库房/分支
2- git clone
3- git add .
4- git commit -m 'aaa'
5- git push
# 本地开始
1- git init
2- git remote add origin "http://gitee..."
3- git push
# 开发特性功用
1- git clone
2- git checkout -b feature/造火箭
3- git add .
4- git commit -m '做推进器1'
5- git add .
6- git commit -m '做推进器2'
7- git add .
8- git commit -m '做推进器3'
9- git checkout master
10- git pull
11- git merge feature/造火箭
12- git push
小细节（多长途库房）
- git push “长途地址别号” “分支名（可加可不加）”
- git pull “长途地址别号” “分支名（可加可不加）”
- git remote add “长途地址别号” “库房地址”
- git merge –strategy-option=ours/theirs B
- git add fileA fileB
- git checkout — [fileA fileB]/ .
几个稍微特别的场景
场景一
前置条件：库房 A(有上千个 commit 记载)，空库房 B。
需求：根据库房 A branch v1.0 commitID asd12345 创立新的分支 v1.0-feature 提交到 库房 B，并保留 commit 记载。
场景二
前置条件：库房 A(很杂乱)，库房 B是由 库房A 经过场景一分离出去的，已经有了新的 commit tree。
需求：将库房 A 中的 连续/不连续 的commit 兼并进 库房 B 的 v1.0-feature 分支，不打乱原有的 commit 记载。
场景三
前置条件：库房 A(很杂乱)，主分支 master、特性分支 feature1、开发分支 dev1，feature1 早于 dev1 且有抵触。
需求：完整的提取 feature ，并 不影响现在的dev环境。
场景四
正常开发 add commit push，因为 commit 不行漂亮，最新一个 commit 不想要了。
场景五
一个 demo 库性质的库房，即你下载了别人的一个库房，库房的提交记载特别整齐，每个 commit 都是一个完整的 demo，你想要把 某个 demo 放在你的项目里边，即 cherrypick 一个跟你的库房彻底没关系的 commitID。
场景六
一个库房两个团队都在更新内容，怎么保证代码兼并时分，两边都不会受到影响？
场景七
三个分支，一个是持续迭代分支，一个是主分支，还有一个或多个是新需求分支，兼并需求的时分，发现需求分支上旧版别把另一个迭代版别覆盖了。
场景八
一个需求经过开发、联调、上线、解决bug一系列操作才完结，期望能把这一系列的 commitID 兼并成 一条记载。
场景九
装备一个本地库房，能够向客户A、客户B、公司库房推送代码。
一个综合性比较强的场景
echo -e "\033[36m :: Start 克隆长途库房 -fe-watermark-- \033[0m" &&
git clone https://gitee.com/RELEASE/watermark.git &&
echo -e "\033[36m :: 进入库房 fe-watermark --- \033[0m" &&
cd fe-watermark &&
echo -e "\033[36m :: 增加新长途地址 \033[0m" &&
git remote add kt https://github.com/project/watermark.git &&
git remote -v &&
echo -e "\033[36m :: 切换至方针分支 --- \033[0m" &&
git checkout di/dev-v1.2.0 &&
echo -e "\033[36m :: 推送 dev_1.0.0--- \033[0m" &&
git checkout -b dev_1.0.0 && git push kt dev_1.0.0 -f &&
echo -e "\033[36m :: 拉取 master--- \033[0m" &&
git pull kt master && git checkout master &&
echo -e "\033[36m :: 比对 master | di/dev-v1.2.0--- \033[0m" &&
git diff di/dev-v1.2.0 master &&
echo -e "\033[36m :: 重置 master--- \033[0m" &&
git reset --hard dev_1.0.0 &&
echo -e "\033[36m :: 再次比对 master | di/dev-v1.2.0--- \033[0m" &&
git diff di/dev-v1.2.0 master &&
echo -e "\033[36m :: 推送 master--- \033[0m" &&
git push kt master -f &&
echo -e "\033[36m :: 完结 - Exit -- \033[0m" &&
cd ..
详细场景是这样的，有一个大型项目，库房30+，需求对所有的库房都新建一个库房并且将现有库房的指定分支重命名推送到新的库房，并且master要和这个重命名的分支同步。
举个实际场景便是，我们公司开发的代码，根据 dev-1.2 改成 xxx-1.0 并新建库房交付给客户，然后加个小条件便是把现在的代码放在master分支上。很不巧的是，昨天刚做了一趟，现在并且代码管理员很交心的给了另一套库房地址，里边的分支愈加明晰。
便是说，我昨天从 A 列表中 将 a 分支 改名 为 a1 同步到了 B 列表，现在 又要把 C 列表当做 A 列表再来一次。关键点是不同源了。B列表又不能新建一遍。
如同工作并不难，难的是怎么保证不犯错，高效的完结这件事情，即使犯错了也能很快的追溯其时发生了什么，迅速的进行解决。
如上指令调用所示，直接完成了这个情况。中心有两个：
- push -f
- reset –hard
还有一些 remote 相关的操作。
之所以写成这么一坨的原因是因为避免犯错，需求修正的只有三个地方，clone 地址，remote 地址，旧分支称号。那么是不是能够这么理解：
- 如果前端写一个表单，就能够经过输入这三个内容太就能够完结者一系列操作了？
- 更高级一点，这些信息本来放在 excel 里边，我也能够经过解析 excel 的方法拿到这三个信息，完成彻底自动化？当然这个需求借助一点 node 的知识，可是不多。
这种纯体力劳动，越少手动操作越少犯错，并且库房越多越能表现优势。
兼并不同来源的分支
$ git merge master –allow-unrelated-histories
拉去长途覆盖本地
$ git reset --hard origin/master
$ git pull origin master
修正长途库房地址
git remote set-url [--push] <name> <newurl> [<oldurl>]
git remote set-url --add [--push] <name> <newurl>
git remote set-url --delete [--push] <name> <url>
装备一个库房对应多个长途库房
如下，git里边的 config 文件长这样：
# .git/config
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hooksPath = .husky
[remote "origin"]
url = https://gitee.com/jci/datasource.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "nlc"]
url = https://github.com/DI-WEB/dataSource.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "di/v_1.2"]
remote = origin
merge = refs/heads/di/v_1.2
[branch "di/dev-v1.2.2"]
remote = nlc
merge = refs/heads/di/dev-v1.2.2
