GitHub中将某Repo移到另一个Repo的二级目录中
我估计这个问题应该很简单，简单到网上查不到我能看懂的教程。没办法，谁让我完全不想去看Git使用手册，却还妄想做这种操作呢。大部分教程提供的思路在我看了十几遍以后也慢慢理解了，但在我终于意识到这些个奇怪的命令应该是写在Git for Windows里时，我却没法判断示例命令中哪些是直接写入的，哪些是根据需要填写的。本来这种举一反三的问题随便看哪个教程都是一样的，但对今天才知道Git里的G不念「吉」而念「歌」的我，最后还是依着跟我需求完全一致的这篇文章才不顺利地完成了迁徙。说不顺利是因为中途Merge卡住了，也因此竟然还学会了放弃Merge的命令。好了废话不多说，这篇文章纯粹是个记录，给破坏了稳定情绪和正常作息的自己一个交待。
起因
随着Bitcron主题越写越多（截止至现在已经9个了），不论是在线预览网站还是GitHub都显得有些杂乱。本来我想着一个主题一个Repo（仓库）简洁清爽，因为还有FarBox和Blogger的主题也放在上面，但打开主页一溜的「Bitcron主题XXX」还是觉得太浪费了。之前也想过一次，不过那时候还在犹豫，而且稍微试了一下发现不是可以简单完成的事就放弃了，却也给心里埋下了一颗小种子。今天小种子发芽了，于是我准备把所有Bitcron主题合并至一个文件夹，如此Star也集中些（心机）。
重开一个仓库
上面说到之前尝试过如何移动文件，同Repo内的移动很简单，要么在GitHub网页上直接修改path，官方也有教程，要么在GitHub Desktop里克隆Repo到本地，然后本地修改再push上去。当然是第二种方法简单咯，还能批量修改。但是，如果是Repo间的移动就不行了，剪切粘贴后push会有错误。所以在以往失败的经验上，我直接复制了所有文件到新开的bitcron-themes仓库里，修改好文件名，push，完成。
保留历史版本
Git之所以为人乐道，是因为它能够保留更改历史，后悔药全部都留着呢。如果按照上面的方法新增文件，那么以前的修改就都没有了。保留住历史版本，才是「移动」的终极奥义。于是我照例谷歌了一圈，看了好几个小时，不断感叹怎么这么难，心情宕到极点。负面情绪一上来不得了，「及时止损」「得不偿失」都听不进去。但也凭着这股倔劲儿，愣是成功了，可最终我还是决定使用没有历史的版本，原因请听我娓娓道来。
移动开始
基本逻辑是这样的：
- 把需要移动的旧Repo里的内容全部放入一个新建的文件夹
- 直接把这个文件夹移动到新Repo中，如此一来就是二级目录了
诶，我才意识到还有local和remote的区别，不管了不管了，总之基本逻辑就是上面这样。所以我先用GitHub Desktop把新旧Repo都克隆到本地，然后在旧Repo中修改内容到二级目录并重命名，同样用GitHub Desktop推送到远方~~刷了一下GitHub页面发现已经生效了，于是进行第二步，打开Git for Windows的Git Bash，话说入门还是因为想要缩短项目网址。按照教程里的写法，命令如下：
$ cd /home/machete/new-project
$ git remote add temp /home/machete/old-project
$ git fetch temp
$ git merge temp/master
$ git remote rm temp
第一步的cd我还特意查了一下才知道是change directory也就是改变目录的意思，毕竟得定位才能操作，能理解。于是我按照上面的写法，以为套入GitHub中的相对地址就行，结果不行……然后又查了一下发现可以直接拖文件夹进去，就能自动定位，于是输入cd后空格，把新Repo也就是bitcron-themes文件夹往里一拖，自己跳出来~/Documents/GitHub/bitcron-themes (master)。接着依葫芦画瓢在第二步里也用同样方法在输入git remote add temp并空格后拖入旧Repo的文件夹，回车。第三步照输没问题，第四步卡住了说：
fatal: refusing to merge unrelated histories
按照评论里的提示，试着输入git merge temp/master --allow-unrelated-histories，结果跳出来不懂什么奇怪的东西，叫我输入merge理由，我随便输入回车也没用，就关闭了Bash重启。重新定位到新Repo下时，地址后面变成了(master|MERGING)，接着按照上面方法重来一遍却被告知正在merging没法进行新的命令，就赶紧跑去谷歌了放弃merge的办法：git merge --abort。反复几次之后我想估计得在输命令时加入merge理由，就按照文中提到的命令猜想-m是message的意思吧？然后输入git merge temp/master --allow-unrelated-histories -m "merge"，引号内就是merge理由了，懒得写就只写了merge。然后就跳出来一长串，看着应该是顺利merge了，然后输入最后一步，再到GitHub Desktop上同步了一下，刷新网页确认移动完成！啊，心好累。
维持原判
前面说过最后还是决定用没有历史版本的，也就是最开始我在本地操作后以新增文件push上去的Repo。因为在我进行了那么多复杂的移动操作后，查看Histories时发现，并不会像原本一样，每个文件点进去能看见各自的历史。历史记录确实被保留了，但全部混在一起，只能在新Repo的目录下才能看到，而谁是谁的历史只能从内容中得知，除非之前你的更新理由都指名道姓，而像我就只耿直地写了更新的理由，所以一头雾水。难怪Git命令要改为不默认merge unrelated histories，因为人家就是unrelated呀，怎么能merge！既然被保留的历史并非最初格式，那么有没有历史记录对于主题代码来说似乎没什么区别了，于是我决定放弃再一个个用命令移动剩余文件夹，而是采用最初那个简单粗暴的方法。虽然有点不甘心，毕竟花费了这么长的时间和精力，甚至牺牲了作息，但只要最后决定是正确的，或者说能够「及时止损」「亡羊补牢」，过程也不会显得那么凄凉了。