Lập trình viên Phải Biết 10 kỹ thuật Git nâng cao này | TrungQuanDev | Thành thạo Git - GitHub

[@trungquandev]

✍Mình thấy có một vài bạn khá quan tâm tới câu chuyện "1 pull request thì 1 hay nhiều commits" như mình có chia sẻ trong video, vì vậy mình sẽ tổng hợp lại và ghim câu chuyện này ở comment này nhé. (Và mình rất hoan nghênh các bạn rep lại comment ở đây để cùng chia sẻ kiến thức, mình luôn sẵn sàng open với những kiến thức có giá trị của các bạn) - Đầu tiên mình sẽ clear rõ lại luôn: cả 2 phong cách "Một pull một commit" hoặc "một pull nhiều commit" đều là điều bình thường cả, "không có cái nào là hoàn toàn đúng cũng không có cái nào là hoàn toàn sai" (như mình cũng có nói trong video rồi). Hay nói ngắn gọn như bạn @minhkiTong bên dưới thì "không có cái nào tối ưu nhất, chỉ có cái phù hợp nhất" - mỗi công ty, mỗi team sẽ có những flow riêng để làm việc nhóm phù hợp và phối hợp teamwork trơn tru với nhau. - Về việc mình nói trong video rằng một pull chứa nhiều commit sẽ dễ bị rác commit bởi vì thực tế mình đã từng review code của các bạn mới đi làm, không rõ tại sao mà trong pull của các bạn có lẫn cả commit của những người khác, hiểu đơn giản hơn ví dụ bạn ấy đang làm Task_A nhưng lại chứa cả commit của Task_B, Task_C...vv là những task đã hoàn thành trước đó rồi. - Mình nghĩ cũng vì phần nào nguyên nhân như vậy nên có rất nhiều công ty có quy định 1 Pull Request chỉ nên có 1 Commit đặc biệt khi training các bạn newbie chứ cũng không riêng gì công ty mình :)) Và bản thân mình là một người được tiếp cận với phong cách một pull 1 commit từ những ngày đầu đi làm nên mình cũng khá cẩn thận về vấn đề này, không muốn các bạn mới dính phải vụ nhiều commit rác thôi. - Quay lại câu chuyện của những bạn thuộc phong cách ngược lại đó là "một pull nhiều commits", mình thật sự rất thích các câu trả lời của các bạn, bởi các bạn mang lại nhiều kiến thức cũng như một góc nhìn ngược lại để cùng nhau đào sâu và chia sẻ kiến thức tới mọi người. Mình hy vọng sẽ nhận được thêm những góc nhìn khác nữa ở dưới comment này, và dĩ nhiên chúng ta sẽ thảo luận kiến thức trên tinh thần "văn minh lịch sự" nhé. Nếu ai dùng ngôn từ không phù hợp thì mình sẽ bỏ qua. - Ngoài ra nếu các bạn tìm đọc về câu chuyện này trên google (tiếng Anh) sẽ thấy ngoài kia cũng chia ra 2 phong cách như mình nói, mình ví dụ một vài link bài viết cho các bạn đi qua đây tham khảo thêm nhé. + A case for 1 commit per pull request: dev.to/dvnrsn/a-case-for-1-commit-per-pull-request-474k + A cleaner Github workflow: one commit per Pull Pequest: dev.to/amalv/a-cleaner-github-workflow-one-commit-per-pull-pequest-3ic1 - Cảm ơn và chúc các bạn một ngày tốt lành - Have a good day! 🍀

[@MeowMeow-nf9cb]

chưa hợp lý , thay vì gom rác vào một chỗ nên hướng những bạn fresher có trách nhiệm hơn với việc viết code: - git commit message có ý nghĩa, thể hiện đủ thông tin về việc thay đổi code trong 1 PR - việc lưu lại quá trình giải quyết vấn đề trong 1 PR là cần thiết, thường mỗi một "logical change" nên được lưu lại bởi 1 commit commit1: Add method A to calculate xxxx commit2: Update document for A commit3: Add unit test for A commit4: Fix: A returns wrong value when input is .... commit5: .... Việc luôn tư duy các bước để giải quyết 1 vấn đề là hướng đi đúng đắn hơn so với việc "gom hết vào một chỗ". Về việc squashing hay không chỉ là 1 option giúp main (master) branch nhìn clean hơn, khi vào trong 1 PR vẫn thể hiện rõ chi tiết từng commit

[@MeowMeow-nf9cb]

phía reviewer: khi 1 PR của team member chưa đảm bảo 100% và cần thiết được sửa đổi, sau mỗi lần re-request review, thay vì phải ngồi đọc lại PR 1 commit mà không nắm được điều gì đã được member đấy sửa đổi, reviewer cũng chỉ cần quan tâm đến sự thay đổi trong PR qua các commit mới, giúp tiết kiệm thời gian của các bên

[@duynguyen216]

mình nghĩ bạn bị vấn đề như bạn nêu ra là do sau khi review, bạn không squash merge mà chỉ merge vào master hoặc main. Nếu như bạn merge bạn squash merge vào master thì trên lịch sử của master sẽ chỉ có 1 commit (mới) duy nhất. Lúc này bạn được cả 2 lợi ích là trong feature branch, vẫn có thể xem được thay đổi của code theo từng giai đoạn/comment (cực kỳ quan trọng nếu bạn phải review nhiều PR, PR có nhiều người review và codebase lớn). Và lịch sử của master vẫn sạch sẽ. Còn nếu theo trường phái lúc nào cũng 1 commit/ 1 PR thì khi bạn xem lại lịch sử người ta sẽ không hiểu được vì sao hoặc từ đâu mà dev sửa lại như vậy (vì họ không biết cái code đầu tiên nó nhìn như thế nào).

[@trungquandev]

@@MeowMeow-nf9cb cảm ơn bạn đã tích cực chia sẻ nhé, mình không phản đối trường phái nhiều commit nhưng mình vẫn đóng góp thêm vài điều nữa như sau: - Theo mình thì ở đây không có chuyện gom rác nào cả, rác mà ý mình nói ở đây là khi các bạn cứ push tùm lum loạn commit lên rồi bằng cách nào đó dính cả commit không liên quan tới task đang làm (cá nhân mình làm chuẩn thì chưa gặp nhưng khi review code của các bạn mới đi làm thì mình đã gặp nhiều rồi) - Quay lại về việc mà quy trình bên bạn yêu cầu nhiều commit để thể hiện rõ những sự thay đổi, với những môi trường trước giờ mình làm việc thì công việc luôn được chia nhỏ rất rõ ràng và khoa học theo các phase, đại loại là câu chuyện quản lý task của PM thôi, khi mọi thứ đã rõ ràng thì lúc chúng ta code thường 1 commit là đủ, vẫn có thể theo dõi sự thay đổi code rất bình thường, ví dụ dùng git lens là biết lịch sử ai code chỗ này, tại sao...vv khi cần thiết. - Ý cuối mà bạn nói lúc review lại những sự thay đổi thì cách làm của mình khác, đơn giản lúc review thì đằng nào cũng phải để lại comment trên pull, lần sau thì vào đúng chỗ các comment đó kiểm tra lại nếu thấy oke thì nhấn resolve thôi. - Thank you and have a good day!

[@trungquandev]

@@duynguyen216 chào bạn, cảm ơn bạn đã chia sẻ kiến thức, về vấn đề squash merge thì mình cũng vẫn hay dùng nó kể cả khi 1 pull 1 commit bởi vì nếu merge bình thường thì thằng github cũng sẽ tạo thêm một commit merge nữa. - Về việc xem lại lịch sử thì trước giờ mình chưa gặp phải vấn đề gì lớn lắm, mình nghĩ phần nào do mình tiếp cận với các team mà đã được phân chia công việc rất rõ ràng, chia nhỏ task trong từng srpint cụ thể...vv nên khi làm task mọi thứ khá rõ ràng. Rất ít khi một pull request bị quá lớn, và kể cả có nhìn lại lịch sử chỗ code thay đổi cũng không vấn đề gì. - Fun fact: gõ đến đây mình lại nhớ ngày xưa đi thực tập còn có một quy định từ công ty là 1 pull không quá 15 files changed. Giờ thì mình tự bỏ khái niệm này rồi :)) - Anyway, mình rất respect kiến thức các bạn chia sẻ, chắc chắn sẽ giúp mọi người có nhiều góc nhìn và tư duy hơn về một vấn đề, chúc bạn một ngày tốt lành và đón Tết vui vẻ nhé.

[@sangnguyen5031]

Chỗ git push --force thì mọi người có thể hiểu là: 1. Trước đó mình đã tạo Commit "A" 2. Mình Push cái Commit "A" đó lên Remote rồi 3. Local mình thay đổi cái Commit "A" đó bằng --Amend 4. Khi Push nó sẽ báo lỗi là Remote có Commit "A" rồi và nó khác với Commit "A" của Local, quy định của Remote là phải Pull Commit đó về và resolve nó ở Local trước. Làm vậy sẽ rối hơn. 5. Do đó dùng --Force để ghi đè Commit "A" ở Remote. => Tạo Commit xong chưa Push thì ghi đè --Amend bao nhiêu lần rồi Push không sao. => Tạo Commit xong và Push rồi, thì ghi đè --Amend ở Local xong phải ghi đè --Force ở Remote.

[@trungquandev]

Cảm ơn bạn đã giải thích rất chi tiết và cẩn thận nhé, + 1 Respect. Nhiều khi quay video cố lắm mà có lúc mình cũng không ngồi nói được tới mức kỹ hơn nữa như này ^^

[@sangnguyen5031]

@@trungquandev Cám ơn bạn. Bạn đã chia sẽ rất tốt rồi. Mình cũng là người đi tìm thêm kiến thức thôi, cũng muốn chia sẽ để những người đi tìm kiến thức như mình hiểu thêm nếu có thắc mắc :D

[@obitouchiha8853]

thank bro nha , very clean

[@KhoaNguyen-pw9xb]

cảm ơn bạn , mình thử cái amend quài mà lỗi , thông tin chia sẻ bổ ích .

[@yughiole7088]

Ẹc sao mình ko thấy comment này sớm hơn nhỉ hh, trước không biết nên mò mẫm tìm hiểu mãi mới ngộ ra :))

[@adamtong07]

27:31: Ở phần git remote này sẽ có thêm hữu ích nữa khi công việc bạn làm cần đẩy lên 2 repo khác nhau (github và gitlab) chẳng hạn. Thì có thể một repo là internal để test trước và repo còn lại của khách hàng Và sau khi git remote add từng repo thì các bạn có thể đẩy code ở local lên nhiều repo khác nhau. Git push internal task_18 (cho repo internal cần test qua trước) Sau đó git push origin task_18 cho repo của khách hàng

[@nguyennoiphap6989]

cảm ơn bạn đã chia sẻ ^^

[@devquen37]

Video dài nhưng chất lượng thật sự, bạn nào newbie mới làm việc với git em sẽ đưa video này cho bạn đó là có thể join làm với team r.

[@trungquandev]

Lâu lắm mới thấy em comment, dạo này công việc thuận lợi cả chứ em?

[@mangketnoi]

Cám ơn serial Git này của Quân. Giờ mới hiểu và thấy nó hay. Trước cứ bị lỗi này lỗi kia. Làm PHP Local push lên Rep ngon lành hết, xong vào server pull về toàn bị lỗi xung đột những file đang có sẵn, do mình không làm đúng quy trình. Cái được cái không lắm khi kéo tay khổ luôn.

[@tungphunghuu934]

Quá xịn anh ưi Git merge thì sẽ có thêm merge commit, code được merge theo đúng thứ tự tgian nên nhìn commit history sẽ biết các members khác đã thao tác những gì, nhược điểm là làm commit history hơi dài dòng Git rebase thì nó ko tạo cái merge commit khi merge code hay resolve conflicts nên nhìn commit history gọn hơn Gitflow convention của team hiện tại như nào thì mình follow thôi ae :D

[@trungquandev]

Ừa mỗi team chắc chắn sẽ có flow khác nhau phụ thuộc vào nhiều yếu tố từ con người cho tới dự án, miễn sao phối hợp teamwork làm việc trơn tru là oke hết mà. Thanks em đã chia sẻ về Git Merge vs Git Rebase nha, a đọc về 2 cái này cũng lâu lắm rồi mà khá ít dùng tới git Merge, quen Rebase là cứ thế dùng :))

[@QuangTri-w1j]

@@trungquandev a ơi, cho e hỏi vd xài rebase rồi, thì việc mình quay lại bằng git reset bt đúng hk a.

[@thanhlamnguyen7953]

Kiến thức anh chia sẻ rất hay và sát thực tế, many thanks

[@trungquandev]

Không có gì em nhé, anh vẫn luôn giữ đúng tinh thần như slogan: chia sẻ kiến thức giá trị + thực tế lâu nay có trên page fb của anh luôn đó :D Nếu có bạn bè cũng học lập trình thì share kênh ủng hộ anh với nha ^^

[@tiepnguyenngoc2526]

Khá hay mọi người ạ cần chia sẻ rộng rãi đến các bạn đồng môn

[@trungquandev]

Cảm ơn em nhé, hi vọng video này sẽ được nhiều bạn biết đến hơn nữa :D

[@Bliert]

cuối năm rồi mà anh còn năng suất quá

[@trungquandev]

- Cảm ơn em, chúc em năm mới cùng gia đình nhiều sức khỏe, thành công, và bản thân sẽ đạt được các mục tiêu mà mình mong muốn nhé. - Gần tết tập trung cho xong giáo trình khóa MERN Advanced với nhiều việc nên ra video hơi chậm chút đó em, làm xong cái này là ra Tết rồi cũng mới có thời gian làm video mới tiếp được ấy mà :)))

[@dihuynh4893]

đỉnh quá anh. lại tiếp thu được kiến thức bổ ích. cảm ơn anh nhiều :> mong năm mới anh ra video sharing nhiều hơn kiến thức bổ ích nữa ạ

[@trungquandev]

Không có gì em nha, học tốt nhé, và có bạn bè cũng học lập trình thì share kênh ủng hộ anh vs nha ^^

[@MeowMeow-nf9cb]

Best practice: Không nên chỉ có 1 commit trong PR. Commit là 1 snapshot source, khi code hiện tại sai sót hoặc chưa đi đúng hướng có thể quay lại snapshot trước đó. Ngoài ra khi có nhiều hơn 1 member cùng làm việc trên 1 PR thì để 1 commit rất dở hơi, không tận dụng được ưu điểm của git. Nếu muốn PR được merge nhìn cho đẹp thì có thể dùng chức năng squashing commits

[@trungquandev]

- Đầu tiên cảm ơn quan điểm của bạn nhé, mình cũng có vài ý sau: - Cái squashing khi merge thì mình biết. - Mình thấy bạn vẫn chưa nói cụ thể về vấn đề 1 commit “dở hơi” là cụ thể “dở hơi” ở đâu, tận dụng ưu điểm gì của git? Bạn có thể nói rõ thêm hơn không? - Còn về việc nhiều người cùng làm việc trên 1 pull thì ok nhưng cũng phải quay lại vấn đề là tại sao cần phải như vậy, thông thường nếu có một công việc lớn thì đều nên chia nhỏ và chia rõ ràng các phase, mỗi cá nhân sẽ đảm nhiệm chuẩn từng phase, mình không rõ bạn đã từng làm ở team hay công ty như nào, còn mình thì từ thời chập chững đi làm đã được training rõ ràng về cách mà các team trong công ty làm git, cách làm như mình đã chia sẻ trong video và từ đó tới h mọi việc cũng vẫn trơn tru không vấn đề gì. - Về cái snapshot bạn nói thì nghe cũng hợp lý nhưng mình đang thấy thực tế một pull code chuẩn một công việc thì không áp dụng nhiều lắm vấn đề snapshot này, đúng tính năng thì mọi thứ nó đều liên quan tới nhau rồi. - Cuối cùng thì như mình cũng nói trong video rồi đó, vấn đề một pull một commit hay nhiều commit là lựa chọn của mỗi người rồi, cũng chẳng có gì sai cả, miễn sao công việc không vấn đề gì thì cứ quen rồi làm thôi, riêng với mình thì mình đã quen tự kiểm soát về 1 commit sao cho clean gọn gàng ngay từ bước mình xử lý nó hay hơn là push tùm lum rồi cuối cùng squash lại và mình chia sẻ đúng những gì lâu nay mình làm cho các bạn khác. - Anyway cảm ơn góc nhìn của bạn và chúc bạn một ngày tốt lành!

[@juhandvan]

Nhiều commit trên một PR mình thấy có nhược điểm là khi cần cherry-pick thì sẽ vất vả hơn.

[@hathien5839]

em mới năm 1 và xem qua cái git anh hướng dẫn đúng lúc em cần ạ. Cảm ơn anh nhiều.😁

[@trungquandev]

Ừa học được quen rồi sau đi làm đỡ khó khăn vụ Git giai đoạn đầu nha. Trước mãi tới lúc đi thực tập anh mới được học bài bản về Git như thế này đó.

[@hahnquan9914]

thank you :v tôi đang tìm video để đào tạo lính của cty cho nhanh thì gặp luôn ông làm :v

[@trungquandev]

Nhanh gọn lẹ luôn, tôi cũng làm phần nào để sau có gì tiện đẩy luôn cho mem mới mà :v

[@hoanghuynh918]

ko ai chỉ rõ như vậy trên cái youtube này, appreciated it !

[@trungquandev]

You're welcome :)) Trước giờ mình luôn chia sẻ giá trị thực tế mà, không làm trò Dirty Marketing như mấy đứa bán khoá học vớ vẩn, slogan này mình để trên page FB lâu nay luôn :)) - Có bạn bè cũng quan tâm tới chủ đề này thì nhờ bạn share kênh ủng hộ kênh mình nhé, thank you!

[@hoanghuynh918]

@@trungquandev để tránh trường hợp push lên nhánh của anh trung quân, cách 1: các bạn clone về xóa thư mục .git (thư mục này bị ẩn --> show hidden files trước), tạo repo mới trên tk của mình rồi làm, cách 2: clone về copy qua thư mục chỗ khác chưa có .git

[@ThongNguyenChanh]

Video thật bổ ích ❤❤, chúc anh năm mới đạt được nhiều thành công mới

[@trungquandev]

Cảm ơn em nha, chúc em năm mới cũng đạt được những thành công và dự định của bản thân nhé.

Em cảm ơn anh nhiều! mình có thể kết hợp git pull --rebase origin master để cập nhật code mới về nhánh ở local cũng được mà đúng không anh ạ

[@trungquandev]

Được hết nha em, cũng tương tự như câu chuyện git commit --amend --no-edit ấy, ban đầu anh soạn kịch bản video cũng nghĩ có nên đưa vào luôn không nhưng mà thấy cứ lan man quá sợ các bạn khó hiểu nên anh làm chuẩn từ từ từng bước để các bạn mới dễ hiểu hơn á. Còn khi chúng ta đi làm lâu rồi sẽ dần dần biết thêm những lệnh rút gọn hoặc cứ quen tay rồi thì làm kiểu gì cho ra kết quả như nhau là oke hết ấy mà ^^

[@youngtee_01]

10:24 trạng thái chuẩn bị đưa code đi e nhớ ko nhầm đgl staging area a ạ. Lâu phết mới thấy video mới từ a 😁😁Nội dung trong video vẫn súc tích dễ hiểu a ơi, e cx hiểu rõ thêm 1 vài lệnh 😍😍

[@trungquandev]

Ừa nó là Staging, lúc quay video anh cố nghĩ sao để giải thích bằng tiếng Việt :))) Gần tết tập trung cho xong giáo trình khóa MERN Advanced với nhiều việc nên ra video hơi chậm chút ấy mà em :))

[@PhucNguyen-dy9hg]

đỉnh quá anh ơi 😊

[@vantung2210]

Video này còn thiếu git reset và git stash, 2 cái này em thấy cũng dùng nhiều và khá hữu ích cho dev trong 1 vài trường hợp ^^

[@anhdn18]

A có thể hướng dẫn về CI/CD được hog ạ

[@trungquandev]

Ok em nha, chủ đề này anh đã có note trong plan làm một bộ video chất lượng cho hội viên xịn xò trên kênh của anh giống như em nha. Anh sẽ cố sắp xếp làm sớm, dạo này lu bu bận bịu công việc quá :)))

[@tienle5234]

anh có thể hướng dẫn chức năng đăng nhập bằng google trong dự án thực tế bằng nodejs vs passport được k ạ

[@trungquandev]

Ừa để anh note lại nhé, hầu như h anh ít dùng tới Passport nữa bởi quen JWT - jsonwebtokens rồi, a sẽ cố gắng lên kịch bản làm chủ đề riêng về cái login mạng xã hội nhé

[@tutosolve]

Lẽ ra em nên xem video sớm hơn, Em thực tập ở cty, chưa nói tới kĩ năng code ra sao, nhưng em gặp khó khăn trong các thao tác git để PR tới Mentor, Nhiều lúc Git gà quá, nên rất ngại.

[@trungquandev]

Giờ vẫn chưa muộn mà, học đi để quen dần rồi cố gắng hơn nữa em nhé.

[@nguyennoiphap6989]

Mình mở video nghe là chủ yếu chứ không xem. Mà nghe tiếng phím cơ phê quá =))))

[@trungquandev]

Có clip mình tự build và Sound Test luôn cho bác nè =))) kzbin.info/www/bejne/eWmwpXRulrGYjac

[@xuankhoanguyen7675]

Ví dụ ở --amend, trước đó mình có push commit A lên và bạn B đã pull về, sau đó có thay đổi và dùng --amend, thì khi đó bạn B sẽ làm gì để có code mới nhỉ, vì nếu bạn B pull nữa hình như vẫn kg có code mới

[@nvhmusic8316]

Video hay quá anh ạ! Hi vọng a ra thêm video về docker 🥰

[@trungquandev]

Oke em, có thời gian anh sẽ làm dần hết nha, đợt này đang tập trung hoàn thiện nhanh giáo trình bộ MERN Advanced rồi còn công việc nữa nên lu bu quá :))

[@nguyenquanganh7266]

+1 tiếp thu kiên thức mới khôi phục commit lỡ tay bị xoá. cảm ơn anh

[@NgocHoangMinh]

nếu như dùng git rebase thì mình hay dùng 'git pull origin ` để pull code mới nhất từ branch chung về, vậy 2 cách này cách nào an toàn hơn và dễ quản lý log hơn về sau, mong bạn chia sẻ.

[@glorynt7925]

pull thì liên quan gì rebase

[@NgocHoangMinh]

trên clip có sử dụng rebase để ấy được code mới nhất từ branch master, mình thì hay dùng git pull origin từ branch master về, mình không hiểu hết về 2 cách này, mong chủ kênh chia sẻ giúp mình.

[@glorynt7925]

@@NgocHoangMinh bạn phải hiểu như thế này, bạn và 1 đồng đội vô 1 dự án, dự án đó đang chạy code trên production mà code đang chạy là từ nhánh master, bạn và đồng đội đó phải checkout và pull code từ nhánh master và từ nhánh này tạo nhánh con ra để làm task, 1 ngày đẹp trời code đồng đội của bạn pass test và lên production trước, ở đây code bạn đã tạo checkout từ master hiện đang bị outdate (cũ) và có các trường hơp xảy ra: 1./ code đồng đội của bạn sẽ có những chức năng mà bạn cần, hay 1 lý do nào đó, lúc này bạn phải rebase lại với production để đồng bộ code mới nhất về nhánh của bạn, mà code mới nhất sẽ có các function mà bạn cần, có thể dùng merge nhưng merge nó sẽ lấy cả commit của đồng đội của bạn nên cây git commit sẽ hơi loạn cho các bạn mới. 2./ đồng đội bạn vô tình code vô trúng file mà bạn đang code -> bị conflict, lúc này bạn không thể nào pr hoặc merge code của bạn vào product vì đang bị conflict, bạn buộc phải xử lý conflict trước, có thể dùng rebase hoặc merge, ở đây tuỳ trường hợp, mình thì dùng cả 2, nếu conflict với master, bạn chỉ cần checkout qua master rồi git pull để lấy code mới nhất về, sau đó chuyển về nhánh bạn đang làm, có thể dùng lệnh git checkout - để checkout nhanh về nhánh trước đó, ở nhánh của bạn hãy chạy lệnh git rebase origin/master -> conflict -> xử lý confilct -> git add . -> continue -> git push, ở đây nếu branch của bạn đã push lên rồi thì git nó sẽ báo đã có branch của bạn ở phía sau như trong video, bạn buộc phải lên gitlab hoặc github xoá cái branch của bạn để púsh lên hoặc chạy lệnh git push origin -f để force nhánh của bạn lên thẳng và mới nhất nhưng phải đảm bảo kiểm tra code vì có thể gây mất code.

[@trungquandev]

@@glorynt7925 10 điểm không có nhưng cho chiếc comment chỉn chu và tâm huyết này :)) Respect 🤝

[@hehoeohho]

Mình nghĩ là pull = fetch + merge => câu truyện n sẽ là b chọn merge hay rebase ( search gg có ), còn mình cũng hay pull/merge vì mình k muốn bỏ xót commit nào, trước mình làm outsource cho bên dev Nhật họ check và merge thì họ bắt mình k được rebase / force push :D ( chắc do mình gà )

[@AnVo-ju1cy]

Anh ơi anh có thể cho em hỏi được không ạ! Khi em chưa cấu hình SSH thì sử dụng HTTPS để push code lên thì nó không bắt nhập username và password, sau khi em cấu hình SSH xong thì khi push code lên và remote là của HTTPS thì nó bắt nhập username và password anh có thể giải thích giúp em không ạ. Em cảm ơn ạ.

[@vuduyhung-Hungsiro]

" 1 pull request chỉ nên có 1 commit nếu chuẩn chỉnh " -> mình hi vọng tư duy sai lệch này được gỡ bỏ và ko bị lan toả tới nhiều người.

[@trungquandev]

- Bạn nói được từ “sai lệch” thì bạn có thể giải thích được tại sao nó lại là “sai lệch” không? Chứ chỉ nói không như thế này thì kì quá. - Nếu thật sự điều đó là sai thì tại sao lại có commit -amend để gộp về 1 lúc commit? - Ở dưới cũng có một comment về vấn đề này và mình đã comment rất rõ cũng như nói trong video rồi, chẳng có gì sai dù là 1 hay nhiều commit trong 1 pull, cách chọn dùng là của mỗi người, nhưng để gọn gàng clean thì “nên là 1 commit” và mình đã áp dụng nó lâu nay từ thời mới đi làm được công ty training về git tới giờ không vấn đề gì cả => nếu muốn đọc kỹ hơn thì b có thể kéo xuống dưới tìm và đọc thêm. - Chờ thêm phần giải thích từ “sai lệch” của bạn? Mình luôn đón nhận kiến thức đúng đắn và văn minh lịch sự nhé.

[@trungquandev]

Nếu bạn tìm chủ đề này để đọc thì cũng sẽ thấy những câu chuyện giống như chia ra các trường phái quen thuộc sử dụng thôi, có lẽ nhiều người quan tâm tới vấn đề này, tối nay về nhà mình sẽ note một chiếc comment về vấn đề này và ghim luôn ở video này nhé. - 2 bài viết này khá oke mà mình có thể note nhanh luôn tại đây cho bạn và cho các bạn đi qua tham khảo thêm: dev.to/amalv/a-cleaner-github-workflow-one-commit-per-pull-pequest-3ic1 dev.to/dvnrsn/a-case-for-1-commit-per-pull-request-474k

[@dooezgo]

​@@trungquandev kinh nghiệm thực tế của mình 1 PR chỉ có 1 commit review rất tù. Ví dụ task đó update 3 file. Mỗi file update có 1 mục đích khác nhau. Commit đầu support sub task 1, cần update file 1 và 2, sub task 2 update file 2 (LoC khác subtask 1). Thì trong 1 PR có 2 commit nó sẽ rõ ràng hơn về mục đích các LoC update trong file thứ 2. Về lâu về dài khi show history của từng LoC sẽ cực kì chi tiết, mình thường dùng Gitlens của VS code. Nhấn vào dòng nào là nó hiện được line đó lần commit gần nhất change để làm gì, ai change. Nhiều commit không có nghĩa là rác, mà chỉ sợ đẩy toàn commit rác lên. Cách để hạn chế là dùng git rebase -i

[@dooezgo]

​@@trungquandev nhiều commit không có nghĩa là rác, 1 commit không ko nghĩa là clean. 1 PR clean là 1 PR có history và mục đích change rõ ràng. Ví dụ task đó cần change 3 file. Sub task 1, cần change file 1 và 2. Subtask 2 cần change file 2 (khác LoC sub task 1) và 3. Khi đó history của file 2 sẽ rõ ràng mục đích của từng line bị change hơn. Về lâu về dài khi size code lớn thì chỉ cần click vào dòng nào là nó sẽ hiện được lần change gần nhất để làm gì, ai change, những file liên quan của commit change đó. Mình thường dùng Gitlens của VS Code nó sẽ show đc cái này. Nếu số lượng file, code size change lớn, 1 commit review rất mất thời gian vì phải đi hỏi đi hỏi lại là code chỗ đó tại sao change vậy. 1 commit kia chỉ thành mang tính tượng trưng. Người sau coi lại phải đào vô tận Jira, Redmine chưa chắc đã đủ thông tin. Để hạn chế commit rác thì có commit amend như bạn chỉ nhưng chỉ có tác dụng commit gần nhất, cách mình thường dùng là dùng rebase -i

[@trungquandev]

@dooezgo5619 ừa cảm ơn bạn đã để lại comment và kiến thức nhé, mình cũng đã từng gặp khá nhiều trường hợp các bạn mới đi làm đẩy rất nhiều commit rác lên vào 1 pull rồi, mình nghĩ cũng vì phần nào nguyên nhân như vậy nên rất nhiều công ty có quy định 1 Pull Request chỉ nên có 1 Commit đặc biệt khi training các bạn newbie chứ cũng không riêng gì công ty mình :)) Còn khi đã đi làm một thời gian dài rồi thì sẽ hiểu, cái vấn đề này nó cũng như câu chuyện chẳng có gì đúng sai mà đơn giản là cái nào phù hợp thôi, cả team thống nhất một chuẩn flow thì cứ thế mà quẩy code trơn tru thoải mái. Riêng với mình thì mình được tiếp cận việc một pull 1 commit từ những ngày đầu đi làm nên mình cũng khá cẩn thận về vấn đề này, không muốn các bạn mới dính phải vụ nhiều commit rác thôi.

[@maimailabaolau_]

anh có dùng cái extension nào cho cái terminal không ạ?

[@trungquandev]

Không em, Terminal thì em follow theo bài viết này của anh nhé: trungquandev.com/cai-dat-iterm2-oh-my-zsh-zsh-autosuggestions-va-zsh-syntax-highlighting-tren-macos-m1-silicon

[@TuongNguyen-ts1uo]

A có dạy code C++ không ạ

[@trungquandev]

Anh không á, anh chuyên về bên web với JavaScript nha em.

[@iamnguyenhoanganh]

bổ x anh ơii

[@trungquandev]

Bổ x nhưng không hại não, rất thực tế và dễ hiểu đúng k em :))))

[@someoneudontknow3470]

Cho em hỏi tại sao không dùng git pull origin master mà phải dùng git rebase master vậy anh

[@VODIEN_SOUNDS]

mình cũng thắc mắc giống bạn.

[@trungquandev]

- Thông thường mình đang đứng ở branch nào thì mình pull chuẩn code của branch đó trên GitHub từ xa về em. - Trong ví dụ của anh làm đúng chuẩn như này: anh đứng từ master ở máy local thì anh mới chạy `git pull origin master` - Sau đó ở branch khác mà mình làm việc thì mới dùng tới git rebase hoặc git merge để apply code từ nhánh chính (master) về nhánh đang làm việc đó.

[@VODIEN_SOUNDS]

@@trungquandev Ví dụ em đang ở branch task_18, và br task_19 lúc này chưa được push lên master. Thông thường muốn lấy code từ task_19 luôn thì em git pull origin task_19 hay là rebase ạ?

[@trungquandev]

- Oke a hiểu ý em rồi, lúc này nhé, cái task_19 em (hoặc đồng nghiệp của em) sẽ cần phải cho nó lên github, tạo pull request của task_19 đó luôn cũng được và để đó, chưa merge vào master. - Quay lại với máy local mà em đang đứng ở task_18, đầu tiên em checkout về master (bởi vì nếu làm teamwork chuẩn thì tất cả mọi người đều phải base từ master ra) tiếp theo sau đó em sẽ cần phải fetch cái task_19 kia từ trên Github về máy bằng lệnh này (git fetch origin) và tiếp tục tạo ra branch task_19 ở máy của em bằng lệnh (git checkout -b task_19 origin/task_19). - Cuối cùng là checkout lại về task_18 và chạy "git rebase task_19" thôi.

[@VODIEN_SOUNDS]

@@trungquandev cảm ơn anh đã giải ngố giúp em ạ

[@porgatsdace1537]

anh thêm tý về devops Be đi

[@trungquandev]

Ok em nhé, cái gì anh cũng muốn làm hết :)), chỉ là không đủ thời gian thôi nên anh cứ từ từ thong thả, làm youtube này với anh hiện tại là đam mê, coi như tay trái vui vui thôi chứ anh không phải kiểu như mấy người khác tập trung kiếm tiền từ lùa gà khóa học ...vv nên sẽ không nhanh được ấy :)) Và dĩ nhiên anh đã làm video nào thì cứ yên tâm đảm bảo sẽ "chất lượng" video đó nhé. Anh làm với phong thái ưu tiên chất lượng hơn số lượng mà :))

[@thonghoangpham6085]

anh cho em hỏi nếu như em đang code dở giữa chừng lúc đó em thấy đồng nghiệp có đoạn đó em muốn xài lại, lúc này em thấy anh commit code mình xong chuyển về master xong pull xuống rồi rebase, lúc này em thay bước commit của anh bằng cách em đưa đoạn code em đang làm chưa xong vào stash xong rồi về master pull xuống rồi rebase lại qua nhánh em rồi kéo stash ra làm tiếp được không anh

[@trungquandev]

Được em nha, stash là cách để xử lý như vậy mà, chỉ là anh không hay dùng nó, bình thường anh sẽ commit luôn cho lẹ, lần sau sửa code thêm thì lại --ammend vào cái trước. Nói chung em quen cách nào thì cứ dùng cách đó nhé.

[@LongTong-i3b]

dạ cho em hỏi nếu mình muốn có code của nhánh master thì dùng git rebase từ nhánh con, nó sẽ khác như nào nếu như em git pull origin master về nhánh con vậy ạ

[@trungquandev]

- Cái này anh cũng có rep ở 1 comment khác rồi á, đại loại em cứ tự thử đi là hiểu ngay nha, nó sẽ báo lỗi luôn kiểu như này "You have divergent branches and need to specify how to reconcile them." - Nghĩa là lúc này em cần chỉ định cách reconcile bọn nó, lúc này thì em có thể chạy lệnh kiểu: git pull origin master --rebase thì bản chất nó tương tự việc anh checkout về master xong pull rồi quay lại nhánh đang làm việc và chạy rebase thôi. - Trong video anh muốn giải thích kỹ bản chất nên không dùng mấy lệnh rút gọn sợ lan man dài dòng ấy mà. - Anh note thêm một link thảo luận khá hay cho em và mọi người đi qua tranh thủ đọc thêm nhé: stackoverflow.com/q/36148602/8324172

[@cuongmn]

Anh dùng macbook gì thế ạ?

[@trungquandev]

Macbook Pro 14 inch 2021 (chip M1 Pro) Bản base 16GB Ram / 512 SSD nha em. Anh mua từ đợt nó mới ra. Giờ chắc rẻ hơn nhiều rồi đó.

[@MinhNguyen47857]

a ơi cho e hỏi cái terminal của a cài thêm gì mà nhìn đẹp vậy ạ

[@trungquandev]

- Trên máy Mac thì em có thể follow theo bài viết này của anh nhé: trungquandev.com/cai-dat-iterm2-oh-my-zsh-zsh-autosuggestions-va-zsh-syntax-highlighting-tren-macos-m1-silicon - Còn máy win thì có cái Oh my Posh thì phải, a không nhớ rõ tên lắm nhưng trong gr Discord có nhiều bạn đề cập tới và cài lên nhìn cũng đẹp tương tự đó em.

[@PhucNguyen-wj8yu]

giao diện terminal của anh là ext gì thế ạ

[@trungquandev]

- Nó không phải extension vscode đâu em, trên máy Mac thì em có thể follow theo bài viết này của anh nhé: trungquandev.com/cai-dat-iterm2-oh-my-zsh-zsh-autosuggestions-va-zsh-syntax-highlighting-tren-macos-m1-silicon - Còn máy win thì có cái Oh my Posh thì phải, a không nhớ rõ tên lắm nhưng trong gr Discord có nhiều bạn đề cập tới và cài lên nhìn cũng đẹp tương tự đó em.

[@PhucNguyen-wj8yu]

@@trungquandev dạ a

[@KhoaHuynh-vc6dj]

Xem không hiểu lắm

[@chaobanh5003]

anh ơi cho e hỏi làm web viết blog với MERN stack thì công cụ Rich Text Editors nào tốt nhất vậy ạ ?

[@trungquandev]

Đầu tiên thì anh sẽ clear luôn cho em là trong cái ngành IT và công nghệ này thì hiếm có cái gì gọi là "tốt nhất" nha em, chúng nó thay đổi, cải tiến mỗi ngày, có cái tốt ở thời điểm hiện tại thì rồi cũng bị cái khác ra sau nó kế thừa tinh hoa rồi sẽ lại tốt hơn nữa, đó là sự phát triển. - Về cái Editor em muốn thì em có thể thử Lexical của Facebook nhé: github.com/facebook/lexical

[@chaobanh5003]

@@trungquandev dạ e cảm ơn a nhiều ạ

[@workwithme23]

bờ ren chứ ko phải bờ ranh nha Quân ơi, ko phải mình bắt lỗi vặt đâu, mà xem video của Quân nghe Q nói bờ ren nhiều sợ ae bị đọc nhầm theo á

[@trungquandev]

Cảm ơn b nhé, nhiều khi mấy từ này hay quen miệng từ trước, không để ý nên toàn phát âm nhầm. Giống lần trước đọc nhầm thằng Vite :))

[@duyanminhpham6331]

Branch phát âm bờ ranh là đúng rồi á bạn

[@dinhngocpham6177]

nếu trong trường hợp bị confict thì có cách nào sử lý nhanh không ạ?

[@trungquandev]

"xử lý" em nha, anh là cảnh sát chính tả đấy :)) Còn về conflict thì phải làm thủ công thôi, em phải hiểu tại sao code chỗ đó bị conflict, và conflict với bạn đồng nghiệp nào, từ đó 2 người thảo luận xem giữ phần code nào, bỏ phần code nào, hay là giữ lại cả hai. Trong VSCode cũng có mấy cái đoạn cho chọn code như vậy dễ dàng rồi đó. Làm vài lần là quen tay ngay thôi :))

[@giangnguyentbk]

cái git add, thường mình xài git add -u chứ ko xài git add . , vì include tất cả các file khá phiền phức nếu nó automatically include files ko cần thiết

[@trungquandev]

Thường thì khi đã quen cái gì và làm việc tốt với nó rồi thì cứ làm thôi bạn, với mình thì luôn sẽ là “add .” toàn bộ không thấy có gì phiền phức cả, bởi đang code task nào thì sẽ chuẩn chỉnh task đó, không để chứa file linh tinh không cần thiết. Còn nếu muốn draft code thì có thể dùng git stash là được rồi.

[@giangnguyentbk]

@@trungquandev tại em code C/C++ á anh, nhiều khi build 1 cái là 1 đống file object, file execute,... nên git add -u để nó ignore mấy cái untrack files cũng tiện.

[@trungquandev]

@@giangnguyentbk ừa cứ tiện và linh hoạt sử dụng cho phù hợp công việc của mình ấy mà em, cũng giống câu chuyện 1 pull 1 commit hay nhiều commit mà anh phải ghim comment ở đầu ấy :)) Làm việc với Git này nó đa dạng lắm :))

[@trungquandev]

🔔Join một số cộng đồng lập trình văn minh lịch sự tại đây nhé bạn: 🔗Discord: Cộng đồng lập trình Việt Nam 🇻🇳 : discord.gg/ycSbhP6gDu 🔗Page: TrungQuanDev: facebook.com/trungquandev 🔗Group: Cộng đồng Lập Trình Web • Front-end & Back-end Việt Nam: facebook.com/groups/laptrinhwebvietnam