Лучшее на RU-vid
Кино
Авто/Мото
Видеоклипы
Животные
Спорт
Игры
Приколы
Развлечения
Хобби
Наука
Авторизоваться
Зарегистрироваться
No video :(
十分钟学会正确的github工作流,和开源作者们使用同一套流程
码农高天
Подписаться 23 тыс.
Просмотров 97 тыс.
50%
1
Видео
Поделиться
Скачать
Добавить в
这期视频分享一下github工作流,也就是究竟应该如何使用github来维护代码。
Опубликовано:
22 авг 2024
Поделиться:
Ссылка:
Скачать:
Готовим ссылку...
Добавить в:
Мой плейлист
Посмотреть позже
Комментарии :
151
@vista4028
3 месяца назад
真棒,我看过逻辑理解最清晰易懂的。
@victor880824tor
4 месяца назад
公司真的是這樣 實用推
@iamaguest2
2 месяца назад
果然是高级码农,不仅自己逻辑清晰而且表达的这么易懂
@zealouskoo2517
2 месяца назад
如果能再配合一个具体的项目操作就太棒了!非常的感谢,学到了很多!
@zhengliu3362
Месяц назад
讲得不错。能帮到初学git的人,不仅是参加开源项目,还有一些公司也是这个工作流
@way2ml
10 дней назад
经过我一个多月的操练, 这套流程已经掌握了, 非常丝滑. 之前只会在main上操作. 现在真正感受到了Git的魅力. 另外我还教会了一个人. 哈哈. 感谢高天!
@Editor_PG
4 месяца назад
開一個新的專項來講 giuhub 怎麼使用感覺很棒 希望之後還能聽到更多有關 github 方面的概念教學 讓更多初次進到 github 領域的工程師能更快上手 個人是想聽 github 的流水線(GitHub Actions)這部分的介紹
@coladock
4 месяца назад
看標題我也以為是在講 ci 的部份,build image, unit test, lint check, push to docker 之類的😂
@gt689229
4 месяца назад
@@coladock 看到標題也以為是要講 CI/CD +1
@leobrown3780
3 месяца назад
讲得真好,正好是很多视频教程空缺的,正好是我想看的
@LeeeroyDex
4 месяца назад
一般情况下,master都禁止push,必须走合并review流程。
@ca91pdf
4 месяца назад
這不就是他說的嗎?squash and merge
@ruoqihuang7502
4 месяца назад
@@ca91pdf 他的意思是不能直接push to main/master, 必须要pull request,就是得是master/main pull from the feature branch
@LeeeroyDex
4 месяца назад
@@ca91pdf 项目上最好把master也设定为protect
@s8960935
4 месяца назад
我們也是鎖master push,其他branch就隨便add push pull,master核准完MR後同時delete掉feature branch就乾淨了
@Jack-gq5qz
3 месяца назад
@@s8960935 個人也是比較偏好Gitlab的MR這種用法,雖然Github上都是叫做PR
@henryge
3 месяца назад
讲的真的好清晰易懂,感谢
@v2266514
4 месяца назад
建議應該補充說明: rebase, rebase -i 使用上應該要小心,而不是 force push 就完事了。 開源項目通常會有多人協作,隨隨便便就對已經存在於 Remote 的 Commit 進行上述的操作,會搞到其他協作者。
@minkoder
4 месяца назад
原则上,不应该有任何两个人同时在一个(可以被push的)branch上工作。
@v2266514
4 месяца назад
@@minkoder 是的,原則上是這樣 不過實務上,不少公司在實際開發的情境 還是會打破這個原則。 而且你沒辦法保證或說服你的同事遵循這個原則😐
@jasonj3952
4 месяца назад
@@v2266514 破坏原则的人会让工作无法继续,代码出现冲突,只能搁置, 不是提交的人搞了其他开发人员, 是破坏原则的人让搞到项目无法进行, 同一个公司的人还好快速沟通, 开源分布工作的项目估计就卡死,或者严重拖延!
@foobarjohnny
4 месяца назад
@@v2266514这种特例太多了,不应该在十分钟的短视频里讲。
@outshine5482
4 месяца назад
@@v2266514 如果连这个都不遵守,其实也没有必要遵守这套工作流
@samuelsun220
3 месяца назад
exactly 就是工业界的git流程 ,简洁明了。
@wantisin9623
12 дней назад
前面給讚,後面直接介紹rebase我就默默收回讚,問了gpt rebase適合個人、merge適合團隊(關於是否簡化異動軌跡)
@jacky02122012
2 месяца назад
多謝生動的講解,受益非常多。 大神,下次能不能講解一下cherry Pick? 先謝謝了!
@user-vb1vx5yr5i
3 месяца назад
圖文並茂,講解的很清楚,很好!🙂
@0xBRACKET
3 месяца назад
视频讲解的比较清晰,但是这个流程可能更适合于个人项目,或者参与人数比较少的情况。比较活跃和贡献者比较多的项目,有两个问题需要注意:1)Github 上首先还是 fork,这样无论怎么修改怎么 Push 都不会影响到其他人的进程;2)强烈不建议 git push -f,个人项目很难撤销,多人项目如果 maintainer 想要撤销容易引起连锁反应
@michaelwu1996
3 месяца назад
Git push force 是僅限於自己在工作的 branch 吧?這樣不應該影響到其他人
@gz6x
Месяц назад
请问fork repo上的修改怎么提交到原来的官方repo呢?
@0xBRACKET
Месяц назад
@@gz6x 发一个 merge request
@youliangqian
3 месяца назад
很有用的知识,对学习很有帮助😄
@gavintao1071
3 месяца назад
跟我们公司的不是完全一样,不同的点主要在code review的步骤。 github可以直接PR,在remote上就直接把my-feature squash and merge进来,然而,不是所有系统都这么智能的。比如我们的工作流程,就是要先git checkout mainline,然后手动在本地git merge --squash my-feature,然后手动add、commit,但是不push。然后调用公司内部的code review工具,把commit的代码提交成一个code review,组里人review过之后,就可以merge了。区别就是checkout然后merge squash这两步是在本地做,然后同步到remote,还是在remote上做,然后再同步到本地
@kjm15246
3 месяца назад
講解的非常清楚 👍
@tonysiu8562
4 месяца назад
BEST EXPLANATION OF ALL TIME!!
@zacks.s
Месяц назад
视频讲的很好, 不过最好再讲一下 post-pull operations (假如还要在 my-feature 继续开发的话). 否则 my-feature 和 main 版本不一致, 后续可能会有问题. ```sh git checkout my-feature git pull origin main --rebase ``` 假如这个branch不用了, 删掉就行; 或者用从main开新的branch
@hengzhang9671
2 месяца назад
讲解的很好,天天都用,但没这么清晰。
@Pilouface95
4 месяца назад
很有帮助,感谢分享🥰
@yanyiwu
4 месяца назад
這是我看過最簡單清楚的說明了👍 但說真的我還是覺得github flow把事情搞的太複雜😂
@haodeng9639
4 месяца назад
不错,讲的很清晰。
@limjenny7815
3 месяца назад
谢谢大佬带路,很有帮助
@johnrui-ug8nx
3 месяца назад
大佬,期待你出静态语言讲解呀!你讲得真的很好!
@gary-qt7tj
4 месяца назад
多人合作一般推薦使用 merge 而不是 rebase,因為 rebase 會改變 git history 而 merge 不會
@minkoder
4 месяца назад
你在feature branch上的任何history都不会被最终保留。理论上你的feature branch也不应该有多人合作。
@fenix20075
3 месяца назад
但依然看不明白為何不使用merge而是使用rebase + delete feature,使用merge在source tree 會直接顯示feature與main branch 合拼吧?
@user-go5xh3qx9x
3 месяца назад
讲的真好!
@yuyu-ce4fz
Месяц назад
我看過最棒的,以後對自己項目都這樣做好了
@michaelwu1996
3 месяца назад
老師講得很好,只是我的建議是 disk 的 branch 不要刪除,算是留一個備份
@weibao9176
3 месяца назад
太清晰了,感谢
@PotatoMan1491
4 месяца назад
之前我一直納悶pro都是怎麽做的,這個好!
@twjasper
4 месяца назад
清楚!感謝
@wycmiracle
2 месяца назад
说的太好了,别的教程都讲什么add push 也没讲冲突怎么解决 没讲怎么使用
@user-db5mp5fl8p
3 месяца назад
So clear! Thanks 🎉
@WeijingJayLin
3 месяца назад
我這邊 遇到的一般是 用 merge 而不是 rebase,盡可能保留歷史... force 是危險的操作... 公式一個 repo 會有 7~8 人同時維護
@adamaiken00
3 месяца назад
會建議考慮trunk based development多於festure branch
@berwin88
3 месяца назад
感谢分享!
@ihuang7392
3 месяца назад
下次講講 為何rebase is better than merge? 還有cherry pick? 謝謝
@user-kc1ku7fu5o
4 месяца назад
讲的不错。
@heaton1451
3 месяца назад
終於懂了 感謝
@nickel-alloys
4 месяца назад
严谨又高效 不过最好解释一下参数的功能 比如-f会不会有什么危害
@MonkeyDLuffy-cq2lo
Месяц назад
先订阅以后慢慢看
@zishengliang202
4 месяца назад
5:51 应该是 `git pull origin main` 吧, 之前用的都是 `main`
@foobarjohnny
4 месяца назад
你是对的。
@miaohf
4 месяца назад
必须赞
@ArcsaberkxL
4 месяца назад
还以为我看错了,,,10 天前视频,我在 阿b 好早之前看的了😂
@qjfu-ex1hd
4 месяца назад
解决了我的疑惑!!
@kfove7347
3 месяца назад
很有用
@gz6x
Месяц назад
但有些repo比如s3fs只有一个master 分支,那么就必须在个人forked repo修改对吧,那以后再怎么合并回原来的官方repo呢?
@ericchen7849
3 месяца назад
和gitlab流程几乎一模一样,差异在pull request那里,gitlab里面叫merge request。不过也差不多。
@gunale925
4 месяца назад
add commit push太真实了
@alexfu2422
3 месяца назад
应该使用git branch -d而不是-D,-d会检查,-D实际是--delete --force
@fredgan2036
4 месяца назад
有点标题党的感觉,我以为你讲的是github workflow,结果你讲的是git
@郭zq
15 дней назад
nice
@hunterxu9019
Месяц назад
请问你在做Git workflow的视频里用到的画图/ppt软件是什么呀?谢谢
@wonderfulcxm
4 месяца назад
我去,我还以为讲github action,看了半天原来是讲git基础,额。。。
@user-pb7wm7wc9k
4 месяца назад
真的...
@darrenlin7204
4 месяца назад
你省了我十分鐘 感謝
@didi098710
4 месяца назад
基础也需要学习
@Flora7489
3 месяца назад
太感谢了
@shuangg
3 месяца назад
都说了是工作流了
@liucloud6317
3 месяца назад
5:50 好像应该是git checkout -b master',而不是main
@user-fi2ty4bm2n
4 месяца назад
可以做 git checkout -b my-feature develop 嗎? 假定已經有 develop 分支,那建立 my-feature 在 develop 上會有什麼樣的疑慮嗎?
@vaporeon2822
3 месяца назад
想问git rebase 时候用的是 .git 的 main 还是 disk 的 main, 如果是前者, 是否 git fetch origin main && git rebase main 也能达到相同目的, 不需 git pull origin main
@user-wr8mr3we4d
4 месяца назад
我们小团队都在 dev add commit push , master 都被遗忘了 。。。😄
@user-od9gx8xd2j
4 месяца назад
您好 講得真好 我想請問一下 刪掉那些commit只保留一個commit不會一次有太多程式碼修改嗎 這樣要除錯會不會比較不好除錯呢? 用fork的方式如何呢?
@minkoder
4 месяца назад
每个feature squash成一个commit是未来读起来更好读的。如果一次改了太多程序可能说明这个feature不应该一个PR完成。是不是fork和这个事情无关,只是决定了feature branch是在原repo完成还是fork的repo完成。
@user-cx6rg6mr7d
4 месяца назад
感謝!請問在開發新功能(fearture1)的時候,是在main branch 上開發?還是應該新建一個,是在新建另一個dev feature branch在上面開發,結束之後再merge回main呢?是不是每開發一個新feature 就要有一個對應的feature branch? 如果merge 回main之後,main 又新增了幾個commit
@minkoder
4 месяца назад
永远不在main上做任何开发。main上的每一个commit,都应该是feature branch PR过来的(当然是理论上,我自己的个人项目很偶尔也会违背这个原则,但是尽量)。feature merge回main之后,这个feature就完成了。修改这个feature是一个新的feature(这里要看你怎么理解feature这个词,更合适的词可能是task)。这时候从main再branch出来,再做修改。每个feature branch只是保证要做一个完整的commit到main上。
@user-cx6rg6mr7d
4 месяца назад
@@minkoder 感謝您
@AliverLenX
3 месяца назад
现在 git 切分支可以用 git switch [-c] branch-name 了呢
@simpereleven7645
4 месяца назад
如果当我已经将本地的分支合并到主分支后,还没来得及pull request,另一个人也合并了他的代码,如果我们同时在修改同一个文件,那不会造成冲突吗?
@kirito8116
4 месяца назад
开发组的人越多约有用,如果就3~5个人,一把梭其实效率最高
@user-hd5it1bk7c
3 месяца назад
當有bug或是人員開始流動時就是痛苦的開始了
@guliya0000
3 месяца назад
after rebase master, I always get diverged feature branch (Xbehind, Ybefore), do you have a good solution for this situation?
@xtjane
4 месяца назад
大佬,请问在checkout和switch命令之间该如何选择呢
@franciszhang0302
4 месяца назад
天哥,可不可以讲讲实际使用是如何搭配vscode使用的,我用的时候commit时候,会生成一个文件还需要我自己手动取消注释。您讲这个的应该是命令行的git使用,想看看大家都实际是用的什么工作套件。
@gradypark5390
4 месяца назад
VSCode 的 git 源代码管理插件是一样的,只是图形化运行 git 命令。不是很懂“会生成一个文件还需要我自己手动取消注释”是什么意思,能具体说说吗?
@lavonzux
4 месяца назад
下commit時出現的文件叫commit message,是用來描述你這個commit做了/修改了什麼。
@SecludedRain
2 месяца назад
你直接git commit -m " " 在雙引號之間寫入就好commit資訊就好
@Jason-lm2yq
3 месяца назад
我以为要讲github workflow 没想到讲的是workflow
@liuwenming
2 месяца назад
没讲到fork, 我一开始就不知道fork别人项目, 再进行提pr的工作流
@gy0624ww
3 месяца назад
请问,如果git rebase master 之后,在merge request之前, master有更新了。 这种情况怎么办?
@stevekeol
3 месяца назад
UP朱,是不是应该改成github 的工作流程,而非工作流? 工作流的话,几乎都会认为是github action 那一套吧
@0xBRACKET
3 месяца назад
来源于 Github Workflow 这个单词,一般也不会认为是 Github Actions
@teti2148
10 дней назад
Danke!
@teti2148
10 дней назад
GOAT!
@abeltan-ch5tt
Месяц назад
Make simple things complicated. You should have your team members manage commit and pull requests based on their roles and rules.
@huacai168
4 месяца назад
有一个疑问,假如说master分支上squash&merge之后,变成update2。其他分支也在这个基础之上merge进来了master。但update2这个merge的代码有bug,需要回滚,或者需要bugfix,这个时候应该要怎么要操作
@minkoder
4 месяца назад
revert本身是可能出现conflict的,需要手动处理,这个是很正常的事情。但是如果相对大家开发的内容比较独立,即使你的commit之后有很多commits,在revert的时候依然可能是clean的。单独开个PR做revert就好。另外明天会有个视频讲撤销。
@pacersgo
4 месяца назад
我们一般不滚回(gitflow),如果不是紧急的bug就建一个feature 分支,修改后并入develop分支,如果是紧急的bug就建立一个hotfix的分支,直接在main上修改
@John_Shi305
3 месяца назад
讲的还是比较清晰的
@dongwalker6234
3 месяца назад
squash学到了,我们公司都是直接merge。。。
@AdamChou-mu3ow
4 месяца назад
git小白聽一半迷路聽完頭暈嗚嗚嗚😅🥴😵💫😵
@hughtong5551
2 месяца назад
公司和这套流程一摸一样..
@pingpangqiu5605
4 месяца назад
请问一个feature branch什么时候应该做一个commit?应该尽量多一些commit来抓住更多改动的细节还是commit越少越好?既然最后都要squash是不是没必要做太多commit?
@minkoder
4 месяца назад
做多少commit主要影响的是code review和你自己的history track。它不影响合并之后的事情。
@jiazhechen
4 месяца назад
我的理解是,写了一些东西以后,到某一个时间点你会想要跑一下代码看看,初步测试一下这些修改。这个时间点上如果这些初步的测试能通过,那就是一个比较好的commit时间点了。commit不应该太少的原因不只是为了方便其他想要查看开发进度的人理解,也是一种帮助自己整理开发过程思路的手段。如果你的很多东西都堆在一个commit里分不开,那一定程度上说明你的思路也比较混乱,并不能清晰地描述开发过程中的每一个小进展。学会如何把握commit大小本身就是对提高项目规划能力的一种考验。供参考。
@pacersgo
4 месяца назад
请问同时进行多版本开发怎么办?每个版本开一个main branch吗?
@minkoder
4 месяца назад
这种情况相对少一些。但是确实会出现多主branch开发的,一般就不叫main了,每个主力branch都有个自己的名字。
@kevincheng3702
4 месяца назад
所以實務上不會使用到git merge嗎?
@minkoder
4 месяца назад
看团队的喜好。CPython团队就希望feature branch在update到main的时候用merge,因为对code review更友好。
@blchen1
4 месяца назад
@@minkoder 确实如此。我们组和其他隔壁组合作的时候大家都是用merge
@hsiehmin787
4 месяца назад
這一串看不太懂,為什麼merge會對code review友好呢😢
@user-kx9hc1jg6x
4 месяца назад
@@hsiehmin787 我也喜欢merge, 不喜欢rebase. rebase 会打乱原来的顺序. 假设你针对当前的代码添加了新功能还没提交, 但是同事提交了一个破坏更新. 你用rebase把同事的代码放到前面, 自己的放的后面, 最初的提交记录就丢失了.而你用merge会保留所有操作的时间线.
@KL-gc2hx
2 месяца назад
没必要学,装个tortoise git点界面就行了😊
@FluffyNanachi
4 месяца назад
对于个人开发而言,是不是就没必要用这一套流程?除非我是为了适应未来可能的合作流程?
@FluffyNanachi
4 месяца назад
另外,还想问一下,对于审查能不能merge到main的情况,审查者的流程是什么呢?他为了审查代码,总得把要审查的部分在自己的本地check out吧?所以实际上他要在本地pull下来my-feature的分支,然后测试?那如果他要修改合并其他的东西呢?建立一个临时的测试分支吗?
@minkoder
4 месяца назад
哪怕是纯个人项目,也推荐走这个流程,最主要的原因是可以让你的commit history比较干净,bisect问题的时候更方便,尽可能保证每个commit都work。大部分的merge是不需要check out这个branch的,因为有CI的帮助,可以在github action之类的地方跑测试。只需要看新的代码写的怎么样,测试覆盖如何,就行了。一般来说,code review只会提出意见,不会去改别人的branch。
@yangwang9688
4 месяца назад
Local和Disk有什麼區別?
@ICE_WORK
4 месяца назад
Disk就是你的物理磁盘,你的工作目录,你实际编辑代码的地方,保存着你当前所在分支的文件以及用于版本控制的文件。Local则是git的一个功能,即本地仓库的元数据,保存本地仓库的描述信息,比如做了什么修改,当前位于哪一个分支等等信息。Local本质是一些包含上述信息的文件,实际上也保存在你的硬盘上,比如.git文件夹下面。你可以看看add、commit命令前后.git目录下面的文件内容变化。
@LinkChenTW
4 месяца назад
Disk的東西要先commit到Local,在Local處確定這些commit的東西都是正確的,才push到Remote。 你可以想像Local就是你的對外窗口,負責和Remote端的人接洽。至於你的內部(Disk和Local)要怎麼亂怎麼糟,那是你自己去處理,Remote端的人不管。Remote真正關心的是Local交給他的東西。
@jungding
4 месяца назад
懂的人不用听,不懂的听了也还是不懂🙃
@zhizunbao333
4 месяца назад
5:25 在local/my-feature 直接git pull origin main, 如果有conflict,resolve conflict,然后commit and push到remote my-feature. create PR, approve后就可以merge去main了。 这个流程更简洁,有什么潜在问题吗?
@minkoder
4 месяца назад
没问题,merge和rebase都是可选的feature branch方案。只要你意识到你在git pull origin main的时候实际上是做了两个操作,fetch到了local main,同时merge到了current branch就行。因为有的时候你只需要git merge main(如果你的local main已经是最新的)。
@YuelengWang
4 месяца назад
但是一般来说 有commit记录 是不会mess up 的 毕竟只要 reset head到前一个就好了。 anyway 其实是一样的哈哈
@binz735
4 месяца назад
@@minkoder 我是新人,我就是直接在local/my-feature上git pull origin main,然后就是经常有冲突了,老提示merge --no-ff 这跟普通的merge有什么不同;要是再出一期视频讲讲merge的流程以及常见的冲突情况就好了
@zhiqunlai2996
4 месяца назад
@@binz735 推一個,我也想知道常見衝突
@yao5673
3 месяца назад
这是git workflow 不是github
@davidliu5095
4 месяца назад
你自己的github push项目,你merge什么
@kevinsun123
4 месяца назад
沒有正不正確的,只是看 use-case。
@myEsn2E9
3 месяца назад
无语
@jxLin-sd7yq
4 месяца назад
😮太麻煩了
@dennisliu5641
4 месяца назад
聽的頭好暈
@mickypeng1451
4 месяца назад
已經很好懂ㄌ
@chekang6697
4 месяца назад
666
@hornliu2399
3 месяца назад
你的分支已经push到远端了,就要考虑到有别人check out 的可能,要用merge,不要随便rebase。去看看git 的官网教程对rebase 的描述吧,如果你不懂rebase和merge 的区别,那就用merge。。。。也许会乱,但不会错。
Далее
15:51
程式與網頁開發者必備技能!Git 和 GitHub 零基礎快速上手,輕鬆掌握版本控制的要訣!
Просмотров 84 тыс.
15:12
【python】asyncio的理解与入门,搞不明白协程?看这个视频就够了。
Просмотров 10 тыс.
00:23
Переписка с женой 😅 #мягкова #интервью #шоу #личка #юмор #соболев #жена #переписка #смс
Просмотров 88 тыс.
1:01:46
Все о работе в М Видео. Как разводят покупателей в магазинах.
Просмотров 218 тыс.
00:10
Тренд ты мой зайчик по очереди 🐰
Просмотров 158 тыс.
29:38
От первого лица: Лагерь 😱 УГНАЛИ ЯХТУ 🤯 РАЗГРОМИЛИ ЛАГЕРЬ 🥹 ВЫГНАЛИ из СТРАНЫ 😭 ГЛАЗАМИ ШКОЛЬНИКА
Просмотров 2,2 млн
16:02
程序员小姐姐: 编程入门该学哪门语言? Java? Python? JavaScript? 如何加强编程基本功? | 编程语言
Просмотров 366 тыс.
3:24
Top 6 Tools to Turn Code into Beautiful Diagrams
Просмотров 627 тыс.
27:09
[Rust 程序设计语言] 1. Rust 能干什么?怎么搭建环境?
Просмотров 5 тыс.
12:25
【人工智能】500页AI指数报告精华内容解读 | 2024第七版 | 斯坦福人工智能研究所 | 十大洞察 | 开源与闭源对比 | 产业分布 | 国家竞争 | AI智能水平正在接近人类
Просмотров 17 тыс.
27:16
相见恨晚!我這輩子見過最好的學習方法 | CLT認知負荷理論 | 湯質看本質
Просмотров 391 тыс.
16:40
【人工智能】马克扎克伯格最新80分钟访谈精华版 | Llama 3 | AGI | 开源 | Meta AI | 元宇宙Metaverse
Просмотров 21 тыс.
11:00
Python为什么适合编程入门?如何高效学Python? | 推荐Python优质学习资源 | Python入门
Просмотров 202 тыс.
11:41
Intro to Competitive Programming
Просмотров 771 тыс.
1:28:45
C#语言入门详解(017)--字段,属性,索引器,常量
Просмотров 21 тыс.
14:58
黄仁勋:“别再学编程,如果一切重来,我会学习。。。” 聊聊 AI 阴影下的程序员生存技能 | 回到Axton
Просмотров 288 тыс.
00:23
Переписка с женой 😅 #мягкова #интервью #шоу #личка #юмор #соболев #жена #переписка #смс
Просмотров 88 тыс.