Розмір відео: 1280 X 720853 X 480640 X 360
Показувати елементи керування програвачем
Автоматичне відтворення
Автоповтор
公司真的是這樣 實用推
真棒，我看过逻辑理解最清晰易懂的。
经过我一个多月的操练, 这套流程已经掌握了, 非常丝滑. 之前只会在main上操作. 现在真正感受到了Git的魅力. 另外我还教会了一个人. 哈哈. 感谢高天!
第一次看到把git讲得这么条缕分明, 太赞了,谢谢
如果能再配合一个具体的项目操作就太棒了！非常的感谢，学到了很多！
果然是高级码农，不仅自己逻辑清晰而且表达的这么易懂
讲得不错。能帮到初学git的人，不仅是参加开源项目，还有一些公司也是这个工作流
一般情况下，master都禁止push，必须走合并review流程。
這不就是他說的嗎？squash and merge
@@ca91pdf 他的意思是不能直接push to main/master, 必须要pull request，就是得是master/main pull from the feature branch
@@ca91pdf 项目上最好把master也设定为protect
我們也是鎖master push，其他branch就隨便add push pull，master核准完MR後同時delete掉feature branch就乾淨了
@@s8960935 個人也是比較偏好Gitlab的MR這種用法，雖然Github上都是叫做PR
開一個新的專項來講 giuhub 怎麼使用感覺很棒希望之後還能聽到更多有關 github 方面的概念教學讓更多初次進到 github 領域的工程師能更快上手個人是想聽 github 的流水線（GitHub Actions）這部分的介紹
看標題我也以為是在講 ci 的部份，build image, unit test, lint check, push to docker 之類的😂
@@coladock 看到標題也以為是要講 CI/CD +1
讲得真好，正好是很多视频教程空缺的，正好是我想看的
最簡潔扼要的 GitHub 工作流介紹!!!!!
建議應該補充說明:rebase, rebase -i 使用上應該要小心，而不是 force push 就完事了。開源項目通常會有多人協作，隨隨便便就對已經存在於 Remote 的 Commit 進行上述的操作，會搞到其他協作者。
原则上，不应该有任何两个人同时在一个（可以被push的）branch上工作。
@@minkoder 是的，原則上是這樣不過實務上，不少公司在實際開發的情境還是會打破這個原則。而且你沒辦法保證或說服你的同事遵循這個原則😐
@@v2266514 破坏原则的人会让工作无法继续，代码出现冲突，只能搁置，不是提交的人搞了其他开发人员，是破坏原则的人让搞到项目无法进行，同一个公司的人还好快速沟通，开源分布工作的项目估计就卡死，或者严重拖延！
@@v2266514这种特例太多了，不应该在十分钟的短视频里讲。
@@v2266514 如果连这个都不遵守，其实也没有必要遵守这套工作流
exactly 就是工业界的git流程 ，简洁明了。
视频讲解的比较清晰，但是这个流程可能更适合于个人项目，或者参与人数比较少的情况。比较活跃和贡献者比较多的项目，有两个问题需要注意：1）Github 上首先还是 fork，这样无论怎么修改怎么 Push 都不会影响到其他人的进程；2）强烈不建议 git push -f，个人项目很难撤销，多人项目如果 maintainer 想要撤销容易引起连锁反应
Git push force 是僅限於自己在工作的 branch 吧？這樣不應該影響到其他人
请问fork repo上的修改怎么提交到原来的官方repo呢？
@@gz6x 发一个 merge request
感谢，如果不用force, 可以使用其他的什么做法代替呢？
@@wzhings 协作的项目，fork之后在自己的代码库里修改、提交，测试完成之后发 pull request，等maintainer review/merge
讲的真的好清晰易懂，感谢
下次講講 為何rebase is better than merge？ 還有cherry pick? 謝謝
很有帮助，感谢分享🥰
跟我们公司的不是完全一样，不同的点主要在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上做，然后再同步到本地
多謝生動的講解，受益非常多。大神，下次能不能講解一下cherry Pick? 先謝謝了！
但依然看不明白為何不使用merge而是使用rebase + delete feature，使用merge在source tree 會直接顯示feature與main branch 合拼吧？
圖文並茂，講解的很清楚，很好！🙂
讲解的很好，天天都用，但没这么清晰。
正是我目前的操作流，nice！
很有用的知识，对学习很有帮助😄
前面給讚，後面直接介紹rebase我就默默收回讚，問了gpt rebase適合個人、merge適合團隊(關於是否簡化異動軌跡)
我看過最棒的，以後對自己項目都這樣做好了
多人合作一般推薦使用 merge 而不是 rebase，因為 rebase 會改變 git history 而 merge 不會
你在feature branch上的任何history都不会被最终保留。理论上你的feature branch也不应该有多人合作。
视频讲的很好, 不过最好再讲一下 post-pull operations (假如还要在 my-feature 继续开发的话). 否则 my-feature 和 main 版本不一致, 后续可能会有问题.```shgit checkout my-featuregit pull origin main --rebase```假如这个branch不用了, 删掉就行; 或者用从main开新的branch
老師講得很好，只是我的建議是 disk 的 branch 不要刪除，算是留一個備份
太感谢了，终于知道怎么用
這是我看過最簡單清楚的說明了👍 但說真的我還是覺得github flow把事情搞的太複雜😂
大佬，期待你出静态语言讲解呀！你讲得真的很好！
講解的非常清楚 👍
BEST EXPLANATION OF ALL TIME!!
说的太好了，别的教程都讲什么add push 也没讲冲突怎么解决 没讲怎么使用
之前我一直納悶pro都是怎麽做的，這個好！
不错，讲的很清晰。
會建議考慮trunk based development多於festure branch
谢谢大佬带路，很有帮助
讲的真好！
严谨又高效 不过最好解释一下参数的功能 比如-f会不会有什么危害
但有些repo比如s3fs只有一个master 分支，那么就必须在个人forked repo修改对吧，那以后再怎么合并回原来的官方repo呢？
清楚！感謝
太清晰了，感谢
这个幻灯片是用什么做的呢？
请问你在做Git workflow的视频里用到的画图/ppt软件是什么呀？谢谢
Github的話要先fork？
还以为我看错了，，，10 天前视频，我在 阿b 好早之前看的了😂
应该使用git branch -d而不是-D，-d会检查，-D实际是--delete --force
So clear! Thanks 🎉
想问git rebase 时候用的是 .git 的 main 还是 disk 的 main, 如果是前者, 是否 git fetch origin main && git rebase main 也能达到相同目的， 不需 git pull origin main
和gitlab流程几乎一模一样，差异在pull request那里，gitlab里面叫merge request。不过也差不多。
可以做 git checkout -b my-feature develop 嗎？假定已經有 develop 分支，那建立 my-feature 在 develop 上會有什麼樣的疑慮嗎？
现在 git 切分支可以用 git switch [-c] branch-name 了呢
先订阅以后慢慢看
after rebase master, I always get diverged feature branch (Xbehind, Ybefore), do you have a good solution for this situation?
add commit push太真实了
讲的不错。
終於懂了 感謝
请问，如果git rebase master 之后，在merge request之前, master有更新了。 这种情况怎么办？
漂亮!
有点标题党的感觉，我以为你讲的是github workflow，结果你讲的是git
如果当我已经将本地的分支合并到主分支后，还没来得及pull request，另一个人也合并了他的代码，如果我们同时在修改同一个文件，那不会造成冲突吗？
您好 講得真好 我想請問一下 刪掉那些commit只保留一個commit不會一次有太多程式碼修改嗎這樣要除錯會不會比較不好除錯呢？用fork的方式如何呢？
每个feature squash成一个commit是未来读起来更好读的。如果一次改了太多程序可能说明这个feature不应该一个PR完成。是不是fork和这个事情无关，只是决定了feature branch是在原repo完成还是fork的repo完成。
大佬，请问在checkout和switch命令之间该如何选择呢
感謝
5:51 应该是 `git pull origin main` 吧， 之前用的都是 `main`
你是对的。
必须赞
UP朱，是不是应该改成github 的工作流程，而非工作流？ 工作流的话，几乎都会认为是github action 那一套吧
来源于 Github Workflow 这个单词，一般也不会认为是 Github Actions
天哥，可不可以讲讲实际使用是如何搭配vscode使用的，我用的时候commit时候，会生成一个文件还需要我自己手动取消注释。您讲这个的应该是命令行的git使用，想看看大家都实际是用的什么工作套件。
VSCode 的 git 源代码管理插件是一样的，只是图形化运行 git 命令。不是很懂“会生成一个文件还需要我自己手动取消注释”是什么意思，能具体说说吗？
下commit時出現的文件叫commit message，是用來描述你這個commit做了/修改了什麼。
你直接git commit -m " " 在雙引號之間寫入就好commit資訊就好
解决了我的疑惑！！
有一个疑问，假如说master分支上squash&merge之后，变成update2。其他分支也在这个基础之上merge进来了master。但update2这个merge的代码有bug，需要回滚，或者需要bugfix，这个时候应该要怎么要操作
revert本身是可能出现conflict的，需要手动处理，这个是很正常的事情。但是如果相对大家开发的内容比较独立，即使你的commit之后有很多commits，在revert的时候依然可能是clean的。单独开个PR做revert就好。另外明天会有个视频讲撤销。
我们一般不滚回（gitflow），如果不是紧急的bug就建一个feature 分支，修改后并入develop分支，如果是紧急的bug就建立一个hotfix的分支，直接在main上修改
5:50 好像应该是git checkout -b master'，而不是main
所以實務上不會使用到git merge嗎？
看团队的喜好。CPython团队就希望feature branch在update到main的时候用merge，因为对code review更友好。
@@minkoder 确实如此。我们组和其他隔壁组合作的时候大家都是用merge
這一串看不太懂，為什麼merge會對code review友好呢😢
@@hsiehmin787 我也喜欢merge, 不喜欢rebase. rebase 会打乱原来的顺序. 假设你针对当前的代码添加了新功能还没提交, 但是同事提交了一个破坏更新. 你用rebase把同事的代码放到前面, 自己的放的后面, 最初的提交记录就丢失了.而你用merge会保留所有操作的时间线.
我们小团队都在 dev add commit push , master 都被遗忘了 。。。😄
没讲到fork， 我一开始就不知道fork别人项目， 再进行提pr的工作流
哈哈，我也犯过这个错误
开发组的人越多约有用，如果就3~5个人，一把梭其实效率最高
當有bug或是人員開始流動時就是痛苦的開始了
项目里多于3个人的时候处理conflict就会有想死的感觉，上午一次，下午一次，一天少做一次第二天都能死
很有用
请问同时进行多版本开发怎么办？每个版本开一个main branch吗？
这种情况相对少一些。但是确实会出现多主branch开发的，一般就不叫main了，每个主力branch都有个自己的名字。
感謝！請問在開發新功能（fearture1)的時候，是在main branch 上開發？還是應該新建一個，是在新建另一個dev feature branch在上面開發，結束之後再merge回main呢？是不是每開發一個新feature 就要有一個對應的feature branch?如果merge 回main之後，main 又新增了幾個commit
永远不在main上做任何开发。main上的每一个commit，都应该是feature branch PR过来的（当然是理论上，我自己的个人项目很偶尔也会违背这个原则，但是尽量）。feature merge回main之后，这个feature就完成了。修改这个feature是一个新的feature（这里要看你怎么理解feature这个词，更合适的词可能是task）。这时候从main再branch出来，再做修改。每个feature branch只是保证要做一个完整的commit到main上。
@@minkoder 感謝您
Local和Disk有什麼區別？
Disk就是你的物理磁盘，你的工作目录，你实际编辑代码的地方，保存着你当前所在分支的文件以及用于版本控制的文件。Local则是git的一个功能，即本地仓库的元数据，保存本地仓库的描述信息，比如做了什么修改，当前位于哪一个分支等等信息。Local本质是一些包含上述信息的文件，实际上也保存在你的硬盘上，比如.git文件夹下面。你可以看看add、commit命令前后.git目录下面的文件内容变化。
Disk的東西要先commit到Local，在Local處確定這些commit的東西都是正確的，才push到Remote。你可以想像Local就是你的對外窗口，負責和Remote端的人接洽。至於你的內部(Disk和Local)要怎麼亂怎麼糟，那是你自己去處理，Remote端的人不管。Remote真正關心的是Local交給他的東西。
我這邊 遇到的一般是 用 merge 而不是 rebase，盡可能保留歷史... force 是危險的操作... 公式一個 repo 會有 7～8 人同時維護
我以为要讲github workflow 没想到讲的是workflow
5:25 在local/my-feature 直接git pull origin main， 如果有conflict，resolve conflict，然后commit and push到remote my-feature. create PR, approve后就可以merge去main了。 这个流程更简洁，有什么潜在问题吗？
没问题，merge和rebase都是可选的feature branch方案。只要你意识到你在git pull origin main的时候实际上是做了两个操作，fetch到了local main，同时merge到了current branch就行。因为有的时候你只需要git merge main（如果你的local main已经是最新的）。
但是一般来说 有commit记录 是不会mess up 的 毕竟只要 reset head到前一个就好了。 anyway 其实是一样的哈哈
@@minkoder 我是新人，我就是直接在local/my-feature上git pull origin main，然后就是经常有冲突了，老提示merge --no-ff 这跟普通的merge有什么不同；要是再出一期视频讲讲merge的流程以及常见的冲突情况就好了
@@binz735 推一個，我也想知道常見衝突
对于个人开发而言，是不是就没必要用这一套流程？除非我是为了适应未来可能的合作流程？
另外，还想问一下，对于审查能不能merge到main的情况，审查者的流程是什么呢？他为了审查代码，总得把要审查的部分在自己的本地check out吧？所以实际上他要在本地pull下来my-feature的分支，然后测试？那如果他要修改合并其他的东西呢？建立一个临时的测试分支吗？
哪怕是纯个人项目，也推荐走这个流程，最主要的原因是可以让你的commit history比较干净，bisect问题的时候更方便，尽可能保证每个commit都work。大部分的merge是不需要check out这个branch的，因为有CI的帮助，可以在github action之类的地方跑测试。只需要看新的代码写的怎么样，测试覆盖如何，就行了。一般来说，code review只会提出意见，不会去改别人的branch。
请问一个feature branch什么时候应该做一个commit？应该尽量多一些commit来抓住更多改动的细节还是commit越少越好？既然最后都要squash是不是没必要做太多commit？
做多少commit主要影响的是code review和你自己的history track。它不影响合并之后的事情。
我的理解是，写了一些东西以后，到某一个时间点你会想要跑一下代码看看，初步测试一下这些修改。这个时间点上如果这些初步的测试能通过，那就是一个比较好的commit时间点了。commit不应该太少的原因不只是为了方便其他想要查看开发进度的人理解，也是一种帮助自己整理开发过程思路的手段。如果你的很多东西都堆在一个commit里分不开，那一定程度上说明你的思路也比较混乱，并不能清晰地描述开发过程中的每一个小进展。学会如何把握commit大小本身就是对提高项目规划能力的一种考验。供参考。
nice
squash学到了，我们公司都是直接merge。。。
Make simple things complicated. You should have your team members manage commit and pull requests based on their roles and rules.
git小白聽一半迷路聽完頭暈嗚嗚嗚😅🥴😵💫😵
不是所有项目pr后都会squash
讲的还是比较清晰的
你自己的github push项目，你merge什么
没必要学，装个tortoise git点界面就行了😊
聽君一席話，勝讀十年書
我去，我还以为讲github action，看了半天原来是讲git基础，额。。。
真的...
你省了我十分鐘 感謝
基础也需要学习
太感谢了
都说了是工作流了
懂的人不用听,不懂的听了也还是不懂🙃
公司和这套流程一摸一样..
这是git workflow 不是github
公司真的是這樣 實用推
真棒，我看过逻辑理解最清晰易懂的。
经过我一个多月的操练, 这套流程已经掌握了, 非常丝滑. 之前只会在main上操作. 现在真正感受到了Git的魅力. 另外我还教会了一个人. 哈哈. 感谢高天!
第一次看到把git讲得这么条缕分明, 太赞了,谢谢
如果能再配合一个具体的项目操作就太棒了！非常的感谢，学到了很多！
果然是高级码农，不仅自己逻辑清晰而且表达的这么易懂
讲得不错。能帮到初学git的人，不仅是参加开源项目，还有一些公司也是这个工作流
一般情况下，master都禁止push，必须走合并review流程。
這不就是他說的嗎？squash and merge
@@ca91pdf 他的意思是不能直接push to main/master, 必须要pull request，就是得是master/main pull from the feature branch
@@ca91pdf 项目上最好把master也设定为protect
我們也是鎖master push，其他branch就隨便add push pull，master核准完MR後同時delete掉feature branch就乾淨了
@@s8960935 個人也是比較偏好Gitlab的MR這種用法，雖然Github上都是叫做PR
開一個新的專項來講 giuhub 怎麼使用感覺很棒
希望之後還能聽到更多有關 github 方面的概念教學
讓更多初次進到 github 領域的工程師能更快上手
個人是想聽 github 的流水線（GitHub Actions）這部分的介紹
看標題我也以為是在講 ci 的部份，build image, unit test, lint check, push to docker 之類的😂
@@coladock 看到標題也以為是要講 CI/CD +1
讲得真好，正好是很多视频教程空缺的，正好是我想看的
最簡潔扼要的 GitHub 工作流介紹!!!!!
建議應該補充說明:
rebase, rebase -i 使用上應該要小心，而不是 force push 就完事了。
開源項目通常會有多人協作，隨隨便便就對已經存在於 Remote 的 Commit 進行上述的操作，會搞到其他協作者。
原则上，不应该有任何两个人同时在一个（可以被push的）branch上工作。
@@minkoder 是的，原則上是這樣
不過實務上，不少公司在實際開發的情境
還是會打破這個原則。
而且你沒辦法保證或說服你的同事遵循這個原則😐
@@v2266514 破坏原则的人会让工作无法继续，代码出现冲突，只能搁置，
不是提交的人搞了其他开发人员，
是破坏原则的人让搞到项目无法进行，
同一个公司的人还好快速沟通，
开源分布工作的项目估计就卡死，或者严重拖延！
@@v2266514这种特例太多了，不应该在十分钟的短视频里讲。
@@v2266514 如果连这个都不遵守，其实也没有必要遵守这套工作流
exactly 就是工业界的git流程 ，简洁明了。
视频讲解的比较清晰，但是这个流程可能更适合于个人项目，或者参与人数比较少的情况。比较活跃和贡献者比较多的项目，有两个问题需要注意：1）Github 上首先还是 fork，这样无论怎么修改怎么 Push 都不会影响到其他人的进程；2）强烈不建议 git push -f，个人项目很难撤销，多人项目如果 maintainer 想要撤销容易引起连锁反应
Git push force 是僅限於自己在工作的 branch 吧？這樣不應該影響到其他人
请问fork repo上的修改怎么提交到原来的官方repo呢？
@@gz6x 发一个 merge request
感谢，如果不用force, 可以使用其他的什么做法代替呢？
@@wzhings 协作的项目，fork之后在自己的代码库里修改、提交，测试完成之后发 pull request，等maintainer review/merge
讲的真的好清晰易懂，感谢
下次講講 為何rebase is better than merge？ 還有cherry pick? 謝謝
很有帮助，感谢分享🥰
跟我们公司的不是完全一样，不同的点主要在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上做，然后再同步到本地
多謝生動的講解，受益非常多。
大神，下次能不能講解一下cherry Pick? 先謝謝了！
但依然看不明白為何不使用merge而是使用rebase + delete feature，使用merge在source tree 會直接顯示feature與main branch 合拼吧？
圖文並茂，講解的很清楚，很好！🙂
讲解的很好，天天都用，但没这么清晰。
正是我目前的操作流，nice！
很有用的知识，对学习很有帮助😄
前面給讚，後面直接介紹rebase我就默默收回讚，問了gpt rebase適合個人、merge適合團隊(關於是否簡化異動軌跡)
我看過最棒的，以後對自己項目都這樣做好了
多人合作一般推薦使用 merge 而不是 rebase，因為 rebase 會改變 git history 而 merge 不會
你在feature branch上的任何history都不会被最终保留。理论上你的feature branch也不应该有多人合作。
视频讲的很好, 不过最好再讲一下 post-pull operations (假如还要在 my-feature 继续开发的话). 否则 my-feature 和 main 版本不一致, 后续可能会有问题.
```sh
git checkout my-feature
git pull origin main --rebase
```
假如这个branch不用了, 删掉就行; 或者用从main开新的branch
老師講得很好，只是我的建議是 disk 的 branch 不要刪除，算是留一個備份
太感谢了，终于知道怎么用
這是我看過最簡單清楚的說明了👍 但說真的我還是覺得github flow把事情搞的太複雜😂
大佬，期待你出静态语言讲解呀！你讲得真的很好！
講解的非常清楚 👍
BEST EXPLANATION OF ALL TIME!!
说的太好了，别的教程都讲什么add push 也没讲冲突怎么解决 没讲怎么使用
之前我一直納悶pro都是怎麽做的，這個好！
不错，讲的很清晰。
會建議考慮trunk based development多於festure branch
谢谢大佬带路，很有帮助
讲的真好！
严谨又高效 不过最好解释一下参数的功能 比如-f会不会有什么危害
但有些repo比如s3fs只有一个master 分支，那么就必须在个人forked repo修改对吧，那以后再怎么合并回原来的官方repo呢？
清楚！感謝
太清晰了，感谢
这个幻灯片是用什么做的呢？
请问你在做Git workflow的视频里用到的画图/ppt软件是什么呀？谢谢
Github的話要先fork？
还以为我看错了，，，10 天前视频，我在 阿b 好早之前看的了😂
应该使用git branch -d而不是-D，-d会检查，-D实际是--delete --force
So clear! Thanks 🎉
想问git rebase 时候用的是 .git 的 main 还是 disk 的 main, 如果是前者, 是否 git fetch origin main && git rebase main 也能达到相同目的， 不需 git pull origin main
和gitlab流程几乎一模一样，差异在pull request那里，gitlab里面叫merge request。不过也差不多。
可以做 git checkout -b my-feature develop 嗎？
假定已經有 develop 分支，那建立 my-feature 在 develop 上會有什麼樣的疑慮嗎？
现在 git 切分支可以用 git switch [-c] branch-name 了呢
先订阅以后慢慢看
after rebase master, I always get diverged feature branch (Xbehind, Ybefore), do you have a good solution for this situation?
add commit push太真实了
讲的不错。
終於懂了 感謝
请问，如果git rebase master 之后，在merge request之前, master有更新了。 这种情况怎么办？
漂亮!
有点标题党的感觉，我以为你讲的是github workflow，结果你讲的是git
如果当我已经将本地的分支合并到主分支后，还没来得及pull request，另一个人也合并了他的代码，如果我们同时在修改同一个文件，那不会造成冲突吗？
您好 講得真好 我想請問一下 刪掉那些commit只保留一個commit不會一次有太多程式碼修改嗎
這樣要除錯會不會比較不好除錯呢？
用fork的方式如何呢？
每个feature squash成一个commit是未来读起来更好读的。如果一次改了太多程序可能说明这个feature不应该一个PR完成。是不是fork和这个事情无关，只是决定了feature branch是在原repo完成还是fork的repo完成。
大佬，请问在checkout和switch命令之间该如何选择呢
感謝
5:51 应该是 `git pull origin main` 吧， 之前用的都是 `main`
你是对的。
必须赞
UP朱，是不是应该改成github 的工作流程，而非工作流？ 工作流的话，几乎都会认为是github action 那一套吧
来源于 Github Workflow 这个单词，一般也不会认为是 Github Actions
天哥，可不可以讲讲实际使用是如何搭配vscode使用的，我用的时候commit时候，会生成一个文件还需要我自己手动取消注释。您讲这个的应该是命令行的git使用，想看看大家都实际是用的什么工作套件。
VSCode 的 git 源代码管理插件是一样的，只是图形化运行 git 命令。不是很懂“会生成一个文件还需要我自己手动取消注释”是什么意思，能具体说说吗？
下commit時出現的文件叫commit message，是用來描述你這個commit做了/修改了什麼。
你直接git commit -m " " 在雙引號之間寫入就好commit資訊就好
解决了我的疑惑！！
有一个疑问，假如说master分支上squash&merge之后，变成update2。其他分支也在这个基础之上merge进来了master。但update2这个merge的代码有bug，需要回滚，或者需要bugfix，这个时候应该要怎么要操作
revert本身是可能出现conflict的，需要手动处理，这个是很正常的事情。但是如果相对大家开发的内容比较独立，即使你的commit之后有很多commits，在revert的时候依然可能是clean的。单独开个PR做revert就好。另外明天会有个视频讲撤销。
我们一般不滚回（gitflow），如果不是紧急的bug就建一个feature 分支，修改后并入develop分支，如果是紧急的bug就建立一个hotfix的分支，直接在main上修改
5:50 好像应该是git checkout -b master'，而不是main
所以實務上不會使用到git merge嗎？
看团队的喜好。CPython团队就希望feature branch在update到main的时候用merge，因为对code review更友好。
@@minkoder 确实如此。我们组和其他隔壁组合作的时候大家都是用merge
這一串看不太懂，為什麼merge會對code review友好呢😢
@@hsiehmin787 我也喜欢merge, 不喜欢rebase. rebase 会打乱原来的顺序. 假设你针对当前的代码添加了新功能还没提交, 但是同事提交了一个破坏更新. 你用rebase把同事的代码放到前面, 自己的放的后面, 最初的提交记录就丢失了.而你用merge会保留所有操作的时间线.
我们小团队都在 dev add commit push , master 都被遗忘了 。。。😄
没讲到fork， 我一开始就不知道fork别人项目， 再进行提pr的工作流
哈哈，我也犯过这个错误
开发组的人越多约有用，如果就3~5个人，一把梭其实效率最高
當有bug或是人員開始流動時就是痛苦的開始了
项目里多于3个人的时候处理conflict就会有想死的感觉，上午一次，下午一次，一天少做一次第二天都能死
很有用
请问同时进行多版本开发怎么办？每个版本开一个main branch吗？
这种情况相对少一些。但是确实会出现多主branch开发的，一般就不叫main了，每个主力branch都有个自己的名字。
感謝！請問在開發新功能（fearture1)的時候，是在main branch 上開發？還是應該新建一個，是在新建另一個dev feature branch在上面開發，結束之後再merge回main呢？是不是每開發一個新feature 就要有一個對應的feature branch?
如果merge 回main之後，main 又新增了幾個commit
永远不在main上做任何开发。main上的每一个commit，都应该是feature branch PR过来的（当然是理论上，我自己的个人项目很偶尔也会违背这个原则，但是尽量）。feature merge回main之后，这个feature就完成了。修改这个feature是一个新的feature（这里要看你怎么理解feature这个词，更合适的词可能是task）。这时候从main再branch出来，再做修改。每个feature branch只是保证要做一个完整的commit到main上。
@@minkoder 感謝您
Local和Disk有什麼區別？
Disk就是你的物理磁盘，你的工作目录，你实际编辑代码的地方，保存着你当前所在分支的文件以及用于版本控制的文件。Local则是git的一个功能，即本地仓库的元数据，保存本地仓库的描述信息，比如做了什么修改，当前位于哪一个分支等等信息。Local本质是一些包含上述信息的文件，实际上也保存在你的硬盘上，比如.git文件夹下面。你可以看看add、commit命令前后.git目录下面的文件内容变化。
Disk的東西要先commit到Local，在Local處確定這些commit的東西都是正確的，才push到Remote。
你可以想像Local就是你的對外窗口，負責和Remote端的人接洽。至於你的內部(Disk和Local)要怎麼亂怎麼糟，那是你自己去處理，Remote端的人不管。Remote真正關心的是Local交給他的東西。
我這邊 遇到的一般是 用 merge 而不是 rebase，盡可能保留歷史... force 是危險的操作... 公式一個 repo 會有 7～8 人同時維護
我以为要讲github workflow 没想到讲的是workflow
5:25 在local/my-feature 直接git pull origin main， 如果有conflict，resolve conflict，然后commit and push到remote my-feature. create PR, approve后就可以merge去main了。 这个流程更简洁，有什么潜在问题吗？
没问题，merge和rebase都是可选的feature branch方案。只要你意识到你在git pull origin main的时候实际上是做了两个操作，fetch到了local main，同时merge到了current branch就行。因为有的时候你只需要git merge main（如果你的local main已经是最新的）。
但是一般来说 有commit记录 是不会mess up 的 毕竟只要 reset head到前一个就好了。 anyway 其实是一样的哈哈
@@minkoder 我是新人，我就是直接在local/my-feature上git pull origin main，然后就是经常有冲突了，老提示merge --no-ff 这跟普通的merge有什么不同；要是再出一期视频讲讲merge的流程以及常见的冲突情况就好了
@@binz735 推一個，我也想知道常見衝突
对于个人开发而言，是不是就没必要用这一套流程？除非我是为了适应未来可能的合作流程？
另外，还想问一下，对于审查能不能merge到main的情况，审查者的流程是什么呢？他为了审查代码，总得把要审查的部分在自己的本地check out吧？所以实际上他要在本地pull下来my-feature的分支，然后测试？那如果他要修改合并其他的东西呢？建立一个临时的测试分支吗？
哪怕是纯个人项目，也推荐走这个流程，最主要的原因是可以让你的commit history比较干净，bisect问题的时候更方便，尽可能保证每个commit都work。大部分的merge是不需要check out这个branch的，因为有CI的帮助，可以在github action之类的地方跑测试。只需要看新的代码写的怎么样，测试覆盖如何，就行了。一般来说，code review只会提出意见，不会去改别人的branch。
请问一个feature branch什么时候应该做一个commit？应该尽量多一些commit来抓住更多改动的细节还是commit越少越好？既然最后都要squash是不是没必要做太多commit？
做多少commit主要影响的是code review和你自己的history track。它不影响合并之后的事情。
我的理解是，写了一些东西以后，到某一个时间点你会想要跑一下代码看看，初步测试一下这些修改。这个时间点上如果这些初步的测试能通过，那就是一个比较好的commit时间点了。commit不应该太少的原因不只是为了方便其他想要查看开发进度的人理解，也是一种帮助自己整理开发过程思路的手段。如果你的很多东西都堆在一个commit里分不开，那一定程度上说明你的思路也比较混乱，并不能清晰地描述开发过程中的每一个小进展。学会如何把握commit大小本身就是对提高项目规划能力的一种考验。供参考。
nice
squash学到了，我们公司都是直接merge。。。
Make simple things complicated. You should have your team members manage commit and pull requests based on their roles and rules.
git小白聽一半迷路聽完頭暈嗚嗚嗚😅🥴😵💫😵
不是所有项目pr后都会squash
讲的还是比较清晰的
你自己的github push项目，你merge什么
没必要学，装个tortoise git点界面就行了😊
聽君一席話，勝讀十年書
我去，我还以为讲github action，看了半天原来是讲git基础，额。。。
真的...
你省了我十分鐘 感謝
基础也需要学习
太感谢了
都说了是工作流了
懂的人不用听,不懂的听了也还是不懂🙃
公司和这套流程一摸一样..
这是git workflow 不是github