logo of Shuibaco

GitHub中将某Repo移到另一个Repo的二级目录中

2017. / 1,839字 / 2,700阅 / 0评

我估计这个问题应该很简单,简单到网上查不到我能看懂的教程。没办法,谁让我完全不想去看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之所以为人乐道,是因为它能够保留更改历史,后悔药全部都留着呢。如果按照上面的方法新增文件,那么以前的修改就都没有了。保留住历史版本,才是「移动」的终极奥义。于是我照例谷歌了一圈,看了好几个小时,不断感叹怎么这么难,心情宕到极点。负面情绪一上来不得了,「及时止损」「得不偿失」都听不进去。但也凭着这股倔劲儿,愣是成功了,可最终我还是决定使用没有历史的版本,原因请听我娓娓道来。

移动开始

基本逻辑是这样的:

  1. 把需要移动的旧Repo里的内容全部放入一个新建的文件夹
  2. 直接把这个文件夹移动到新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!既然被保留的历史并非最初格式,那么有没有历史记录对于主题代码来说似乎没什么区别了,于是我决定放弃再一个个用命令移动剩余文件夹,而是采用最初那个简单粗暴的方法。虽然有点不甘心,毕竟花费了这么长的时间和精力,甚至牺牲了作息,但只要最后决定是正确的,或者说能够「及时止损」「亡羊补牢」,过程也不会显得那么凄凉了。

916°
合并主题们
Comments
Write a Comment
点击加载Disqus