5 篇博文 含有标签「Git」

当需要根据一个已有分支，来创建一个新分支并在上面开发时，这篇内容会很有用。

一般情景是，在 dev 分支开发，此时遇到了一些 bug 需要修复，要根据 dev 分支创建一个 bugfix 分支，在此分支把问题解决，然后推送并发起 pull request 将代码合并到 dev 分支。

步骤​

1.新建分支​

依据：git checkout -b <new-branch> [<start-point>]，创建并切换到 new-branch 分支，如果写上了 start-point 参数，则新分支的 HEAD 将指向它，不写则需要手动设置上游。

start-point：The new branch head will point to this commit. It may be given as a branch name, a commit-id, or a tag. If this option is omitted, the current HEAD will be used instead.

现在以远程的 origin/dev 分支为上游，新建了一个 bugfix 分支。

git checkout -b bugfix origin/dev

2.代码开发​

在 bugfix 分支进行开发。

3.设置上游分支​

现在的上游是 origin/dev，推送时会推到远程 dev 分支。 设置上游可以根据这条命令 git branch -u, --set-upstream-to <upstream> ，-u 简写比较方便，也可以使用完整参数 --set-upstream-to。

git branch -u origin/bugfix

但是这里还不能这样用，因为还没有把本地创建的新分支推送到远程，无法设置远程的上游。因此需要推送并设置上游

git push -u origin bugfix

4.推送​

可以推送到远程仓库

git push

如果没手动设置上游，需要次次都手动推送到指定分支

git push origin bugfix

在这之后，就可以在仓库看到了 bugfix 分支，可以发起合并请求了

Git Rebase 自己压根没用过，正巧公司团队要用到，学习总结一下。

使用场景​

合并提交：完成一个 feature 提交了很多次，有很多杂乱连续的 commit，团队对提交规范要求一个特性对应一次提交，此时需要合并多个提交为一个。

分支变基：多人协作开发时，用 merge 合并分支会多出一个 Merge Commit 的提交，这个提交是两个分支的最新节点的合并项。分支树呈现的是一条线从 main 分支叉出去，经过几个提交，又汇合到 main，汇合处形成了一个提交节点。团队想要让提交记录是线性的，也不想要这个多余的提交，此时适合进行变基。

举例​

有一个提交结点树，C1是首次提交，C4是 hotfix 分支第一次提交。主线是 main 分支。

               C4 <- C5
              /
C1 <- C2 <- C3 <- C6

今天逛 GitHub 时看到了 docusaurus 的仓库，临时起意打算把自己的网站也提交到 showcase 里，没想到居然不一会就被合并了。

上一次提交 pull request 还是在上次...

有时需要提交一次代码，但是有一部分新写上的代码还是半成品，又不舍得删除。或者在切换分支时工作目录和暂存区里那些还没有被提交的修改，它可能会和即将检出的分支产生冲突从而阻止 Git 切换到该分支。

解决方式​

git stash 可以解决这个问题。贮藏（stash）会处理工作目录的脏的状态，即跟踪文件的修改与暂存的改动，然后将未完成的修改保存到一个栈上，而你可以在任何时候重新应用这些改动。

一些常用的命令如下，不算全面但是日常对我来说是够用了。

• git clone url ：克隆项目，如需自定义本地文件夹的名称，在 url 之后加个名称即可。
• git add ：这是个多功能命令，可以用它开始跟踪新文件，或者把已跟踪的发生更改的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。
• git rm ：要从 Git 中移除某个文件，就必须要从暂存区域移除，然后提交。可以用 git rm 完成，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
• git diff ：查看尚未暂存的文件更新了哪些部分。在后面加一个 --staged 参数，将比对已暂存文件与最后一次提交的文件差异。