十分钟学会正确的github工作流，和开源作者们使用同一套流程 

真棒，我看过逻辑理解最清晰易懂的。

公司真的是這樣 實用推

果然是高级码农，不仅自己逻辑清晰而且表达的这么易懂

如果能再配合一个具体的项目操作就太棒了！非常的感谢，学到了很多！

讲得不错。能帮到初学git的人，不仅是参加开源项目，还有一些公司也是这个工作流

经过我一个多月的操练, 这套流程已经掌握了, 非常丝滑. 之前只会在main上操作. 现在真正感受到了Git的魅力. 另外我还教会了一个人. 哈哈. 感谢高天!

開一個新的專項來講 giuhub 怎麼使用感覺很棒 希望之後還能聽到更多有關 github 方面的概念教學 讓更多初次進到 github 領域的工程師能更快上手 個人是想聽 github 的流水線（GitHub Actions）這部分的介紹

讲得真好，正好是很多视频教程空缺的，正好是我想看的

一般情况下，master都禁止push，必须走合并review流程。

讲的真的好清晰易懂，感谢

建議應該補充說明: rebase, rebase -i 使用上應該要小心，而不是 force push 就完事了。 開源項目通常會有多人協作，隨隨便便就對已經存在於 Remote 的 Commit 進行上述的操作，會搞到其他協作者。

exactly 就是工业界的git流程 ，简洁明了。

前面給讚，後面直接介紹rebase我就默默收回讚，問了gpt rebase適合個人、merge適合團隊(關於是否簡化異動軌跡)

多謝生動的講解，受益非常多。 大神，下次能不能講解一下cherry Pick? 先謝謝了！

圖文並茂，講解的很清楚，很好！🙂

视频讲解的比较清晰，但是这个流程可能更适合于个人项目，或者参与人数比较少的情况。比较活跃和贡献者比较多的项目，有两个问题需要注意：1）Github 上首先还是 fork，这样无论怎么修改怎么 Push 都不会影响到其他人的进程；2）强烈不建议 git push -f，个人项目很难撤销，多人项目如果 maintainer 想要撤销容易引起连锁反应

很有用的知识，对学习很有帮助😄

跟我们公司的不是完全一样，不同的点主要在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上做，然后再同步到本地

講解的非常清楚 👍

BEST EXPLANATION OF ALL TIME!!

视频讲的很好, 不过最好再讲一下 post-pull operations (假如还要在 my-feature 继续开发的话). 否则 my-feature 和 main 版本不一致, 后续可能会有问题. ```sh git checkout my-feature git pull origin main --rebase ``` 假如这个branch不用了, 删掉就行; 或者用从main开新的branch

讲解的很好，天天都用，但没这么清晰。

很有帮助，感谢分享🥰

這是我看過最簡單清楚的說明了👍 但說真的我還是覺得github flow把事情搞的太複雜😂

不错，讲的很清晰。

谢谢大佬带路，很有帮助

大佬，期待你出静态语言讲解呀！你讲得真的很好！

多人合作一般推薦使用 merge 而不是 rebase，因為 rebase 會改變 git history 而 merge 不會

但依然看不明白為何不使用merge而是使用rebase + delete feature，使用merge在source tree 會直接顯示feature與main branch 合拼吧？

讲的真好！

我看過最棒的，以後對自己項目都這樣做好了

老師講得很好，只是我的建議是 disk 的 branch 不要刪除，算是留一個備份

太清晰了，感谢

之前我一直納悶pro都是怎麽做的，這個好！

清楚！感謝

说的太好了，别的教程都讲什么add push 也没讲冲突怎么解决 没讲怎么使用

So clear! Thanks 🎉

我這邊 遇到的一般是 用 merge 而不是 rebase，盡可能保留歷史... force 是危險的操作... 公式一個 repo 會有 7～8 人同時維護

會建議考慮trunk based development多於festure branch

感谢分享！

下次講講 為何rebase is better than merge？ 還有cherry pick? 謝謝

讲的不错。

終於懂了 感謝

严谨又高效 不过最好解释一下参数的功能 比如-f会不会有什么危害

先订阅以后慢慢看

5:51 应该是 `git pull origin main` 吧， 之前用的都是 `main`

必须赞

还以为我看错了，，，10 天前视频，我在 阿b 好早之前看的了😂

解决了我的疑惑！！

很有用

但有些repo比如s3fs只有一个master 分支，那么就必须在个人forked repo修改对吧，那以后再怎么合并回原来的官方repo呢？

和gitlab流程几乎一模一样，差异在pull request那里，gitlab里面叫merge request。不过也差不多。

add commit push太真实了

应该使用git branch -d而不是-D，-d会检查，-D实际是--delete --force

有点标题党的感觉，我以为你讲的是github workflow，结果你讲的是git

nice

请问你在做Git workflow的视频里用到的画图/ppt软件是什么呀？谢谢

我去，我还以为讲github action，看了半天原来是讲git基础，额。。。

5:50 好像应该是git checkout -b master'，而不是main

可以做 git checkout -b my-feature develop 嗎？ 假定已經有 develop 分支，那建立 my-feature 在 develop 上會有什麼樣的疑慮嗎？

想问git rebase 时候用的是 .git 的 main 还是 disk 的 main, 如果是前者, 是否 git fetch origin main && git rebase main 也能达到相同目的， 不需 git pull origin main

我们小团队都在 dev add commit push , master 都被遗忘了 。。。😄

您好 講得真好 我想請問一下 刪掉那些commit只保留一個commit不會一次有太多程式碼修改嗎 這樣要除錯會不會比較不好除錯呢？ 用fork的方式如何呢？

感謝！請問在開發新功能（fearture1)的時候，是在main branch 上開發？還是應該新建一個，是在新建另一個dev feature branch在上面開發，結束之後再merge回main呢？是不是每開發一個新feature 就要有一個對應的feature branch? 如果merge 回main之後，main 又新增了幾個commit

现在 git 切分支可以用 git switch [-c] branch-name 了呢

如果当我已经将本地的分支合并到主分支后，还没来得及pull request，另一个人也合并了他的代码，如果我们同时在修改同一个文件，那不会造成冲突吗？

开发组的人越多约有用，如果就3~5个人，一把梭其实效率最高

after rebase master, I always get diverged feature branch (Xbehind, Ybefore), do you have a good solution for this situation?

大佬，请问在checkout和switch命令之间该如何选择呢

天哥，可不可以讲讲实际使用是如何搭配vscode使用的，我用的时候commit时候，会生成一个文件还需要我自己手动取消注释。您讲这个的应该是命令行的git使用，想看看大家都实际是用的什么工作套件。

我以为要讲github workflow 没想到讲的是workflow

没讲到fork， 我一开始就不知道fork别人项目， 再进行提pr的工作流

请问，如果git rebase master 之后，在merge request之前, master有更新了。 这种情况怎么办？

UP朱，是不是应该改成github 的工作流程，而非工作流？ 工作流的话，几乎都会认为是github action 那一套吧

Danke!

Make simple things complicated. You should have your team members manage commit and pull requests based on their roles and rules.

有一个疑问，假如说master分支上squash&merge之后，变成update2。其他分支也在这个基础之上merge进来了master。但update2这个merge的代码有bug，需要回滚，或者需要bugfix，这个时候应该要怎么要操作

讲的还是比较清晰的

squash学到了，我们公司都是直接merge。。。

git小白聽一半迷路聽完頭暈嗚嗚嗚😅🥴😵‍💫😵

公司和这套流程一摸一样..

请问一个feature branch什么时候应该做一个commit？应该尽量多一些commit来抓住更多改动的细节还是commit越少越好？既然最后都要squash是不是没必要做太多commit？

请问同时进行多版本开发怎么办？每个版本开一个main branch吗？

所以實務上不會使用到git merge嗎？

没必要学，装个tortoise git点界面就行了😊

对于个人开发而言，是不是就没必要用这一套流程？除非我是为了适应未来可能的合作流程？

Local和Disk有什麼區別？

懂的人不用听,不懂的听了也还是不懂🙃

5:25 在local/my-feature 直接git pull origin main， 如果有conflict，resolve conflict，然后commit and push到remote my-feature. create PR, approve后就可以merge去main了。 这个流程更简洁，有什么潜在问题吗？

这是git workflow 不是github

你自己的github push项目，你merge什么

沒有正不正確的，只是看 use-case。

无语

😮太麻煩了

聽的頭好暈

666

你的分支已经push到远端了，就要考虑到有别人check out 的可能，要用merge，不要随便rebase。去看看git 的官网教程对rebase 的描述吧，如果你不懂rebase和merge 的区别，那就用merge。。。。也许会乱，但不会错。