Git Branching基础操作学习笔记

本文为博主在https://learngitbranching.js.org/?locale=zh_CN 网站上的Git Branching基础操作学习笔记,仅于个人复习以及学习交流使用。目前只学习了1-10,19和20。
后面还有一些在实际开发中的使用笔记。

注:快速查看git仓库的内容:将url中的github改为github1s

一、提交 git commit

git commit

二、新建分支 git branch < branchname >

git checkout < branchname >: 切换到分支

git checkout -b < branchname >:新建并切换到分支

三、合并分支(1) git merge < branchname >

  • 创建新分支 bugFix
  • git checkout bugFix 命令切换到该分支
  • 提交一次
  • git checkout main 切换回 main
  • 再提交一次
  • git mergebugFix 合并到 main
git checkout -b bugfix
git commit
git checkout main
git commit
git merge bugfix

四、合并分支(2) git rebase < branchname >

  • 新建并切换到 bugFix 分支
  • 提交一次
  • 切换回 main 分支再提交一次
  • 再次切换到 bugFix 分支,rebase 到 main 上
git checkout -b bugfix
git commit
git checkout main
git commit
git checkout bugfix
git rebase main

五、在提交树上移动 git checkout < commit >

HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的(如 bugFix)。在你提交时,改变了 bugFix 的状态,这一变化通过 HEAD 变得可见。

git checkout C4(C4是提交记录,而不是分支名)

六、相对引用 git checkout < commit >^

通过指定提交记录哈希值的方式在 Git 中移动不太方便。在实际应用时,并没有像本程序中这么漂亮的可视化提交树供你参考,所以你就不得不用 git log 来查查看提交记录的哈希值。

并且哈希值在真实的 Git 世界中也会更长(译者注:基于 SHA-1,共 40 位)。例如前一关的介绍中的提交记录的哈希值可能是 fed2da64c0efc5293610bdd892f82a58e8cbc5d8。舌头都快打结了吧…

比较令人欣慰的是,Git 对哈希的处理很智能。你只需要提供能够唯一标识提交记录的前几个字符即可。因此我可以仅输入fed2 而不是上面的一长串字符。

首先看看操作符 (^)。把这个符号加在引用名称的后面,表示让 Git 寻找指定提交记录的父提交。

所以 main^ 相当于“main 的父节点”。

main^^main 的第二个父节点

七、~操作符

我使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:

git branch -f main HEAD~3: 将 main 分支强制指向 HEAD 的第 3 级父提交。

git branch -f main C6: 将main分支强制指向C6提交

git checkout HEAD~2: 将HEAD指向它的上两个父级分支

八、撤销变更

git reset < branchname >: 撤销本地仓库变更

git revert < branchname >: 撤销远程仓库变更(实际上是提交了一个新版本)

九、整理提交记录

git cherry-pick <提交号>...

十、交互式 rebase

交互式 rebase 指的是使用带参数 --interactive 的 rebase 命令, 简写为 -i

如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录,它还会显示每个提交记录的哈希值和提交说明,提交说明有助于你理解这个提交进行了哪些更改。

在实际使用时,所谓的 UI 窗口一般会在文本编辑器 —— 如 Vim —— 中打开一个文件。

git rebase -i HEAD~4

十九、远程仓库

远程仓库

远程仓库并不复杂, 在如今的云计算盛行的世界很容易把远程仓库想象成一个富有魔力的东西, 但实际上它们只是你的仓库在另个一台计算机上的拷贝。你可以通过因特网与这台计算机通信 —— 也就是增加或是获取提交记录

话虽如此, 远程仓库却有一系列强大的特性

  • 首先也是最重要的的点, 远程仓库是一个强大的备份。本地仓库也有恢复文件到指定版本的能力, 但所有的信息都是保存在本地的。有了远程仓库以后,即使丢失了本地所有数据, 你仍可以通过远程仓库拿回你丢失的数据。
  • 还有就是, 远程让代码社交化了! 既然你的项目被托管到别的地方了, 你的朋友可以更容易地为你的项目做贡献(或者拉取最新的变更)

现在用网站来对远程仓库进行可视化操作变得越发流行了(像 GitHubPhabricator), 但远程仓库永远是这些工具的顶梁柱, 因此理解其概念非常的重要!

git clone

二十、远程分支

你可能注意到的第一个事就是在我们的本地仓库多了一个名为 o/main 的分支, 这种类型的分支就叫远程分支。由于远程分支的特性导致其拥有一些特殊属性。

远程分支反映了远程仓库(在你上次和它通信时)的状态。这会有助于你理解本地的工作与公共工作的差别 —— 这是你与别人分享工作成果前至关重要的一步.

远程分支有一个特别的属性,在你检出时自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, (更新了远程分支之后)再用远程分享你的工作成果。

远程分支有一个命名规范 —— 它们的格式是: <remote name>/<branch name>

因此,如果你看到一个名为 o/main 的分支,那么这个分支就叫 main,远程仓库的名称就是 o

大多数的开发人员会将它们主要的远程仓库命名为 origin,并不是 o。这是因为当你用 git clone 某个仓库时,Git 已经帮你把远程仓库的名称设置为 origin 了。

在实际开发项目中的使用笔记

在本学期的项目作业中负责前端开发,IDE是webstorm,在git中使用到了分支开发,为各种conflict和rollback踩了不少坑,特此记录。

创建远端和本地分支

远端分支直接在网页上创建

本地同名分支创建并切换到该分支 git checkout -b 本地分支名称

与远端分支同步 git pull origin 远端分支名称

拉取

切换到本地的主分支 git checkout 本地主分支

拉取本地主分支的在远端更新 git pull

切换回本地自己的分支 git checkout 自己分支

rebase将本地主分支合并到自己分支 git rebase 本地主分支

推送

将自己的修改提交到本地分支 git commit

将本地自己的分支推送到远端自己的分支 git push

请求合并到远端主分支,在网页上发起pull request,等待同意。

冲突解决

本地分支因与远端分支冲突而无法push时,先进行 git pull --rebase 在webstorm中手动解决冲突。

おすすめ

転載: blog.csdn.net/ycsss/article/details/116501978