• Git 实战(三) | Github 必会高频基础命令与 IDE 的 Git 集成


    GitHub 上我们可以 fork 别人的项目,为了与别人产生一种协作关系,将他人的项目在自己本地创建也一个,这里以霍格沃兹测试学院(Hogwarts)的演练环境做演示:

    1.1) 点击fork按钮对项目进行fork:

    1.2)fork完成后就可以在我们自己的GitHub账户下见到被fork的项目:

    2.1)接着我们使用git clone命令将fork的项目clone到本地:

    这个时候可以将此项目看做是自己的一个项目,可以任意修改;

    2.2)项目的作者可以看到有哪些人fork了自己的项目:

    3.1) 先在本地修改README.md文件为:

    # Hogwarts_Online2 霍格沃兹测试学院定向班第二期演练 try it

    3.2)将文件提交到本地仓库:

    4017efe1cd0a2760d74f77a96b82a914.jpeg

    这个时候可以看到提交的作者已经变成我们自己了;也可以使用git remote -v命令来查看,可见现在本地仓库与远程仓库直接关联的是fork之后的项目:

    ed9442a8c74bef2def79cef9316e29f1.jpeg

    3.3)只用git push命令将本地仓库的文件推到远程仓库中去:

    a0696eab557c9af4fd9e00050c8517fa.jpeg

    如下图可以看到已经成功将修改后的README.md文件推到了GitHub上:

    pr:全称 pull request,当我们修改了 fork 后的项目后,因为不能直接修改别人的项目,这个时候想要将自己的修改与原项目合并,就可以使用 pr 来向原项目作者进行申请

    4.1)发起 pr,点击 New pull request:

    然后我们可以看到仓库路径从我的仓库向原作者项目仓库地址发起 pr 请求,在下面可以看到我对项目的修改 diff:

    4.2)这个时候我们点击Create new pull request按钮,填写描述后再点击Create new pull request按钮:

    9a39977c15f29cfa8e2110ec109473cc.jpege5738e18731e3c97a22dc53cb84eeb95.jpeg

    这个时候原仓库维护人员就可以收到pr,并对其进行审核、评论、merge或close的操作:

    d78b28a90fc29c5674571d2424461c72.jpeg

    5.1) 在文件修改没有冲突(conflict)的时候,可以直接merge:

    5.2) 当文件修改有冲突的时候,就需要原作者去进行RResolve了:

    5.3) 或者有冲突的pr直接close:总结下来有以下三种情况:

    • 无冲突直接merge

    • 有冲突手工merge

    • 有冲突close并重新发起pr

      有时候我们fork了项目,但是很有可能我们对项目的修改会比原项目滞后,这就会导致pr的时候容易出现conflict;为了能让我们知道当前的修改是否conflict,就需要使用git fetch命令了;

      使用 git fetch 拿下来一个远程分支的文件,看一下这个分支和我自己的有什么冲突。

      7.1)先使用git remote -v命令来查看本地仓库与远程仓库的关联关系

    eb191930e9859536e85ca6ef01153c5b.jpeg

    这个时候我们可以增加一个remote,选择原仓库的HTTPS地址,使用git remote add <远端名> <远端地址>命令来添加一个remote:

    5c8e2331ae76d3d447e3653f7e0df93a.jpeg

    7.2)再将远程端的master分支fetch到本地:

    a7b2cc7180d097f910dcf85e55e65d4f.jpeg

    7.3) 这时候使用git merge将当前master分支与远端分支合并:

    74d1a52647ea789ee79eb66a753b7246.jpeg

    结果中我们发现产生了冲突,再使用git status命令查看:

    b3594653306285f4be8058fba58fe6c0.jpeg

    发现两边都修改了README.md,这个时候我们使用vi对README.md进行查看,当我们merge的时候,系统会把文件换成以下的展示模式:

    5b06019c9907f822133b05a8449bcde3.jpeg

    这种展示模式的意思是以等号=为分隔符,等号上方为当前分支的修改,等号下方为远程分支的修改,这样就产生的冲突,我们可以手动进行修改,然后merge:

    d7f1925d77a075c0c8f706a0a5cea909.jpege5ab52bbf9ec58eed66a37b68fce0bf8.jpegbee2d8adba1f8551e8ea426c71f219f4.jpeg

    7.4) 这个时候刷新GitHub,在我们自己的分支仓库中可以看到已经成功将修改进行merge:

    这个时候如果再进行pr的话,遇见conflict的几率就会小的多了命令简单总结:

    git remote add other xxxx git fetch other master git merge remotes/other/masteb8813996bf84e6b03154f0355b982ad6.jpeg

    8.1)将项目用IDEA打开,在Version Control → log中可以看到我们的提交管理线:

    67486655fe4958d33c06b6e220bc472e.jpeg

    8.2)双击文件可以查看文件diff:

    b1501f06260e8273bffd953c3f94b2c9.jpeg

    8.3)在右下角还可以进行Git分支的管理:

    免费领取:性能测试+接口测试+自动化测试+测试开发+测试用例+简历模板+测试文档


  • 相关阅读:
    (二)Python类型总结
    AM@两种余项型泰勒公式的对比和总结@常用函数的麦克劳林公式
    spingboot按照依赖包除了maven还有Gradle,两者的区别?
    SpringBoot整合Redis缓存
    直播协议 python 常见直播协议
    windows配置FTP服务
    轻松上手 | 使用国内资源安装 K3s 全攻略
    【数模之数据分析-2】
    一百七十、Linux——Crontab定时任务调度Kettle脚本
    案例拆解丨逆势增长,瑞幸是怎么打好私域这张牌的?
  • 原文地址:https://blog.csdn.net/Hogwartstester/article/details/126623688