-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.json
More file actions
2 lines (1 loc) · 27.4 KB
/
index.json
File metadata and controls
2 lines (1 loc) · 27.4 KB
1
2
[{"content":"\r一些维护方法: #\r文章管理: 生成新文章用:hugo new content/posts/\u0026lt;英文标题\u0026gt;/index.md\n本地插入图片在markdown的语法?待研究\n上传posts的提交方式:\n保存各种修改(全选暂存)后,先去命令行执行hugo生成静态文件,然后回来git push public仓库和本地仓库,保持最新,,提交一定要有消息备注?\n最初的教程:https://www.hetong-re4per.com/posts/how-bulid-blog-on-github-page/\nhugo server本地启动\n","date":"2025 February 12","externalUrl":null,"permalink":"/posts/fix_solu/","section":"Posts","summary":"","title":"Fix_solu","type":"posts"},{"content":"","date":"2025 February 12","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"欢迎来到CompJIN的存档点\u0026amp;博客!初次见面抑或是好久不见。\nQQ:3556294024\n欢迎聊天\u0026amp;催更2333\nabout myself: #\r","date":"2025 February 12","externalUrl":null,"permalink":"/","section":"欢迎来到 Blowfish !","summary":"","title":"欢迎来到 Blowfish !","type":"page"},{"content":"\r直接复制粘贴的,markdown格式没改完,, #\r关于LearnGitBranching网站的一些个人解法文章列表\n2023-07-01 16:05:04\n网址: https://learngitbranching.js.org/?locale=zh_CN\ntips:\n解释一些快捷调试本网站的语句:\nreset //重置所有已执行命令(被重置后所有命令数会重新开始计数)\nhide goal //隐藏右边图标栏\ngoal //打开右边图标栏\nlevels //打开选关界面\nobjective //打开提示对话框\n主要 #\rSTAGE 1 基础篇 #\r\u0026ndash;循序渐进地介绍Git主要命令 #\r1.1 Git Commit #\r提示和图标很明显,所以直接提交两遍就好\ngit commit\rgit commit\r1.2 Git Branch #\r学习了 创建分支 git branch 分支名\n和切换分支 git checkout 分支名\n所以审题后,第一想法是创建后切换到bugFix完成要求\n第一解:\ngit branch bugFix git checkout bugFix 根据提示后优化的第二解(一行):\ngit checkout -b bugFix\r//这是新建并同时切换到该分支的意思 1.3 Git Merge 分支与合并 #\r在 Git 中合并两个分支时会产生一个特殊的提交记录,它有两个 parent 节点。翻译成自然语言相当于:“我要把这两个 parent 节点本身及它们所有的祖先都包含进来。”\n解法按照题干要求一步一步来就好(第一解):\n解释\ngit branch bugFix\rgit checkout bugFix\rgit commit git checkout mian\rgit commit\rgit merge bugFix 压缩一下就是优化第二解(5条/5条):\n解释\ngit checkout -b bugFix\rgi commit\rgit checkout main\rgit commit git merge bugFix 1.4 Git Rebase #\r进入一面关底!有没有点兴奋呢(\n第二种合并分支的方法是 git rebase。Rebase 实际上就是取出一系列的提交记录,“复制”它们,然后在另外一个地方逐个的放下去。 Rebase 的优势就是可以创造更线性的提交历史,这听上去有些难以理解。如果只允许使用 Rebase 的话,代码库的提交历史将会变得异常清晰。\n审题,按步骤来得解:\n解释\ngit checkout -b bugfix /*后文将均使用git checkout -b A的形式来取代git branch A 和 git checkout A两条语句*/\rgit commit\rgit checkout main\rgit commit\rgit checkout bugFix\rgit rebase main STAGE 1 ALL CLEAR!!! #\r休息一下,坐和放宽,让我们进入二面。\nSTAGE 2 高级篇 #\r介绍Git的120%酷炫的特性并在提交树上使用和白井黑子相同的能力吧!(迫真)\n2.1分离HEAD #\rHEAD 是一个对当前所在分支的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。\nHEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。\nHEAD 通常情况下是指向分支名的(如 bugFix)。\n如果想看 HEAD 指向,可以通过 cat .git/HEAD 查看, 如果 HEAD 指向的是一个引用,还可以用 git symbolic-ref HEAD 查看它的指向。但是该程序不支持这两个命令)\n言归正传,以下是解法:\ngit checkout C4 是不是很简单?接下来要加大难度了,跟上!\n2.2相对引用1(^) #\r相对引用非常给力,这里我介绍两个简单的用法:\n使用 ^ 向上移动 1 个提交记录 使用 ~ 向上移动多个提交记录,如 ~3\n解释\n解1:\ngit checkout bugFix^ 解2:\ngit checkout C4^ //前两个是移动到上个父级节点\n解3:\ngit checkout bugFix~1\n解4:\ngit checkout C4~1 解5:\ngit checkout bugFix~\n解6:\n//后四个是移动到前n(n=1)个父级节点 2.3相对引用2(~) #\r“如果你想在提交树中向上移动很多步的话,敲那么多 ^ 貌似也挺烦人的,Git 当然也考虑到了这一点,于是又引入了操作符 ~ 。 该操作符后面可以跟一个数字(可选,不跟数字时与 ^ 相同,向上移动一次),指定向上移动多少次.\n你现在是相对引用的专家了,现在用它来做点实际事情。\n我(指网站作者)使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:\ngit branch -f main HEAD~3\n上面的命令会将 main 分支强制指向 HEAD 的第 3 级 parent 提交。”\n接下来是题目分析: 可以观察到,题目要求: 将当前分支(HEAD)判定在C1点上 main从C4移动到C6 bugFix从C5到C0\n还记得前文作者在引入时提到的“git branch -f A B\u0026quot;可以将A分支强行指向B吗? 逃课小寄巧+1 da⭐ze\n所以直接将它们移过去就好了,以下是解:\ngit branch -f main C6 //将main移动到C6\rgit branch -f bugFix C0//将bugFix移动到C0\rgit checkout C1 //使当前分支位于C1 顺带一提,好像这里语序先后可以不用在意? 对于以上的C0,C1点你可以使用相对引用来表示他们;但是C6不能直接用已有可用分支来表示他们,即不能用已知可用节点运用相对引用来表示他们的子节点\n2.4撤销变更 #\rgit reset A~n 撤销A节点的更改并回退到A的第n个父节点(用于本地) git revert 本质上在要撤销的节点后面增添了与要撤销的节点性质相反的子节点,达到撤销该节点的目的(用于远程)\n题目分析: 题干提醒得很明显了,local节点顾名思义是本地节点,所以对应用reset指令撤销更改;pushed就是推送节点即远程节点,对应用revert指令撤销更改\n解:\ngit reset local~1 //撤销local节点的更改并回退到上一个父节点(本地)\rgit checkout pushed //切换当前节点对象为pushed节点\rgit revert pushed//撤销pushed节点(远程) 以上,全解。\nSTAGE 2 ALL CLEAR!!! #\r别着急去打则,再接再厉!\nSTAGE 3 移动提交记录 #\r进入三面,播放BGM:幽雅に咲かせ、墨染の桜 ~ Border of Life(手动滑稽)\n你可能会说:你说得对,但是这是我们东方妖妖梦六面西行寺幽幽子的关底曲啊?\n你先别急,但是我们接下来会学一些和cherry相关的符(命)卡(令)来 和uuz大人一起成为幻想乡偶像吧(\n3.1 Git Cherry-pick 樱符「完全墨染的樱花 -开花-」 #\r我承认以上都是我看见cherry后无端联想瞎扯来引起你们阅读兴趣的,我自裁先(\ngit cherry-pick \u0026lt;提交号\u0026gt;\u0026hellip;\n如果你想将一些提交复制到当前所在的位置(HEAD)下面的话, Cherry-pick 是最直接的方式了。\n例子的话,参考网站演示,比博客的效果会好上一点\n值得一提的是,git cherry-pick 后面可以接很多节点 将你想要移动的节点按顺序输在后面,他们也会按顺序建立新的附节点(即git cherry-pick A B C后就会在ABC的父节点下按顺序接一排A\u0026rsquo;,B\u0026rsquo;,C\u0026rsquo;节点)\n因此这张符卡也很好解:\ngit cherry-pick C3 side^ C7 //目标图要哪个节点要什么顺序,后面跟着输就好 3.2交互式 rebase \u0026ndash;真的很方便!!! #\r当你知道你所需要的提交记录(并且还知道这些提交记录的哈希值)时, 用 cherry-pick 再好不过了 —— 没有比这更简单的方式了。 但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase —— 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了。\n交互式 rebase 指的是使用带参数 \u0026ndash;interactive 的 rebase 命令, 简写为 -i\n如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录,它还会显示每个提交记录的哈希值和提交说明,提交说明有助于你理解这个提交进行了哪些更改。\n当 rebase UI界面打开时, 你能做3件事:\n调整提交记录的顺序(通过鼠标拖放来完成) 删除你不想要的提交(网站通过切换 pick 的状态来完成,关闭就意味着你不想要这个提交记录) 合并提交。 遗憾的是由于某种逻辑的原因,网站课程不支持此功能,因此网站不会详细介绍这个操作。简而言之,它允许你把多个提交记录合并成一个。\n想必打交(指使用交互功能)大家都会吧(确信) 网站给到的教程也很方便 以下是3.2的解,观察目标图,发现在原节点链上的变化是去掉了C2,C4和C5交换了位置 因此我们这样解决它:\ngit rebase -i main~4\r//打开对于C5~C2的交互窗口\r然后手动C4和C5换位置,C2删掉(即网站给的切换状态键Omit点一下变灰掉) 综上\nSTAGE 3 ALL CLEAR!!! #\rSTAGE4 杂项 #\r\u0026ndash;Git 技术、技巧与贴士大集合 #\r4.1本地栈式提交:只取一个提交记录 #\r没有看懂题目的要求(\n自己试试然后就过了,采用了rebase -i和branch -f\ngit rebase -i C4~3\r//选取包含C4的三个节点进行rebase可视化操作\r然后取消掉C2,C3,仅保留C4在队首\rgit branch -f main C4’ 强制把main移动到C4\u0026#39;上 解决。 等会试试cherry-pick的解法\n4.2提交的技巧1:反复利用rebase -i\n技巧精髓如上。\n审题,“先用 git rebase -i 将提交重新排序,然后把我们想要修改的提交记录挪到最前;然后用 git commit \u0026ndash;amend 来进行一些小修改;接着再用 git rebase -i 来将他们调回原来的顺序;最后我们把 main 移到修改的最前端(用你自己喜欢的方法),就大功告成啦!”思路基本上都给了。\n但是git commit \u0026ndash;amend题目没给解释,以下是chatGPT3.5给出解释:git commit \u0026ndash;amend是一个用于修改最新一次提交的命令,执行后打开一个文本编辑器提供对当前节点的修改。大抵懂了就着手解题。 解:\ngit rebase -i HEAD~2 //提示写了就直接照做\r手动交换C2和C3节点顺序\rgit commit --amend //模拟修改过程,得到C2\u0026#39;\u0026#39;\rgit rebase caption~2 //再次交换顺序排回去\r手动交换C2\u0026#39;\u0026#39;和C3\u0026#39;的顺序\rgit branch -f main caption//把main移动到caption 4.3 提交的技巧2: #\rrebase的冲突,看uuz的樱符如何解决 审题后,写出了两行代码后不知所措(\ngit checkout newImage\rgit commit --amend 跑去回顾了cherry-pick的用法(uuz大人对不起QAQ\n摸鱼了大概二三十分钟后回来突发奇想:\ngit checkout main\r/*绕过了C2\u0026#39; 提交已经存在于你的改动集里,已忽略! 的问题*/\rgit cherry-pick C2\u0026#39; C3 然后过了 适当摸鱼有助激发灵感?(什,这就是摸鱼的借口吗(\n4.4Git Tags 操纵永远程度的能力(不是 #\r相信通过前面课程的学习你已经发现了:分支很容易被人为移动,并且当有新的提交时,它也会移动。分支很容易被改变,大部分分支还只是临时的,并且还一直在变。\n你可能会问了:有没有什么可以永远指向某个提交记录的标识呢,比如软件发布新的大版本,或者是修正一些重要的 Bug 或是增加了某些新特性,有没有比分支更好的可以永远指向这些提交的方法呢?\n当然有了!Git 的 tag 就是干这个用的啊,它们可以(在某种程度上 —— 因为标签可以被删除后重新在另外一个位置创建同名的标签)永久地将某个特定的提交命名为里程碑,然后就可以像分支一样引用了。\n更难得的是,它们并不会随着新的提交而移动。你也不能切换到某个标签上面进行修改提交,它就像是提交树上的一个锚点,标识了某个特定的位置。\n经过初步学习,我们知道它的用法是:git tag \u0026lt;tag名称\u0026gt; \u0026lt;对象分支\u0026gt; 题干很简单,告诉你对XX标记XX就行:\ngit tag v0 C1\rgit tag v1 C2\rgit checkout C2 4.5Git Describe 锚点?传送锚点?wc,op(我是梗小鬼 #\rgit describe 的语法是: git describe \u0026lt;ref\u0026gt;\n可以是任何能被 Git 识别成提交记录的引用,如果你没有指定的话,Git 会使用你目前所在的位置(HEAD)。\n它输出的结果是这样的: \u0026lt;tag\u0026gt;_\u0026lt;numCommits\u0026gt;_g\u0026lt;hash\u0026gt;\ntag 表示的是离 ref 最近的标签, numCommits 是表示这个 ref 与 tag 相差有多少个提交记录, hash 表示的是你所给定的 ref 所表示的提交记录哈希值的前几位。\n当 ref 提交记录上有某个标签时,则只输出标签名称\n这个关卡为体会为主,体验够了输入git commit结束关卡就好,不需要过多解2333\nSTAGE 4 ALL CLEAR!!! #\rSTAGE 5 高级话题 #\r\u0026ndash;只为成为真正的勇士!\n5.1多次rebase #\r题目没有给过多有用信息,但是你可能猜到这次与情景中的有序提交有关。\n初见审题,先把分支整理一下,合并到只剩下两条:\ngit rebase C2 C3\rgit branch -f bugFix C3\u0026#39;\rgit rebase C6 C7\rgit branch -f another C7\u0026#39;\r然后把右边分支接到C3\u0026#39;的下面,再移动对应分支到指示点:\rgit rebase C3\u0026#39; another git branch -f side C6\u0026#39;\rgit branch -f main another 当然,这还不是最优解,毕竟(7/4) 先过了再说,回头研究优化解( 标准答案解参考如下(\ngit rebase main bugFix\rgit rebase bugFix side\rgit rebase side another\rgit rebase another main ####5.2 两个parent节点\n操作符 ^ 与 ~ 符一样,后面也可以跟一个数字。\n但是该操作符后面的数字与 ~ 后面的不同,并不是用来指定向上返回几代,而是指定合并提交记录的某个 parent 提交。还记得前面提到过的一个合并提交有两个 parent 提交吧,所以遇到这样的节点时该选择哪条路径就不是很清晰了。\nGit 默认选择合并提交的“第一个” parent 提交,在操作符 ^ 后跟一个数字可以改变这一默认行为。\n链式操作:e.g.:\ngit checkout HEAD~;git checkout HEAD^2;git checkout HEAD~2\n以上等效于\ngit checkout HEAD~^2~2\n题干同样明了,让我们用相对引用的方式在C2上得到bugWork节点\n解1:\ngit branch bugWork //创建bugWork节点\rgit branch -f bugWork main~^2~1\r/*将bugWork移动到main的上一级的第二个父节点的上一个节点(即C2)*/ 解2: 那么,为什么不直接在C2上创建bugWork节点呢?\ngit branch bugWork main~^2~1 这就是最优解了。\n5.3纠缠不清的分支 #\r来到五面关底,但是它的终符很水。 没给过多描述?没关系。 掏出你的『樱符』-cherry-pick吧!见招拆招!\n解1:\ngit checkout one git cherry-pick C4 C3 C2\rgit checkout two\rgit cherry-pick C5 C4\u0026#39; C3\u0026#39; C2\u0026#39;\rgit branch -f three C2 终符击破!\n顺带一提,这次的提示里面给出了一条新的控制台命令show solution来查阅标准答案 让我们和标准答案比较一下\ngit checkout one\rgit cherry-pick C4 C3 C2\rgit checkout two\rgit cherry-pick C5 C4 C3 C2\rgit branch -f three C2 我的答案的哈希值比它更精准!赢!(x\nSTAGE 5 ALL CLEAR!!! #\r远程-EXTRA #\rBGM:秘匿されたフォーシーズンズ~The Concealed Four Seasons\nEX1 Push \u0026amp; Pull —— Git 远程仓库! #\r是时候分享你的代码了,让编码变得社交化吧\nEX1.1 Git Clone #\r从技术上来讲,git clone 命令在真实的环境下的作用是在本地创建一个远程仓库的拷贝(比如从 github.com)。 但在教程中使用这个命令会有一些不同 —— 它会在远程创建一个你本地仓库的副本。显然这和真实命令的意思刚好相反,但是它帮咱们把本地仓库和远程仓库关联到了一起,在教程中就凑合着用吧。\n本关同样以体验为主,可以自己尝试\n解如下!\n只要 git clone 就可以了!\nEX2.1 远程分支 #\r这下真有o了,但是它是origin即对远程仓库的默认名称的缩写。\n仍然体验为主。\ngit commit git checkout o/main\rgit commit EX1.3 Git Fetch #\rgit fetch 完成了仅有的但是很重要的两步:\n从远程仓库下载本地仓库中缺失的提交记录 更新远程分支指针(如 o/main) git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。\n如果你还记得上一节课程中我们说过的,远程分支反映了远程仓库在你最后一次与它通信时的状态,git fetch 就是你与远程仓库通信的方式了!希望我说的够明白了,你已经了解 git fetch 与远程分支之间的关系了吧。\ngit fetch 通常通过互联网(使用 http:// 或 git:// 协议) 与远程仓库通信。\n还是体验 所以 git fetch就好\nEX1.4 Git Pull #\r实际上,由于先抓取更新再合并到本地分支这个流程很常用,因此 Git 提供了一个专门的命令来完成这两个操作。它就是我们要讲的 git pull。\n也就是说,git pull是git fetch和git merge的缩写。\n本关运行 ``git pull `命令就可以了!\nEX1.5 模拟团队合作 #\r按照题意一步一步来\ngit clone //先在本地克隆远程仓库\rgit fakeTeamwork main 2//按照图表在远程模拟2次更改\rgit commit//按照图标在本地进行一次提交\rgit pull//在本地拉取远程更改 EX1.6 Git Push #\rgit push 负责将你的变更上传到指定的远程仓库,并在远程仓库上合并你的新提交记录。一旦 git push 完成, 你的朋友们就可以从这个远程仓库下载你分享的成果了!\n你可以将 git push 想象成发布你成果的命令。它有许多应用技巧,稍后我们会了解到,但是咱们还是先从基础的开始吧……\n解: 非常简单,看图写写就好\ngit commit\rgit commit\rgit push EX1.7 偏离的提交历史 #\r情景非常真实,泪目了(\ngit pull 就是 fetch 和 merge 的简写\ngit pull \u0026ndash;rebase 就是 fetch 和 rebase 的简写!\n按照明确的工作流,解如下:\ngit clone\rgit fakeTeamwork\rgit commit\rgit pull --rebase\rgit push EX1.8 锁定的main #\r由已知得:\ngit branch feature //本地创建feature分支 git reset o/main //重置main\rgit push //推送新的 EXTRA 1 ALL CLEAR!!! #\rEXTRA 2 关于 origin 和它的周边—Git远程仓库高级操作 #\r做一名仁慈的独裁者一定会很有趣……\nEX2.1推送主分支 #\r关卡描述看似很难?照样击破它!\n首先我们注意到,远程有C8,但本地没C8\n所以先想办法把C8拉过来,顺带一提,这里不能直接pull \u0026ndash;rebase,可以用fetch\n拉过本地后把其他的C拉到C8下按顺序排好\n最后推送到远端\n解一:\ngit fetch\rgit checkout o/main\rgit cherry-pick side1 C3 side2 C5 C6 side3\rgit branch -f main C7\u0026#39;\rgit branch -f side1 C2\u0026#39;\rgit branch -f side2 C4\u0026#39;\rgit branch -f side3 C7\u0026#39;\rgit checkout main\rgit push 初见过于依赖cherry-pick的后果是(9/6)比较繁琐\n让我们show sloution一下\ngit fetch\rgit rebase o/main side1\rgit rebase side1 side2\rgit rebase side2 side3\rgit rebase side3 main\rgit push 标准答案用的是rebase解(6/6)\nEX2.2合并远程仓库 #\r在开发社区里,有许多关于 merge 与 rebase 的讨论。以下是关于 rebase 的优缺点:\n优点:\nRebase 使你的提交树变得很干净, 所有的提交都在一条线上\n缺点:\nRebase 修改了提交树的历史\n解:用merge替换上题的rebase 初见解(10/6):\ngit fetch\rgit checkout side1\rgit merge C8\rgit merge C4\rgit merge C7\rgit branch -f side1 C2\rgit branch -f main C11\rgit push\rgit checkout main\rgit push 优化一下(8/6):\ngit checkout C2 git merge C8\rgit merge C4 git merge C7\rgit branch -f main C11\rgit checkout main\rgit push 剩下的优化下次一定,能跑就行.jpg\nEX2.3 远程跟踪分支 #\r你可以让任意分支跟踪 o/main, 然后该分支会像 main 分支一样得到隐含的 push 目的地以及 merge 的目标。 这意味着你可以在分支 totallyNotMain 上执行 git push,将工作推送到远程仓库的 main 分支上。\n有两种方法设置这个属性,第一种就是通过远程分支切换到一个新的分支,执行:\ngit checkout -b totallyNotMain o/main 就可以创建一个名为 totallyNotMain 的分支,它跟踪远程分支 o/main。\n另一种设置远程追踪分支的方法就是使用:git branch -u 命令,执行:\ngit branch -u o/main foo 这样 foo 就会跟踪 o/main 了。如果当前就在 foo 分支上, 还可以省略 foo: git branch -u o/main 我们要做到不切换到main的前提完成本关,因此得采取一些特殊技巧\ngit checkout -b side\rgit branch -u o/main side\rgit pull\rgit checkout C1\rgit commit\rgit checkout side\rgit cherry-pick C3\rgit push\r//(8/4)压代码?下次一定,没checkout main就是胜利 EX2.4Git push 的参数 #\r很好! 既然你知道了远程跟踪分支,我们可以开始揭开 git push、fetch 和 pull 的神秘面纱了。我们会逐个介绍这几个命令,它们在理念上是非常相似的。\n首先来看 git push。在远程跟踪课程中,你已经学到了 Git 是通过当前所在分支的属性来确定远程仓库以及要 push 的目的地的。这是未指定参数时的行为,我们可以为 push 指定参数,语法是:\ngit push \u0026lt;remote\u0026gt; \u0026lt;place\u0026gt; 参数是什么意思呢?我们稍后会深入其中的细节, 先看看例子, 这个命令是:\ngit push origin main 把这个命令翻译过来就是:\n切到本地仓库中的“main”分支,获取所有的提交,再到远程仓库“origin”中找到“main”分支,将远程仓库中没有的提交记录都添加上去,搞定之后告诉我。\n我们通过“place”参数来告诉 Git 提交记录来自于 main, 要推送到远程仓库中的 main。它实际就是要同步的两个仓库的位置。\n需要注意的是,因为我们通过指定参数告诉了 Git 所有它需要的信息, 所以它就忽略了我们所切换分支的属性!\n以上为网站作者废话 以下两行解决:\ngit push origin main\rgit push origin foo EX2.5Git push 参数 2 #\r来看看git的离谱操作:如果来源和去向分支的名称不同,同样可以做到\n要同时为源和目的地指定 的话,只需要用冒号 : 将二者连起来就可以了:\ngit push origin \u0026lt;source\u0026gt;:\u0026lt;destination\u0026gt; 这个参数实际的值是个 refspec,“refspec” 是一个自造的词,意思是 Git 能识别的位置(比如分支 foo 或者 HEAD~1)\n以上还是废话 非常简单!\ngit push origin C6^:foo\rgit push origin foo:main EX2.6Git fetch 的参数 #\rgit fetch 的参数和 git push 极其相似。他们的概念是相同的,只是方向相反罢了(因为现在你是下载,而非上传)\n解:\ngit fetch origin foo:main\rgit fetch origin main^:foo\rgit checkout foo\rgit merge main EX2.7没有 source 的 source #\r古怪的 Git 有两种关于 的用法是比较诡异的,即你可以在 git push 或 git fetch 时不指定任何 source,方法就是仅保留冒号和 destination 部分,source 部分留空。\ngit push origin :side git fetch origin :bugFix\n如果 push 空 到远程仓库会如何呢?它会删除远程仓库中的分支!\n如果 fetch 空 到本地,会在本地创建一个新分支。\n这个关卡很容易 —— 只要删除一个远程的分支, 再用 git fetch 在本地创建一个新分支就可以了!\n解如下:\ngit push origin :foo\rgit fetch origin :bar EX2.8Git pull 的参数 #\r终于来到最后一关辣!\n既然你已经掌握关于 git fetch 和 git push 参数的方方面面了,关于 git pull 几乎没有什么可以讲的了 :)\n因为 git pull 到头来就是 fetch 后跟 merge 的缩写。你可以理解为用同样的参数执行 git fetch,然后再 merge 你所抓取到的提交记录。\n以下命令在 Git 中是等效的:\ngit pull origin foo 相当于:\ngit fetch origin foo; git merge o/foo 还有\u0026hellip;\ngit pull origin bar~1:bugFix 相当于:\ngit fetch origin bar~1:bugFix; git merge bugFix 看到了? git pull 实际上就是 fetch + merge 的缩写, git pull 唯一关注的是提交最终合并到哪里(也就是为 git fetch 所提供的 destination 参数)\n好啦, 该结束了!请按照目标窗口中的状态进行操作。你需要下载一些提交,然后创建一些新分支,再合并这些分支到其它分支, 但这用不了几个命令 :P\n//以下是初见笨方法(10/2)\rgit fetch origin main:C2\rgit fetch origin main:side\rgit checkout foo\rgit merge main\rgit checkout side\rgit merge C5\rgit branch -f main C6\rgit branch -f side C2\rgit branch -f foo C3\rgit checkout main 2333\n//优化解:\ngit pull origin bar:foo\rgit pull origin main:side 至此,终符击破!!!!!!!!!!!!\nSTAGE EX2 ALL CLEAR!!!!!!!!!!!! #\rCongratulations! 感谢你看到这里(虽然说可能这里没几个人会看) 谢谢苗爷指导,各位的陪伴和自己没有中途而废\n评论:\n发 布\n• CompJIN_WLAN 2023-07-02 11:26:50\n2023/7/2 11:25主要部分完成击破 EX面(远程)等会继续推进\n• CompJIN_WLAN 2023-07-02 11:26:44\n2023/7/2 11:25主要部分完成击破 EX面(远程)等会继续推进\n• xie_lzh 2023-07-02 10:44:20\n好好好\n来自 https://www.luogu.com.cn/blog/RhodesIsland/gitlearning\n","date":"2025 February 3","externalUrl":null,"permalink":"/posts/learngitbranching/","section":"Posts","summary":"","title":"关于LearnGitBranching网站学习的个人题解","type":"posts"},{"content":"参考https://www.runoob.com/markdown/md-code.html\n深海巨型大水虱大王具足虫\n删除~~,换行双空格\n图片测试 #\r本地图像1\n网络图像1(github为图床) 网络图像2(洛谷图床) 明码卡片测试 #\r**警告!**此操作具有破坏性!\rThis is an error!\rNew article!\rnunocoracao/blowfish\rPersonal Website \u0026amp; Blog Theme for Hugo\rHTML 1695\r459\r文字测试 #\r1# #\r2# #\r3# #\r4# #\r5# #\r6# #\r\u0026mdash;分割线\u0026mdash;\n斜体文本\n斜体文本\n粗体文本\n粗体文本\n粗斜体文本\n粗斜体文本\n代码块三个```或者是四个空格\nprintf()\n","date":"2025 February 2","externalUrl":null,"permalink":"/posts/basic/","section":"Posts","summary":"","title":"Basic test#1","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]