Git学习与使用(三)

对于merge的问题确实非常多。
总结一下必要的在这里。

提交PR后可继续更新该分支以及不必总是fork

这部分内容在 pro git zh v2 178页中有。
有权限的话,其实不必非得在github.com上fork.
实习第一天就被教育这点了。

fork仓库的工作流

那个仓库是非fork的情况,使用的是gitlab,每次也是有PR审核的。

这次,是fork的情况。
使用的方法和操作流,是这样的。

这里面比较符合我的想法,先要拉去上游的信息,然后把自己的仓库强制同步上游的,就不用操心了。

执行指令:

git fetch upstream

接下来我们要在自己的本地分支上,去 rebase 上游原项目的代码,执行指令:

git rebase upstream/main


如果想让上游原项目直接覆盖本地 fork 的项目,可以执行命令:

git reset upstream/main --hard


然后进行强行推送即可,执行命令:

git push --force

不能干净合并的情况

github.com没有显示绿色的合并按钮。
解决这种问题是必要的。
从书上看。

你有两种方法来解决这个问题。你可以把你的分支变基到目标分支中去 (通常是你派生出的版本库中的 master
分支),或者你可以合并目标分支到你的分支中去。

GitHub 上的大多数的开发者会使用后一种方法,基于我们在上一节提到的理由:
我们最看重的是历史记录和最后的合并,变基除了给你带来看上去简洁的历史记录, 只会让你的工作变得更加
困难且更容易犯错。

不停的rebase是很容易出问题的。亲身体会。

合并目标分支到你的分支

最为常用。

如果你想要合并目标分支来让你的拉取请求变得可合并,你需要将源版本库添加为一个新的远端,并从远端抓取内容,合并主分支的内容到你的分支中去,修复所有的问题并最终重新推送回你提交拉取请求使用的分支。

$ git remote add upstream https://github.com/schacon/blink ①
$ git fetch upstream ②
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From https://github.com/schacon/blink
 * [new branch] master -> upstream/master
$ git merge upstream/master ③
Auto-merging blink.ino
CONFLICT (content): Merge conflict in blink.ino
Automatic merge failed; fix conflicts and then commit the result.
$ vim blink.ino ④
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
 into slower-blink
$ git push origin slow-blink ⑤
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/tonychacon/blink
 ef4725c..3c8d735 slower-blink -> slow-blink

这里关键的是第15行,要在add之后commit

如果你一定想对分支做变基并进行清理,你可以这么做,但是强烈建议你不要强行的提交到已经提交了拉取请求的分支。 如果其他人拉取了这个分支并进行一些修改,你将会遇到** 变基的风险** 中提到的问题。 相对的,将变基后的分支推送到 GitHub 上的一个新分支中,并且创建一个全新的拉取请求引用旧的拉取请求,然后关闭旧的拉取请求。

github使用emoji

https://www.webfx.com/tools/emoji-cheat-sheet/
可以从这个网站查询自己想要使用的emoji的在github的评论框中输入的方法。
提交信息中花样繁多的表情。
这个在webclipper中有。
https://github.com/carloscuesta/gitmoji

github的交叉引用

除了议题编号外,你还可以通过使用提交的 SHA-1 来引用提交。 你必须完整的写出 40 位长的 SHA-1,GitHub
会在评论中自动地产生指向这个提交的链接。 同样的,你可以像引用议题一样对派生的项目中的提交或者其他
项目中的提交进行引用。

更新抓取配置

$ git remote add progit https://github.com/progit/progit2.git ①
$ git branch --set-upstream-to=progit/master master ②
$ git config --local remote.pushDefault origin ③

① 添加源仓库并取一个名字,这里叫它 progit
② 将 master 分支设置为从 progit 远端抓取
③ 将默认推送仓库设置为 origin

$ git checkout master ①
$ git pull ②
$ git push ③

① 如果在另一个分支上,就切换到 master
② 从 progit 抓取更改后合并到 master
③ 将 master 分支推送到 origin

这样的话就可以使用来自别人或者说来自其他远程仓库的代码了。
早就在用,但是一直没有写出来。

高级合并

这个章节的内容在269页,是肯定要看的。
但是先放着,暂时没有用到高级合并。遇到的合并冲突实在不行了,也都可以在网页端编辑,gitlab服务也好,github.com也好。

git rm 教训

想要在已经完成的提交中去除一个new文件动作。但是想把这个文件保留在磁盘上。
应该使用的不是git rm
而是git rm --cached

要从 Git 中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交。
可以用 git rm 命令完成此项工作,并连带从工作目录中删除指定的文件,这样以后就不会出现在未跟踪文件清单中了。

另外一种情况是,我们想把文件从 Git 仓库中删除(亦即从暂存区域移除),但仍然希望保留在当前工作目录
中。 换句话说,你想让文件保留在磁盘,但是并不想让 Git 继续跟踪。 当你忘记添加 .gitignore 文件,不小
心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时,这一做法尤其有用。 为达到这一目
的,使用 --cached 选项:
$ git rm --cached README

git rm 命令后面可以列出文件或者目录的名字,也可以使用 glob 模式。比如:
$ git rm log/\*.log
注意到星号 * 之前的反斜杠 \, 因为 Git 有它自己的文件模式扩展匹配方式,所以我们不用 shell 来帮忙展开。
此命令删除 log/ 目录下扩展名为 .log 的所有文件。 类似的比如:
$ git rm \*~
该命令会删除所有名字以 ~ 结尾的文件。

git archieve

git生成干净文件夹
git生成取出.git信息的代码存档,使用的命令是
https://www.jianshu.com/p/98fa58073554

git archieve
posted @ 2022-12-01 15:34  lingr7  阅读(53)  评论(0编辑  收藏  举报