quá tuyệt vời luôn ạ hic=)) cả chiều tìm hiểu, hỏi chatgpt mãi mà ko hiểu, xem cả các video cx ko hiểu xong thấy cái video dài dài thì nghĩ là thôi thì tốn cả buổi chiều ko hiểu gì thì thêm 30p ngồi nghe có khi lại thấy hiểu hơn, cuối cùng cũng hiểu ạ=)) hic em xin cảm ơn huhu
Không hiểu sao, nhưng mỗi lần xem video của a, e cảm thấy rất thoái mái, cứ chill chill thế nào ấy. Giống như đang ngồi và nghe một người anh kể chuyện cho vậy! Cám ơn a, em rất trân trọng điều đó.
Cám ơn a vì những gì chia sẻ cho cộng đồng. Ở video này e có chia sẻ chút kinh nghiệm cá nhau sau khi đã làm rất nhiều dự án size ~ 100 Mem Thì đã từng trải qua dự án dùng rebease, dự án dùng merge. 1. Dùng merge thì tốn ít time merge hơn, người dùng dê làm hơn nhưng commit lại rất loằng ngoằng, nếu lượng commit lớn thì cực kỳ khó nhìn, đó là ngược điểm 2. Khi dùng rebease thì phải tranning cho a e tư tưởng rebease, rebease sẽ dẫn tới resolver conflict rất là nhiều, chưa nói tới các commit bị revert do đẩy lên sai sau phải revert lại. Ở video thấy a bảo phù hợp dùng cho dự án lớn nhưng e thấy dự án lớn thì lại không nên dùng, các dự án e chạy hoặc nếu đã chạy merge thì k nên áp dụng rebase, nếu đi thì phải đi từ đầu và việc pull phải thực hiện thường xuyên, nếu commit quá xa sẽ dẫn tới time resolver rất lớn, thậm trí sai 1 bước nào đó lấy k đúng bên thì có thể phải làm lại từ đầu. A có chia sẻ gì cho những case đó không chứ e trải qua rất nhiều dự án lớn nhưng e thấy xấu tý nhưng đỡ take time. :d
Minh cung dong y kien. Da tung lam ca 2 rebase voi merge. Nhung cuoi cung phai bo ko lam rebase nua, moi lan rebase phai resolve conflict qua nhieu, qua cuc, va qua ton thoi gian. Co the se phai fix mot loi conflict lam nhieu lan, repeatedly....
Theo mình thấy thì nên nói rõ ra chứ thực tế nhánh dev và nhánh master đều ở chế độ protect chỉ có quản lý mới đẩy lên được thôi, viết thế này nhiều bạn lại tưởng push lên 2 nhánh đó thoải mái lại toang! Ngoài ra khái niệm rebase hiểu đơn giản là biến commit của nhánh khác thành commit nhánh hiện tại (rebase nghĩa là chuyển cơ sở), bản chất là nó biến commit của nhánh cần merge thành commit của nhánh được merge (nghĩa là commit rebase sẽ được bê nguyên nội dung và snapshot sang nhánh mới nên trên tree log sẽ là 1 đường thẳng và các commit này đều bị thay đổi SHA dù giống nội dung và snap shot). Còn git merge là thực hiện merge bình thường tuy nhiên commit vẫn giữ nguyên SHA không thay đổi và cây git sẽ hiển thị không còn là đường thẳng nữa, ngoài ra git merge còn tạo ra 1 commit gọi là commit merge.
300 views và >40 likes, tỉ lệ hơn 10%, content quá sức chất lượng, làm demo vô cùng có tâm. Chúc kênh phát triển vù vù ra thêm nhiều video tutorial cho coder chúng e ạ
Em góp ý chút, thầy có thể để 40% màn hình bên phải dành cho web, graph, GUI kết quả... chỉ cần 60% bên trái code ( IDE ) là được ạ. Khi đó user sẽ xem được cả code và GUI kết quả, mô tả...
Dự án e h đang dùng rebase nhưng việc resolve conf từng commit cực quá. Do đó tl bảo bọn e phải gộp commit lại r mới rebase nhưng thế lại mất đi lịch sử commit, khiến cho việc trace commit khá khó và commit k rõ ràng. A có ý kiến gì về vấn đề này k ạ.
a ơi cho e hỏi với ạ. Có phải quy định là Mt4 phải create trước T5 ko a, vậy trong dự án thực tế thì bắt buộc team dev phải tạo branch, commit rồi T5 mới commit hay sao vậy a
anh cho em hỏi tại sao khi master đã có nhiều commit mà các nhánh khác rebase từ master và resolved conflict hết rồi push lên lại báo phải rebase hoặc merge? lúc đó thì buộc phải dùng force push để push lên mới được.
Cho em hỏi, việc dùng Rebase hình như những leadteam, có quyền merge mới dùng rebase đúng k ạ? còn team member làm task bình thường thì dùng merge thôi đúng k ạ?
Không! Ai cũng có thể dùng, tối ưu hóa cá nhân mà. Nhưng team chỉ merge từ dev, chứ master thì đúng như em nói, chỉ có một vài người có quyền mà thôi. Và cũng chính những người đó tạo branch hotfix từ master. Xem lại phần 1 nếu em chưa hiểu về gitflow hén.
@@anonystick dạ vâng. Thực tế, trong lúc làm việc, em chỉ pull dev về tạo branch, rồi push lên, xong pull dev về nếu cần code mới nhất. Trong lúc ấy em chưa hình dung mình cần rebase ở chỗ nào? anh có thể nói qua không ạ, và em cảm thấy em k cần dùng rebase để tạo một nhánh đẹp ở local, vì ở repo mới cần một nhánh đẹp để dễ quản lý nên dùng rebase.
@@hoanglongpham5907 Đúng, anh có nói trong fb cũng như youtube. Không nhất thiết sử dụng rebase nhưng hãy làm làm theo quy chuẩn là tốt nhất. Đó là lí do vì sao vẫn còn tranh cãi. Nếu đang tốt thì không nhất thiết phải thay đổi. Chỉ thay đổi khi nó không còn phù hợp với em và xu thế.
@@hoanglongpham5907 bạn không cần dùng rebase cũng vẫn làm việc bình thường được nhé. Cái lợi của dùng rebase: kiểm soát conflict tốt hơn, và không có 1 commit thừa (kiểu như commit merge từ nhánh master về nhánh feature) thì trông commit nó đẹp hơn. Không dùng nó cũng chả sao bạn nhé
Em có 1 nhánh feature nó clone từ nhánh Dev ra, và nhánh Dev đc merge vào những feature khác liên tục, trong khi nhánh feature lại ko có thay đổi gì trừ những phần dev cho feature, và giờ em rebase nhánh Dev về nhánh feature thì thấy nó nhiều commit vô cùng, và em muốn squash hết mớ commit đó thành 1 để cho gọn, push lên cho đẹp thì mình làm sao ạ.
reset soft về head của nhánh dev rồi phần changes lưu vào stash -> rebase nhánh dev -> apply stash changes vừa lưu -> commit and push. giờ PR chỉ có 1 commit
![[LIVE] : ONE ลุมพินี 91 | คู่เอก "คมอาวุธ vs อเล็กเซย์"](http://i.ytimg.com/vi/V0RkEfYFsgM/mqdefault.jpg)
quá tuyệt vời luôn ạ hic=)) cả chiều tìm hiểu, hỏi chatgpt mãi mà ko hiểu, xem cả các video cx ko hiểu xong thấy cái video dài dài thì nghĩ là thôi thì tốn cả buổi chiều ko hiểu gì thì thêm 30p ngồi nghe có khi lại thấy hiểu hơn, cuối cùng cũng hiểu ạ=)) hic em xin cảm ơn huhu
Ở đây video đều chất lượng.. chúng ta có duyên
Không hiểu sao, nhưng mỗi lần xem video của a, e cảm thấy rất thoái mái, cứ chill chill thế nào ấy. Giống như đang ngồi và nghe một người anh kể chuyện cho vậy! Cám ơn a, em rất trân trọng điều đó.
Cảm ơn những comments đầy động lực. Trân trọng!
đồng quan điểm
Cám ơn a vì những gì chia sẻ cho cộng đồng.
Ở video này e có chia sẻ chút kinh nghiệm cá nhau sau khi đã làm rất nhiều dự án size ~ 100 Mem
Thì đã từng trải qua dự án dùng rebease, dự án dùng merge.
1. Dùng merge thì tốn ít time merge hơn, người dùng dê làm hơn nhưng commit lại rất loằng ngoằng, nếu lượng commit lớn thì cực kỳ khó nhìn, đó là ngược điểm
2. Khi dùng rebease thì phải tranning cho a e tư tưởng rebease, rebease sẽ dẫn tới resolver conflict rất là nhiều, chưa nói tới các commit bị revert do đẩy lên sai sau phải revert lại.
Ở video thấy a bảo phù hợp dùng cho dự án lớn nhưng e thấy dự án lớn thì lại không nên dùng, các dự án e chạy hoặc nếu đã chạy merge thì k nên áp dụng rebase, nếu đi thì phải đi từ đầu và việc pull phải thực hiện thường xuyên, nếu commit quá xa sẽ dẫn tới time resolver rất lớn, thậm trí sai 1 bước nào đó lấy k đúng bên thì có thể phải làm lại từ đầu.
A có chia sẻ gì cho những case đó không chứ e trải qua rất nhiều dự án lớn nhưng e thấy xấu tý nhưng đỡ take time. :d
Cảm ơn em. Team em lớn quá. Công nhận... hoa văn vậy đó
@@anonystick Bác vận hành như nào mà team lớn vẫn keep được history thẳng băng thì sẻ e với ạ. e thì hết cách r ạ
Minh cung dong y kien. Da tung lam ca 2 rebase voi merge. Nhung cuoi cung phai bo ko lam rebase nua, moi lan rebase phai resolve conflict qua nhieu, qua cuc, va qua ton thoi gian. Co the se phai fix mot loi conflict lam nhieu lan, repeatedly....
Theo mình thấy thì nên nói rõ ra chứ thực tế nhánh dev và nhánh master đều ở chế độ protect chỉ có quản lý mới đẩy lên được thôi, viết thế này nhiều bạn lại tưởng push lên 2 nhánh đó thoải mái lại toang!
Ngoài ra khái niệm rebase hiểu đơn giản là biến commit của nhánh khác thành commit nhánh hiện tại (rebase nghĩa là chuyển cơ sở), bản chất là nó biến commit của nhánh cần merge thành commit của nhánh được merge (nghĩa là commit rebase sẽ được bê nguyên nội dung và snapshot sang nhánh mới nên trên tree log sẽ là 1 đường thẳng và các commit này đều bị thay đổi SHA dù giống nội dung và snap shot).
Còn git merge là thực hiện merge bình thường tuy nhiên commit vẫn giữ nguyên SHA không thay đổi và cây git sẽ hiển thị không còn là đường thẳng nữa, ngoài ra git merge còn tạo ra 1 commit gọi là commit merge.
ngắn gọn nhưng dễ hiểu, cảm ơn bạn đã chia sẻ
Cám ơn bạn
cực kì hay bạn ơi, cảm ơn bạn
1 casi comment nay gia tri hon cai video dai 40p kia hang chuc lan
Vậy tác dụng của rebase chỉ là nhìn log commit thẳng hơn?
hồi sáng vừa có người hỏi câu này, về có ngay video của anh xem rất dễ hiểu và cuốn, cảm ơn anh
Rõ ràng dễ hiểu A ơi. Hóng A ra thêm phần check-pick trên mỗi version
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.
hôm trước phỏng vấn fresher, em có gặp câu hỏi khi nào dùng merge khi nào dùng rebase. video giải thích dễ hiểu quá.
Tks em
Fresher h hỏi rộng vậy bác :((
Đi làm một năm rồi giờ mới để ý đến cái này, cảm ơn sếp
Cảm ơn em. Cố lên.
Cảm ơn anh đã chia sẻ.
em đã xem cả 2 phần và học được nhiều điều mới.
Còn phần nữa nhé. Những tình huống gay cấn khi sử dụng Git trong team. Nhớ bấm chuông hen.
300 views và >40 likes, tỉ lệ hơn 10%, content quá sức chất lượng, làm demo vô cùng có tâm. Chúc kênh phát triển vù vù ra thêm nhiều video tutorial cho coder chúng e ạ
Cảm ơn Linh. Tôi sẽ cố gắng hơn trong việc đưa ra những tips cho anh em.
Thực sự quan trọng và cần thiết❤
Tôi không đồng ý với những gì bạn nói, nhưng tôi sẽ đánh đổi cuộc đời để bảo vệ quyền được nói của bạn
tuyệt vời quá anh! cảm ơn anh nhiều!!
Sau khi coi a giảng thì thấy trước giờ mình làm GIT tầm bậy quá :(. Cảm ơn a nhiều lắm
Tks em!
topic này em cũng đang thắc mắc, team em hiện tại ch ai đụng tới thằng git rebase, gắn cờ để mai xem, cảm ơn anh
Nhỏ thì dùng merge cũng được Khang!
Em góp ý chút, thầy có thể để 40% màn hình bên phải dành cho web, graph, GUI kết quả... chỉ cần 60% bên trái code ( IDE ) là được ạ. Khi đó user sẽ xem được cả code và GUI kết quả, mô tả...
Thank anh, rất hữu ích
Ok em!
Hay quá, tks anh đã chia sẽ.
rất hay và dễ hiểu cơ mà anh nói chậm quá ( hoặc cố tình làm video chậm lại ) toàn phải setting speed 2x :3
Vậy hử, để anh chỉnh lại. Tks em
Anh giảng bày hay lắm, cảm ơn anh. Nhân tiện cho em hỏi anh xài theme gì thế ạ. Màu đẹp quá
😁
Cobalt2, nếu muốn nhiều tiện ích xem video này em nhé. th-cam.com/video/Ujyal1dzCms/w-d-xo.html
@@anonystick , em cảm ơn anh ạ.
Thầy giảg hay quá, nhưng Tội Gạo quá =]
Thầy không có khóa dạy online , tiếc thật. Em muốn học quá !
Không bạn! Nếu bạn cần gì vui lòng pm qua fan fb.
Cảm ơn a vì video hữu ích này < 3. Tiện thể cho em hỏi ở phút 29:13 a sử dụng extension nào mà nó gợi ý mấy cai branch của git v ạ.
Fig nha em
Quá tuyệt vời ạ
Anh có thể hướng dẫn cách move các file tại repo A vào repo B mà vẫn lưu được lịch sử commit của repo A được không ạ.
Em thấy ở VN hầu như chưa ai dạy Nestjs cả. Sau này a có tính ra seri về Nestjs ko ạ
Một ý tưởng mới hen?
chào bác, nếu rebase ở nhánh feature branch, thì khi tạo pull request vào nhánh dev hay nhánh master hình như nó vẫn có commit merge ?
Dự án e h đang dùng rebase nhưng việc resolve conf từng commit cực quá. Do đó tl bảo bọn e phải gộp commit lại r mới rebase nhưng thế lại mất đi lịch sử commit, khiến cho việc trace commit khá khó và commit k rõ ràng. A có ý kiến gì về vấn đề này k ạ.
Anh cho em hỏi là làm sao để terminal gợi ý được các git command vậy ạ
Em dùng Fig nha em
@@anonystick dạ em cảm ơn anh
quá hay anh ạ
cho em xin tên tool ạ
a ơi cho e hỏi với ạ. Có phải quy định là Mt4 phải create trước T5 ko a, vậy trong dự án thực tế thì bắt buộc team dev phải tạo branch, commit rồi T5 mới commit hay sao vậy a
Không bạn. Tác giả chỉ ví dụ để xem lịch sử commit thôi. Chứ ko quy định. Quan trọng dùng rebase thì những cái commit của mình lên top, dễ quản lý
@@tipsmooc thanks bạn ạ. Mình thấy có đoạn a nhấn mạnh về cái thời gian commit nên mình ko rõ chỗ này lâm đó
@@hautran7559 sau video này mình thấy rõ ràng hơn vè rebase.
Đúng rồi, sao cũng được ko nhất thiết T5 phải trước.. Đó là một ví dụ thôi.
cảm ơn a
anh cho em hỏi là anh dùng extension gì mà gợi ý các câu lệnh git như trong video được không ạ
Fig nha em!
@@anonystick em tim o visual nhiều fig quá , anh có thể cụ thể được không ạ, em cảm ơn anh rất nhiều
@@nviethoang98 fig.io/ nha em!
Sao chưa push mà th branch messi lại có mấy file của cr7 nhỉ
Dạ em cảm ơn anh. Nhưng đoạn git rebase --contionue xong sửa commit rồi ấn nút gì để nhập wq! để thoát ra khỏi màn hình git rebase --continue ạ
ctrl + O -> Enter xong đấy gõ wq! -> Enter
25:30
anh cho em hỏi tại sao khi master đã có nhiều commit mà các nhánh khác rebase từ master và resolved conflict hết rồi push lên lại báo phải rebase hoặc merge? lúc đó thì buộc phải dùng force push để push lên mới được.
Giống t
Cho em hỏi, việc dùng Rebase hình như những leadteam, có quyền merge mới dùng rebase đúng k ạ? còn team member làm task bình thường thì dùng merge thôi đúng k ạ?
Không! Ai cũng có thể dùng, tối ưu hóa cá nhân mà. Nhưng team chỉ merge từ dev, chứ master thì đúng như em nói, chỉ có một vài người có quyền mà thôi. Và cũng chính những người đó tạo branch hotfix từ master. Xem lại phần 1 nếu em chưa hiểu về gitflow hén.
@@anonystick dạ vâng. Thực tế, trong lúc làm việc, em chỉ pull dev về tạo branch, rồi push lên, xong pull dev về nếu cần code mới nhất. Trong lúc ấy em chưa hình dung mình cần rebase ở chỗ nào? anh có thể nói qua không ạ, và em cảm thấy em k cần dùng rebase để tạo một nhánh đẹp ở local, vì ở repo mới cần một nhánh đẹp để dễ quản lý nên dùng rebase.
@@hoanglongpham5907 Đúng, anh có nói trong fb cũng như youtube. Không nhất thiết sử dụng rebase nhưng hãy làm làm theo quy chuẩn là tốt nhất. Đó là lí do vì sao vẫn còn tranh cãi. Nếu đang tốt thì không nhất thiết phải thay đổi. Chỉ thay đổi khi nó không còn phù hợp với em và xu thế.
@@hoanglongpham5907 bạn không cần dùng rebase cũng vẫn làm việc bình thường được nhé. Cái lợi của dùng rebase: kiểm soát conflict tốt hơn, và không có 1 commit thừa (kiểu như commit merge từ nhánh master về nhánh feature) thì trông commit nó đẹp hơn. Không dùng nó cũng chả sao bạn nhé
@@hoanglongpham5907 và Rebase chỉ dành cho các nhánh phụ nhé, lead team thì dùng nhánh chính. Nhánh chính "không bao giờ" dùng rebase nhé
Em có 1 nhánh feature nó clone từ nhánh Dev ra, và nhánh Dev đc merge vào những feature khác liên tục, trong khi nhánh feature lại ko có thay đổi gì trừ những phần dev cho feature, và giờ em rebase nhánh Dev về nhánh feature thì thấy nó nhiều commit vô cùng, và em muốn squash hết mớ commit đó thành 1 để cho gọn, push lên cho đẹp thì mình làm sao ạ.
reset soft về head của nhánh dev rồi phần changes lưu vào stash -> rebase nhánh dev -> apply stash changes vừa lưu -> commit and push. giờ PR chỉ có 1 commit
A là fan CR7 hay M10 vậy vậy:D
CR7 nha, còn em?
@@anonystick sr a e fan a Si
23:31