Github move repo
🏕️

Github move repo

Tag
git
Last Edited Time
Dec 20, 2021 08:54 PM
Created
Apr 16, 2021 08:42 AM

仓库迁移

 
If you're wrangling multiple Git repositorites, you'll eventually want to move files from one to another. This tutorial will show you how you can move a full Git repository from one remote server to another. The steps below even allow you to choose which branches and tags to include.
Let’s call the original repository ORI and the new one NEW, here are the steps required to copy everything from ORI to NEW:
1. Create a local repository in the temp-dir directory using:
git clone <url to ORI repo> temp-dir
notion image
2. Go into the temp-dir directory.
3. To see a list of the different branches in ORI do:
git branch -a
notion image
4. Checkout all the branches that you want to copy from ORI to NEW using:
git checkout branch-name
notion image
5. Now fetch all the tags from ORI using:
git fetch --tags
notion image
6. Before doing the next step make sure to check your local tags and branches using the following commands:
git tag
git branch -a
notion image
7. Now clear the link to the ORI repository with the following command:
git remote rm origin
8. Now link your local repository to your newly created NEW repository using the following command:
git remote add origin <url to NEW repo>
9. Now push all your branches and tags with these commands:
git push origin --all
git push --tags
notion image
10. You now have a full copy from your ORI repo.

Extra

If you want to simply copy the entire repository you can use
git clone --mirror <url to ORI repo> temp-dir
to replace step 1 to 5.

Ready to learn Git?Try this interactive tutorial.

 
 
 
【Git】rebase 用法小结
rebase在git中是一个非常有魅力的命令,使用得当会极大提高自己的工作效率;相反,如果乱用,会给团队中其他人带来麻烦。它的作用简要概括为:可以对某一段线性提交历史进行编辑、删除、复制、粘贴;因此,合理使用rebase命令可以使我们的提交历史干净、简洁! 前提:不要通过rebase对任何已经提交到公共仓库中的commit进行修改(你自己一个人玩的分支除外) 当我们在本地仓库中提交了多次,在我们把本地提交push到公共仓库中之前,为了让提交记录更简洁明了,我们希望把如下分支B、C、D三个提交记录合并为一个完整的提交,然后再push到公共仓库。 现在我们在测试分支上添加了四次提交,我们的目标是把最后三个提交合并为一个提交: 这里我们使用命令: git rebase -i [startpoint] [endpoint] 其中-i的意思是--interactive,即弹出交互式的界面让用户编辑完成合并操作,[startpoint] [endpoint]则指定了一个编辑区间,如果不指定[endpoint],则该区间的终点默认是当前分支 HEAD所指向的 commit(注:该区间指定的是一个前开后闭的区间)。 在查看到了log日志后,我们运行以下命令: git rebase -i 36224db 或: git rebase -i HEAD~3 然后我们会看到如下界面: 上面未被注释的部分列出的是我们本次rebase操作包含的所有提交,下面注释部分是git为我们提供的命令说明。每一个commit id 前面的 pick表示指令类型,git 为我们提供了以下几个命令: pick:保留该commit(缩写:p) reword:保留该commit,但我需要修改该commit的注释(缩写:r) edit:保留该commit, 但我要停下来修改该提交(不仅仅修改注释)(缩写:e) squash:将该commit和前一个commit合并(缩写:s) fixup:将该commit和前一个commit合并,但我不要保留该提交的注释信息(缩写:f) exec:执行shell命令(缩写:x) drop:我要丢弃该commit(缩写:d) 根据我们的需求,我们将commit内容编辑如下: 然后是注释修改界面: 编辑完保存即可完成commit的合并了: 当我们项目中存在多个分支,有时候我们需要将某一个分支中的一段提交同时应用到其他分支中,就像下图: 我们希望将develop分支中的C~E部分复制到master分支中,这时我们就可以通过rebase命令来实现(如果只是复制某一两个提交到其他分支,建议使用更简单的命令: git cherry-pick)。 在实际模拟中,我们创建了master和develop两个分支: master分支: develop分支: 我们使用命令的形式为: git rebase [startpoint] [endpoint] --onto [branchName] 其中,[startpoint] [endpoint]仍然和上一个命令一样指定了一个编辑区间(前开后闭),--onto的意思是要将该指定的提交复制到哪个分支上。 所以,在找到C(90bc0045b)和E(5de0da9f2)的提交id后,我们运行以下命令: git rebase 90bc0045b^ 5de0da9f2 --onto master 注:因为[startpoint] [endpoint]指定的是一个前开后闭的区间,为了让这个区间包含C提交,我们将区间起始点向后退了一步。 运行完成后查看当前分支的日志: 可以看到,C~E部分的提交内容已经复制到了G的后面了,大功告成?NO!我们看一下当前分支的状态:当前HEAD处于游离状态,实际上,此时所有分支的状态应该是这样: 所以,虽然此时HEAD所指向的内容正是我们所需要的,但是master分支是没有任何变化的, git只是将C~E部分的提交内容复制一份粘贴到了master所指向的提交后面,我们需要做的就是将master所指向的提交id设置为当前HEAD所指向的提交id就可以了,即: git checkout master git reset --hard 0c72e64 此时我们才大功告成! 注:文中如有任何错误,请各位批评指正!
【Git】rebase 用法小结

Loading Comments...