Tóm tắt toàn diện về việc sử dụng Git và quy trình làm việc của GitFlow và sếp yêu cầu tôi phải học
ฝัง
- เผยแพร่เมื่อ 30 ก.ค. 2024
- Tóm tắt toàn diện về việc sử dụng Git và quy trình làm việc của GitFlow và sếp yêu cầu tôi phải học
👉 Link khóa học backend Nodejs: / @anonystick
Timeline:
00:00 Giới thiệu nguồn gốc của Git Flow của tác giả Vincent Driessen đề xuất
09:00 Cách triển khai git flow thông qua thực tế ở công ty như thế nào với leader, coder.
Tools git recomment: Fig
#git #github #gittutorial
🚩 Subscribe ➜ / tipsjavascript
✅ Follow Me:
Blog: anonystick.com
Github: github.com/anonystick/anonystick
Facebook: / tipjs
TH-cam: / tipsjavascript
![บุษบา - เมนทอล [Official MV]](http://i.ytimg.com/vi/IGnWPokSEis/mqdefault.jpg)
Các bạn cứ tận hưởng lúc kênh ít người biết đến đi, anh chủ kênh còn tương tác được từng người một. Sau này khi kênh phát triển mạnh, “comment” của anh em sẽ lọt thỏm trong số hàng trăm còm ;)
Ha ha. Để anh capture lại comment này. Sau này còn nhớ.
@@anonystick haha chúc mừng a
Qua tất cả những tut trên TH-cam về Git mà em đã học. Có cả những kênh phổ biến tiếng Việt với hàng trăm ngàn lượt xem. Xem cả nội dung tiếng Anh cả triệu view. NHƯNG đây là video đầy đủ chi tiết tận tậm, tận tụy, tận tình, hết lòng, hết dạ nhất về cái nội dung Git này.
Và đây là video đặc biệt nhất dành cho những bạn nào tự học với vai trò là newbie rất rất rất đáng xem. Thật sự rất chất lượng. Mong là kênh thầy ngày càng phát triển hơn nữa.
Cảm ơn BlackBold. Một comment đầy động lực. Quyết thắng!
Em nghĩ nếu thầy nghiên cứu về từ khóa phổ biến trong tìm kiếm để đặt tiêu thì sẽ nhiều người biết đến hơn nữa. Vì bài Fetch-Async-Await cũng chất lượng cao vô cùng.
Cám ơn anh nhiều ạ, thông tin thực tế hữu ích cho những bạn chưa đi làm ở cty như em ạ.
cảm ơn a rất nhiều về những chia sẻ từ kinh nghiệm thực tế, video đã giúp e hình dung cụ thể hơn về quá trình làm việc và thao tác với git, chúc a nhiều sức khỏe
Cảm ơn anh nhiều, kiến thức quá bổ ích luôn!
mong a ra những vd chi tiết như này, 1 tim cho chủ kênh
Cảm ơn chú. Trong 35 phút đã giúp con từ không biết gì đến sử dụng được Git :D
Cái quan trọng khi làm việc với git trong 1 team là sẽ có nhiều nhánh features chạy song song, có thể là nhiều team cùng làm 1 repo hoặc nhiều thành viên làm các feature khác nhau, bạn nên nói thêm phần merge conflict, tức là trước khi commit code, cần rebase nhánh chính để xem có ai đó hoặc có PR nào đó đã được merge sau khi bạn checkout ra nhánh feature ko, resolve conflict trước khi commit code và tạo PR. Cái này có lẽ là quan trọng nhất khi làm team, nếu ko thì suốt ngày bạn phải đi giải quyết conflict trên PR.
Ý của bạn cũng là điều kiện tiên quyết để làm team làm việc chung trong 1 repo.
Nhưng mình thấy những bạn mới làm thì chỉ biết push code lên thay vì trước khi push thì phải pull mới nhất về merge lại đã.
Pull về rồi mới đẩy lên sẽ rất khó bị conflict
@@nguyenngocle6542 làm gì có chuyện rất khó :D , code mới nhất ở trên main, mà main thì sẽ là kết quả merge của hotfix, hoặc release, lúc bạn đang code thì nó merge vào rồi thì sao, nên kịch bản của chủ kênh đưa ra rất đẹp, nhưng rất tiếc khi làm project với git, cái khó nhất là fix conflict, và tính toán để merge branch , vì sẽ có rất nhiều branch feature, hotfix được break ra, và ko phải là sẽ được hoàn thành ngay
thường thì mấy vụ thêm tag, version, assign, break task sẽ do leader có kinh nghiệm làm, còn developer, sẽ chỉ cần pull nhánh dev về checkout tạo feature ( hoặc leader break luôn dev chỉ việc fetch về code rồi push lên), thì sẽ tốt hơn
nhiều project , nhiều khi bug tùm lùm dính tới nhiều file, lúc push feature lên fix conflict mệt còn hơn code
@@reoteuray9823 ồ cảm ơn bác khai sáng, đó giờ làm dev chứ chưa làm leader chưa thấy cảnh này, nhưng mà dự án bên t làm tự break ra rồi tạo PR r đẩy lên chỉ bị khi quên pull hoặc mình đẩy lên thì có ng vừa merge vào thôi. Fix thì cũng thấy không khó lắm ấy chắc chưa gặp trường hợp hóc búa
@@huyangquang3895 pull về trc rồi mới push hay push trc thấy conflict rồi mới pull thì cũng chả khác gì nhau, vì cơ bản lúc bạn push mà bị conflict thì nó ko cho phép bạn push rồi, thì cũng giống như việc bạn pull về trc gặp conflict rồi mới push lên cũng vậy, cơ bản nó chỉ thay đổi thứ tự công việc bạn làm, nên nhớ, git chỉ cho phép push khi ko có conflict, vậy nên 2 việc bạn nói push trc hay pull trước là giống nhau, đã là conflict thì nó sẽ conflict, ko conflict thì push dc, thế thôi
Cảm ơn anh nhiều vì nội dung hữu ích ạ
Cảm ơn anh vì những kiến thức thực tế.
E chào a. E mới theo dõi kênh của a thấy những kiến thức a chia sẻ rất hay và hữu ích. E chúc a luôn mạnh khỏe và thành công hơn nữa :))
Cảm ơn anh nhiều. Thực sự yêu thích những nội dung thực tế của anh. Chúc anh nhiều sức khoẻ!
Cảm ơn em
Cảm ơn anh video quá hay ạ
Video rất hữu ích, cảm ơn anh rất nhiều ạ❤❤
đúng thứ em cần luôn cảm anh nhiều
Thanks anh, rất dễ hiểu :3
xem nhiều video của anh rất hay ko chỉ chuẩn về học thuật mà anh dùng cách diễn đạt rất hay sát với thực tế, chúc anh sức khỏe và thành công trong cuộc sống và công việc ạ
Cảm ơn Kay Pham! Quyết thắng!
Cảm ơn a rất nhiều ạ
Rất bổ ích ạ
E làm dự án outsource có một yêu cầu như thế này:
Có 2 branch develop và master tương ứng với 2 môi trường server. E có 2 module cần triển khai như thế này theo sơ đồ trong video:
Module A -> branch A -> Làm xong merge branch develop -> Tạo nhánh release A nhưng k tạo tag release.
Sau khi làm xong module A thì tới module B:
Module B -> branch B từ develop -> Làm xong merge branch develop -> Tạo nhánh release B.
Bây giờ tạo tag release thì KH thay đổi chỉ yêu cầu release module B chứ k có module A. Nếu theo sơ đồ của e vẽ thì khi tách branch B đã có commit của branch A. Vậy thì tách branch từ develop hay master thì sẽ tối ưu hơn v a.
Cảm ơn a nhiều!
Quý anh vô cùng. Rất bổ ích cho các bạn mới
Cảm ơn em!
Hay quá anh ơi 💯
Cảm ơn sư phụ đã chia sẽ :))
hi . 1 video rất hữu ích cho fresher . cảm ơn anh
Cam on ban!
rất chi tiết và dễ hiểu , anh làm video setup cái teminal giống anh đc ko anh
Đúng cái em cần
Cảm ơn ad!
đúng thế anh ạ, nhiều thằng làm láo nha láo nháo xong nói thì tự ái.
Anh ơi, a có thể làm video socket gửi thông báo cho số lượng người dùng lớn được không ạ, e cảm ơn a !
anh có thể chia sẽ rõ , đoạn nào thì dev làm , đoạn nào thì leader làm được không ạ
Em là trái ngành, newbie 100% ko biết gì
Nhờ các blog của anh mà em hiểu rõ hơn thao tác trong Array Methods, rồi covert Object Array...v.v...
Chúc Anh nhiều sức khỏe và thường xuyên viết blog, cá nhân em thích đọc docs hơn xem video :D
tôi cũng trái ngành, vừa chuyển qua học được vài tháng. có blog hay video nào cần thiết cho newbie ko ông cho tui xin với
Anh làm video về rabbitMQ khi thanh toán đi ạ
8:20 m nghĩ cái này b nói sai: hotfix branch để sửa bug trên production, và làm trực tiếp trên hotfix chứ không đẩy về develop để fix. Sau khi fix xong thì sẽ merge cả vào develop và master
cty em sử dụng gitlab, luồng giống như trên nhưng bỏ qua đi phần sếp tạo issues và cũng k có nhánh release thay vào đó là đẩy từ develop vào main luôn =))
Anh ơi, em thấy trên nhánh release-v1.1.0 và cả hotfixes phía sau mình đều có thêm commit tuy nhiên lại chỉ merge về main mà không merge về nhánh dev để cập nhật thay đổi hả anh?
Ở hình git flow, tại sao ở chỗ relase 1.0 mình lại có 1 commit rồi mới switch sang dev để tiếp tục làm, trong khi ở commit relase 2.0 lại k có thêm một commit vậy anh?
Hey bro ! I am a movie maker. But in these recent days I beca a sick fan of Alan Walker. I researched 'bout Nice tutorialm and got to know that
a dùng gì mà có gợi ý lệnh trong terminal vậy anh
Cho em hỏi việc viết commit như vậy liệu có áp dụng được với commitlint không ạ?
xin cách set terminal của a có suggest như kia với ạ
Cho em xin cái extension gợi ý và hiển thị tên branch khi gõ ở command line được không ạ. Em cảm ơn ạ
kênh chia sẻ kiến thức hay vậy mà ít người biết quá, trong tương lai gần anh zai có ý định làm hẳn 1 series full từ a->z về JS không anh zai? cảm ơn anh zai về những kiến thức đã chia sẻ :)
Cảm ơn dev. Sẽ cố gắng.
Qui trình này khá dễ ăn hành
anh ơi em mới tìm hiểu Git, anh cho em thắc mắc 1 xíu với ạ.
Trên nhánh master ví dụ mình phát triển phiên bản ed1 lên ed2 rồi lên ed3,...các phiên bản này đều tốt và đúng nhưng giả sử mình cần phải sử dụng hay lấy phiên bản cũ ed1, hay ed2 mà vẫn không ảnh hưởng đến ed5, ed6 hiện tại mình đang phải triển thì mình có phương án sao vậy ạ
Cty em toàn Fork repo thành một cái của riêng mình, xong clone repo đó về, tạo branch -> dev trên branch đó -> upstream branch đó lên remote -> tạo Pull Request tới Repo ban đầu. Không biết qui trình vậy có vấn đề j không anh, tại em thấy fork sẽ đỡ rối hơn là xài chung 1 remote repo
Cảm ơn sư phụ
Roaming đâu đây zậy?
Hi anh, bài giản anh rất bổ ích ạ.
Anh có thể chia sẻ cho em extension gì của vscode để hiển thị branch trong Terminal ko bác
FIG nha em!
anh chia sẻ kiến thức rất thực tế dành cho người biết sơ qua về git, github, trong vcode anh dùng extension nào để gõ git vậy ạ
Vậy học nghiêm túc đi nhé. Đến lúc đó họ lại nạt cho.
giờ git của e các nhánh tự up to date với nhau thì làm cách nào để chạy riêng được vậy mn, dù là trên local nhưng sao git nó lại làm thế với e nhỉ :((
Cảm ơn a nhờ blog của a e nạp thêm được nhiều kiến thức. A có thể làm hướng dẫn về OAuth nodejs với gg được không ạ. Cảm ơn a nhiều
Use passport hử em?
@@anonystick Dạ a tương tự vậy. E đang học cách làm smart home kết nối nodejs với goole . A có thể giúp e được k ạ
Kênh hay như này mà lượt đăng ký ít quá
Hữu duyên ta mới gặp nhau đó dev, do chúng ta có cùng một vấn đề.
sao đến chỗ pull lại k có cái nào để pull
e chua thay a merge hotfix ve develop?
like trước xem sao
cho e hỏi, trường hợp trên develop đang có feature đã sẵn sàng để release và feature trong quá trình test. vậy khi cần release thì feature chưa test xong sẽ giải quyết như nào ạ?
Ok em, video sau anh nói về 5 tình huống thường gặp khi sử dụng Git trong đó có trường hợp của em. Đang làm B mà Phải fix A.
Cảm ơn anh, em xem video từ tối hôm qua và ngồi practice cả ngày nay luôn, trước giờ em chỉ biết push pull fetch, video rất bổ ích ạ. Như góp ý từ anh phía dưới thì thêm khâu rebase từ develop về trước khi push feature lên develop (để check có feature từ ai/team khác được merge vào develop không) thì xuất sắc luôn ạ.
Một lần nữa cảm ơn anh ạ, them theo dõi FB page mấy năm nay xem mấy tips của anh thôi nhưng đây là video practical and cực useful đầu tiên đối với em ^^
Cảm ơn em. Anh hiểu ý em. Thật ra, giờ anh không code nữa chỉ làm quản lý kiểu khác. Nên cũng không nhớ nhiều về thời xưa. Nên đôi lúc thiếu sót quá. Anh em thông cảm. Cũng lâu rồi ko đụng code chỉ định hường kinh doanh của công ty. Đôi lời với em, vì comment của em khá hiểu anh. Trân trọng!
Chào b, cho mình hỏi khi pull từ feature tới release và tới develop phải rebase. Vậy ở tại đây mình sẽ dùng lệnh git rebase để merge code của thành viên khác giống như git merge bth đúng ko b nhỉ. Rồi mới tiếp tục là push lên main. Mình cảm ơn
@@aitrong4884 Vai trò của rebase có thể được tóm tắt ngắn gọn như sau: bạn có thể update, delete, copy và paste một lịch sử commit nhất định, do đó, việc sử dụng hợp lý lệnh rebase có thể làm cho commit của chúng ta trở nên rõ ràng và ngắn gọn! Cứ bật `git log` lên rồi rebase theo HEAD~! là được. Bên tôi không nghiệm ngặt chuyện đó.
@@anonystick e cảm ơn
@@aitrong4884 Hello, chắc bạn viết nhầm "pull". Khi feature dev xong sẽ được test và mình push lên develop, nhưng trước khi push phải chắc chắn là code ở nhánh feature của mình là code mới nhất từ develop + code của feature đang dev. Nên mình phải qua 1 bước là đưa code mới nhất từ develop về, nếu có conflict thì giải quyết rồi push lên develop. Ví dụ git rebase diagram mình hiểu:
feature: x-----A
/
develop: x-----x-----x
Sau khi clone từ develop ra feature để dev feature A thì ở develop đã có 2 update. Nên trước khi push mình phải đưa nhánh feature trở thành: x-----x-----x-----A bằng rebase. Lúc này sẽ là:
feature: x-----x-----x-----A
develop: x-----x-----x
Push feature A lên là done. Nếu có sai mong mọi người sửa ạ!
Hình như đoạn a sửa code ở nhánh release lần thứ 2 khi checkout từ develop thiếu bước merge từ nhánh release về develop đúng k ạ, e thấy merge từ release lên main, mà chưa merge về develop
Để anh xem lại đã hen
Hi a, a dùng tool hay config như thế nào để nó có giao diện + nhắc lệnh trong cái terminal của vs code v ạ :D. Xin a chỉ giáo e vs ạ.
Fig nha em!
Cái xoá nhánh có thể setting trong git để nó tự xoá sau khi đc merge vào nhánh develop và main đúng ko anh?
Chưa hiểu câu hỏi. Xóa nhánh thì local và remote trongv ideo anh có nói và làm rồi á .
Anh có thể làm video về push notification với NodeJS được không ạ ?
push notification cho mobile hay web??
@@anonystick Nếu được thì cho mobile được không anh
sao lai cần phải xóa a? mình giữ nguyên lại thì có tác động gì a, cty e cũng follow chuẩn chung này nhưng hoàn toàn ko có xóa branch trên remote sau khi release lên production
Tuỳ vào yêu cầu thôi em. Bên anh quản lý nhiều quá nên xong và release rồi xoá
Cho e hỏi anh dùng extension gì mà nó hiện được các tên branch trong khi tương tác với terminal ạ
Fig em. Có trong description á em.
@@anonystick à à Thanks anh nhiều ạ \
hình như anh thiếu mất 1 vài bước sau khi merge release vào main, sau đó anh quên checkout qua develop & merge master vào develop lại đúng ko anh
Anh xem lại điều em nói thì không phải do anh không remote á chứ.
cái gợi ý hiện lên khi gõ terminal là cài gì vậy ạ
Fig.
Em chào anh, anh có thể cho em tên của Extensios mà anh cài trên VS code mà gợi ý các câu lệnh GIT như anh đang dùng được không ạ, em cảm ơn anh ạ.
git là fig nha em. vs code là cobalt2 á em
@@anonystick em cảm ơn anh ạ
Nhiều lúc nghe giọng anh như giọng ông nguyễn ngọc ngạn ý..🤣🤣
Èo anh sợ Ông này nhất. Chết thật :(
@@anonystick chắc tại nghe truyện ma nhiều quá😁😁
giờ code team cứ dùng GUI cho ít sai sót như github desktop
anh dùng extention gì để trên terminal hiện tên branch hiện tại luôn v ạ
Fig nha em
@@anonystick s em search k thấy cái nào tên fig hết nhỉ
@@namhoai452 fig.io/ nha em
@@anonystick dạ em cảm ơn anh, mong a ra video sử dụng cái này ạ
Nó sẽ có 1 vấn đề là feature này chứa code của feature kia, khi mà tester đã kiểm thử xong feature 1,, feature 2 vẫn đang phải test tiếp chưa lên prod đc, bài toán đặt ra là giờ chỉ muốn lên prod cho feature 1 thôi thì a giải quyết ntn ạ?, với cái luồng git a nói thì e hình dung là phải chờ cho tất cả các feaure xong thì mới lên prod đc, ví dụ nêu như team có 4 dev, mỗi dev 1 feature thì phải chờ xong hết tất cả 4 feature mới lên prod đc
Có video rồi nha em!
@@anonystick video về git rebase và git merge ạ a, nếu v thì e thấy vẫn chưa giải quyết đc trường hợp như e nói a, cứ phát triển 1 tính năng mới mà checkout từ develop ra là e thấy ko ổn rồi, tính năng của ông này chứa tính năng của bà kia, ko đóng gói đc tính năng
@@anonystick các tính năng phát triển song song, mà code tính năng này chưa code tính năng khác thì rất khó cho việc triển khai trên staging, prod
@@anonystick dự án về micro frontend chỉ 1 repo mà triển theo cách này thì đúng toang luôn a ạ
Bên mình nhánh dev chỉ sử dụng cho anh em merge feature vào để test cho môi trường sandbox, sẽ có 1 nhánh release ( hoặc staging) để dev checkout code và phát triển feature trên đấy. QA sẽ test đồng thời 2 môi trường sandbox và live2 ( nhánh release) . Sau khi live 2 ok mới merge vào master rồi mới lên mt prod.
làm sao cái term của anh nó gợi ý như thế dc ạ
FIG nha em
Em có thể hỏi anh làm ở công ty nào ko ạ?
Anh làm free em à. Họ chưa nhận Anh
làm sao torng command của anh nó hiện lệnh git gợi ý vậy
Đây em ơi: th-cam.com/video/qnn8bqRsijk/w-d-xo.html
@@anonystick em sài win :(
Cái fig xài sướng mà chỉ support IOS :((
hồi đi học xem chẳng hiểu mẹ gì, đi làm xem thì ngấm dần đó ae =))
1 branch feature phải được tạo (checkout) từ master, sau khi phát triển tính năng xong tính năng sẽ merge vào develop hay staging, chứ ko phải tạo từ branch feature develop như này là sai hoàn toàn.
Thôi thôi. Tôi xin. Việc đúng sai ở đây tùy vào mỗi công ty, như đã nói trong video. Đây không phải là cách lý tưởng để bảo đảm team làm việc hiệu quả. Nhưng nó tốt cho tôi và anh em ở hiện tại. Cảm ơn lời động viên của bạn.
chả có gì sai hoàn toàn và cũng chả có cái gì đúng hoàn toàn, tùy hoàn cảnh công việc mỗi cty
E ráng xem hết r nhma anh nói lóng ngóng trình bày lủng củng, khó hiểu thật sự. Xem k hiểu gì trơn
Uhm rất xl em vì sự lóng ngóng này. cho nên cần những comment động viên như em. Tks em!