如何建立营销性企业网站论文,网站开发方案及报价,wordpress core,wordpress卡车主题Git 仓库中的提交记录保存的是你的目录下所有文件的快照#xff0c;就像是把整个目录复制#xff0c;然后再粘贴一样#xff0c;但比复制粘贴优雅许多#xff01; Git 希望提交记录尽可能地轻量#xff0c;因此在你每次进行提交时#xff0c;它并不会盲目地复制整个目录。… Git 仓库中的提交记录保存的是你的目录下所有文件的快照就像是把整个目录复制然后再粘贴一样但比复制粘贴优雅许多 Git 希望提交记录尽可能地轻量因此在你每次进行提交时它并不会盲目地复制整个目录。条件允许的情况下它会将当前版本与仓库中的上一个版本进行对比并把所有的差异打包到一起作为一个提交记录。 Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有 parent 节点的原因 —— 我们会在图示中用箭头来表示这种关系。对于项目组的成员来说维护提交历史对大家都有好处。 前言 学习网站如下网站包含不常用的10% Git 操作Learn Git Branchinghttps://learngitbranching.js.org/?localezh_CN
请开始你的学习吧 基础篇 一个小型Git 代码库。当前有两个提交记录 —— 初始提交 C0 和其后可能包含某些有用修改的提交 C1。 1.Git commit
git commit 创建一个新的提交记录。 操作修改了代码库并把这些修改保存成了一个提交记录 C2。C2 的 parent 节点是 C1 parent 节点是当前提交中变更的基础 2.Git branch
即使创建再多的分支也不会造成储存或内存上的开销并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。 3.分支与合并 - 1️⃣Git merge
例1 例2 main 继承自 bugFixGit 什么都不用做只是简单地把 bugFix 移动到 main 所指向的那个提交记录。 2️⃣Git Rebase Rebase 实际上就是取出一系列的提交记录“复制”它们然后在另外一个地方逐个的放下去。 Rebase 的优势就是可以创造更线性的提交历史这听上去有些难以理解。如果只允许使用 Rebase 的话代码库的提交历史将会变得异常清晰。 ⭕注意把 bugFix 分支里的工作直接移到 main 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发但实际上它们是并行开发的。 现在 bugFix 分支上的工作在 main 的最顶端同时我们也得到了一个更线性的提交序列。 ⭕提交记录 C3 依然存在树上那个半透明的节点而 C3 是我们 Rebase 到 main 分支上的 C3 的副本。 由于 bugFix 继承自 main所以 Git 只是简单的把 main 分支的引用向前移动了一下而已。 高级篇
1.HEAD HEAD 是一个对当前所在分支的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。 HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。 HEAD 通常情况下是指向分支名的 如果想看 HEAD 指向可以通过 cat .git/HEAD 查看 如果 HEAD 指向的是一个引用还可以用 git symbolic-ref HEAD 查看它的指向。 分离的 HEAD
分离的 HEAD 就是让其指向了某个具体的提交记录而不是分支名。在命令执行之前的状态如下所示
HEAD - main - C1
HEAD 指向 main main 指向 C1 2.相对应用 通过指定提交记录哈希值的方式在 Git 中移动不太方便。在实际应用时并没有像本程序中这么漂亮的可视化提交树供你参考所以你就不得不用 git log 来查查看提交记录的哈希值。 并且哈希值在真实的 Git 世界中也会更长译者注基于 SHA-1共 40 位。例如前一关的介绍中的提交记录的哈希值可能是 fed2da64c0efc5293610bdd892f82a58e8cbc5d8。舌头都快打结了吧... 但Git 对哈希的处理很智能。只需要提供能够唯一标识提交记录的前几个字符即可。 通过哈希值指定提交记录很不方便所以 Git 引入了相对引用。这个就很厉害了! 使用相对引用的话你就可以从一个易于记忆的地方比如 bugFix 分支或 HEAD开始计算。 相对引用非常给力这里我介绍两个简单的用法 使用 ^ 向上移动 1 个提交记录使用 ~num 向上移动多个提交记录如 ~3 1操作符 (^)
把这个符号加在引用名称的后面表示让 Git 寻找指定提交记录的 parent 提交。
main^ 相当于“main 的 parent 节点”。main^^ 是 main 的第二个 parent 节点
例1 例2 2“~”操作符 在提交树中向上移动很多步的话敲那么多 ^ 貌似也挺烦人的于是又引入了操作符 ~。 该操作符后面可以跟一个数字可选不跟数字时与 ^ 相同向上移动一次指定向上移动多少次。 ⭕使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如: git branch -f main HEAD~3会将 main 分支强制指向 HEAD 的第 3 级 parent 提交。 -f 则容许将分支强制移动到那个位置 3.撤销变更 resetrevert
撤销变更由底层部分暂存区的独立文件或者片段和上层部分变更到底是通过哪种方式被撤销的组成。 git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支原来指向的提交记录就跟从来没有提交过一样。 ⭕注意 git reset 很方便但是这种“改写历史”的方法对使用的远程分支是无效的哦 为了撤销更改并分享给别人我们需要使用 git revert。 4.整理提交记录 Git Cherry-pick git cherry-pick 提交号... 将一些提交复制到当前所在的位置HEAD下面 5.交互式的 rebase 知道所需要的提交记录并且还知道这些提交记录的哈希值时用 cherry-pick 不清楚想要的提交记录的哈希值——交互式的 rebase 交互式 rebase 指的是使用带参数 --interactive 的 rebase 命令, 简写为 -i。 如果在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录它还会显示每个提交记录的哈希值和提交说明提交说明有助于你理解这个提交进行了哪些更改。 当 rebase UI界面打开时, 能做3件事: 调整提交记录的顺序通过鼠标拖放来完成删除你不想要的提交通过切换 pick 的状态来完成关闭就意味着你不想要这个提交记录合并提交。 遗憾的是由于某种逻辑的原因我们的课程不支持此功能因此我不会详细介绍这个操作。简而言之它允许你把多个提交记录合并成一个。 6.Git Tags 可以在某种程度上 —— 因为标签可以被删除后重新在另外一个位置创建同名的标签永久地将某个特定的提交命名为里程碑然后就可以像分支一样引用了。 它们并不会随着新的提交而移动。你也不能切换到某个标签上面进行修改提交它就像是提交树上的一个锚点标识了某个特定的位置。 远程篇
1.远程仓库-Git clone
远程仓库却有一系列强大的特性 首先也是最重要的的点, 远程仓库是一个强大的备份。本地仓库也有恢复文件到指定版本的能力, 但所有的信息都是保存在本地的。有了远程仓库以后即使丢失了本地所有数据, 你仍可以通过远程仓库拿回你丢失的数据。 还有就是, 远程让代码社交化了! 既然你的项目被托管到别的地方了, 你的朋友可以更容易地为你的项目做贡献(或者拉取最新的变更)
Rebase 实际上就是取出一系列的提交记录“复制”它们然后在另外一个地方逐个的放下去。
git clone 命令在真实的环境下的作用是在本地创建一个远程仓库的拷贝比如从 github.com。
⭕本地仓库多了一个名为 o/main 的分支, 这种类型的分支就叫远程分支。由于远程分支的特性导致其拥有一些特殊属性
远程分支 反映了 远程仓库(在你上次和它通信时)的状态。这会有助于你理解本地的工作与公共工作的差别 —— 这是你与别人分享工作成果前至关重要的一步.
在你切换到远程分支时自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, 更新了远程分支之后再用远程分享你的工作成果。 o/ 是什么意思
命名规范
remote name/branch name
例 o/main 的分支这个分支就叫 main远程仓库的名称就是 o。
大多数的开发人员会将它们主要的远程仓库命名为 origin并不是 o。这是因为当你用 git clone 某个仓库时Git 已经帮你把远程仓库的名称设置为 origin 了 ⭕Git 变成了分离 HEAD 状态当添加新的提交时 o/main 也不会更新。这是因为 o/main 只有在远程仓库中相应的分支更新了以后才会更新。 2.Git Fetch
Git 远程仓库相当的操作实际可以归纳为两点
向远程仓库传输数据从远程仓库获取数据 Git Fetch 当我们从远程仓库获取数据时, 远程分支也会更新以反映最新的远程仓库 C2,C3 被下载到了本地仓库同时远程分支 o/main 也被更新 1️⃣那么 git fetch 做了些什么
git fetch 完成了仅有的但是很重要的两步:
从远程仓库下载本地仓库中缺失的提交记录更新远程分支指针(如 o/main)
git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。
远程分支反映了远程仓库在最后一次与它通信时的状态git fetch 就是你与远程仓库通信的方式了 。
git fetch 通常通过互联网使用 http:// 或 git:// 协议) 与远程仓库通信。
2️⃣git fetch 不会做的事
git fetch 并不会改变你本地仓库的状态。它不会更新你的 main 分支也不会修改你磁盘上的文件。
⭕许多开发人员误以为执行了 git fetch 以后他们本地仓库就与远程仓库同步了。它可能已经将进行这一操作所需的所有数据都下载了下来但是并没有修改你本地的文件。 3.Git Pull
当远程分支中有新的提交时你可以像合并本地分支那样来合并远程分支。也就是说就是你可以执行以下命令:
git cherry-pick o/maingit rebase o/maingit merge o/main等等
因此由于先抓取更新再合并到本地分支这个流程很常用因此 Git 提供了 Git Pull 这一个专门的命令来完成这两个操作 用 fetch 下载了 C3, 然后通过 git merge o/main 合并了这一提交记录。现在 main 分支包含了远程仓库中的更新在本例中远程仓库名为 origin 4.模拟团队合作
我们引入一个自造命令 git fakeTeamwork “假装”你的同事、朋友、合作伙伴更新了远程仓库有可能是某个特定的分支或是几个提交记录。 fakeTeamwork 默认操作就是在远程仓库的 main 分支上做一次提交。 还可以指定提交的分支或是数量只需要在命令后加上它们就可以了。
通过一个命令我们就模拟队友推送了 3 个提交记录到远程仓库的 foo 分支。 5. Git Push
git push 负责将你的变更上传到指定的远程仓库并在远程仓库上合并你的新提交记录。 ⭕注意 : git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本但是在教程中我们使用的是 upstream。 6.偏离的工作 假设你周一克隆了一个仓库然后开始研发某个新功能。到周五时你新功能开发测试完毕可以发布了。但是 —— 天啊你的同事这周写了一堆代码还改了许多你的功能中使用的 API这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了因此你的工作就变成了基于项目旧版的代码与远程仓库最新的代码不匹配了。 这种情况下, git push 就不知道该如何操作了。如果你执行 git pushGit 应该让远程仓库回到星期一那天的状态吗还是直接在新代码的基础上添加你的代码亦或由于你的提交已经过时而直接忽略你的提交 因为这情况历史偏离有许多的不确定性Git 是不会允许你 push 变更的。实际上它会强制你先合并远程最新的代码然后才能分享你的工作。 什么都没有变因为命令失败了git push 失败是因为你最新提交的 C3 基于远程分支中的 C1。而远程仓库中该分支已经更新到 C2 了所以 Git 拒绝了你的推送请求。 解决办法需要做的就是使你的工作基于最新的远程分支。
最直接的方法就是通过 rebase 调整你的工作。
1️⃣push 之前做 rebase 用 git fetch 更新了本地仓库中的远程分支然后用 rebase 将我们的工作移动到最新的提交记录下最后再用 git push 推送到远程仓库。 git pull --rebase 就是 fetch 和 rebase 的简写 2️⃣merge 替换 rebase git merge 不会移动工作它会创建新的合并提交但是它会告诉 Git 你已经合并了远程仓库的所有变更。这是因为远程分支现在是你本地分支的祖先也就是说你的提交已经包含了远程分支的所有变化 用 git fetch 更新了本地仓库中的远程分支然后合并了新变更到我们的本地分支为了包含远程仓库的变更最后我们用 git push 把工作推送到远程仓库 git pull 就是 fetch 和 merge 的简写类似的 git pull --rebase 就是 fetch 和 rebase 的简写 7.远程服务器拒绝!(Remote Rejected)
