Chào mọi người, em đang đi thực tập và có thắc mắc về trường hợp khi làm việc với git, nhờ mọi người giải đáp giúp em với ạ.
Em đã làm 1 tính năng trên branch X, leader đã test và sau đó merge branch X vào master, bây giờ anh leader nói e sửa lại 1 số thứ. Hiện tại thì trên master cũng đã có thêm vài commit khác (em cần những commit này để tiếp tục code tính năng hiện tại), vậy em nên lấy branch X để tiếp tục làm, hay là nên tạo 1 branch mới để làm nhỉ.
Ở trường hơp lấy branch X làm tiếp thì e phải xử lý lấy những commit mới vào branch X để tiếp tục code, em nghĩ sẽ dùng cherry pick, không biết như vậy có đúng ko ạ.
Còn nếu ở trường hợp tạo branch mới làm thì sẽ dễ dàng hơn nhưng e sợ nó sẽ kiểu bị trùng lặp do mình tiếp tục làm tính năng cũ nhưng lại tạo branch mới. Không biết suy nghĩ này của em có đúng ko.
Vì anh leader đang khá bận với dự án nên ảnh nói em tự tìm hiểu phần này, mong mọi người hướng dẫn em với ạ, em xin cảm ơn mọi người.
Thắc mắc về quy trình làm việc với git
Cả 2 cách đều được.
Nếu bạn tiếp tục dùng nhánh X (code đang cũ so với nhánh master) thì bạn dùng merge fast forward từ nhánh master về nhánh X của bạn và code tiếp trên nhánh X
Còn nếu base nhánh mới từ master ra nhánh Y chẳng hạn rồi code tiếp thôi, sau tạo pull request nó sẽ merge vào master. Trong trường hợp local đang có code đang code dở nhánh X mà muốn có thêm chức năng mới từ master thì dùng rebase về local, tạo nhánh mới và code tiếp.
Cherry pick mình thấy dùng trong trường hợp này không hợp cho lắm mặc dù vẫn được (nó khiến cho git log bị rối)
Mình hay dùng cherry pick khi mà cùng một feature trên nhánh của bạn mà muốn lên cả 2 môi trường develop và staging chẳng hạn khi này sẽ dùng nó để đảm bảo 2 pull request nó không ảnh hưởng đến nhau trong quá trình review, môi trường nào cần deploy thì merge feature đó trước.
Nếu tớ là cậu:
- Tớ sẽ thử đọc các ticket/Pull request trước xem họ xử lý sao với TH tương tự.
Cậu nên theo quy trình của team cậu để tránh nhập nhằng. Khi có vấn đề gì, cậu có lý do chính đáng “em làm theo Pull request này ạ” để giải thích cho quyết định của cậu. - Tớ cũng sẽ đưa 2 phương án này thảo luận với các thành viên lâu năm khác hoặc/và leader.
Việc của cậu chỉ cần trình bày 2 phương án, đưa ra suy nghĩ cậu sẽ chọn phương án nào, với lý do gì, và hỏi feedback của mọi người một cách cầu thị.
Việc thảo luận này rất lành mạnh, không tốn quá nhiều thời gian (so với việc cậu làm bừa theo ý cậu và chẳng may phải sửa lại), cũng như giúp cậu có một giải pháp vững chắc.
Có một số điều nho nhỏ tớ sẽ đề cập dưới đây, mục đích để cậu có thêm hiểu biết khi làm việc trong industry:
- Thông thường, khi code của cậu đã được test và merge vào nhánh master, task của cậu đã được tính là hoàn thành.
Vậy nên, nếu có bất cứ cải tiến/fix bug nào trên tính năng đó, đó nên là task hoàn toàn mới. Cậu nên tạo ticket riêng cho task đó, link tới task cũ nếu cần thiết, cùng với nhánh code mới + Pull request mới cho task này. Nếu không, cậu sẽ chỉ tốn thời gian vào task không tên nào đó.
Việc này cũng giúp cậu và cấp trên của cậu quản lý công việc hiệu quả hơn. Ngoài ra, cậu không nên lôi một nhánh implement 1 tính năng từ 1 năm trước dậy, cherry pick commit/merge nhánh master sang và code tiếp, đúng không?
- Ở vị trí của cậu, khi ai đó nói “tự tìm hiểu phần này”, khả năng cao cậu nên hiểu là “tự tìm hiểu, rồi propose solution cho tôi trước khi làm”.
Đừng liều mình làm bậy nếu như cậu không có lý do chắc chắn nha Khả năng cao cậu sẽ phải làm lại đấy. - Cậu cần để ý kỹ quy trình làm việc của cả team và làm theo. Đôi khi, một số team biến tấu git flow để phù hợp với team đó, nên cậu chú ý nhé!
Hope it helps!
Chuẩn rùi đó, cách thì nhiều nhưng theo team thôi.
Cẩn thận bị đồng bọn chửi sml vì merge code mất code của người khác.
Thà mất code của mình còn hơn là mất code của người khác mà mình không biết và nhắm mắt merge là chắc ra đảo haha
Merge rôì thì tạo nhánh mới từ main chứ. thông thường merge là delete branch luôn rồi. Còn
chưa merge thì rebase từ main về. hoăc cho phép pulll thì pulll từ main về nhánh mình
câu hỏi rất hợp lý
-
cách dễ và chắc ăn nhất là tách ra branch X’ như bạn đã nghĩ ra
-
bạn vẫn có thể tiếp tục commit vào branch X mà không cần phải lấy gì về cả, sau khi bạn commit những sửa đổi xong, bạn tiếp tục tạo pull request vào master mà thôi
khi đó, pull request đó chỉ bao gồm những thay đổi của bạn, bạn chỉ việc xử lý những chỗ bị conflict
lý do bị conflict là do bạn và người khác cùng sửa một chỗ
nếu file bạn không sửa file a,
người khác sửa file a và đã merge vào master
lúc này branch X của bạn, file a vẫn là cũ, còn file a trên master đã mới hơn
bạn lo lắng khi merge X vào master thì file a của 2 branch khác nhau, nên được tính là khác và sẽ merge vào khiến file a trên X merge vào lại master sẽ làm cho file a sẽ bị trở lại như cũ?
đừng lo, thay đổi được tính dựa trên những thay đổi mới của bạn, những gì bạn không đụng tới, khi tạo pull request thì sẽ được hiểu là không có update
nếu bạn có sửa file a trên branch X, người khác cũng đã sửa file a và merge vào master, lúc này tạo pull request
lúc này git mới xem xét, nếu chỗ bạn sửa, không liên quan tới chỗ người kia sửa (bạn sửa dòng 1, người kia sửa dòng 100, không liên quan gì nhau) thì git sẽ lấy thay đổi của bạn merge vào master
dòng 100 vẫn là mới, chỉ có update dòng 1 mà thôi (fast forward)
nếu bạn và người kia sửa bị xung đột, git sẽ báo
lúc này, bạn cần merge master ngược vào X (A merge vào B cũng giống như B merge vào A, chỉ khác ở chỗ commit nó nằm ở bên được merge vào)
hiển nhiên nó đã báo confict thì bạn merge master vào X sẽ bị báo conflict, bạn resolve xong thì commit thêm một phần nữa
sau đó bạn merge X vào master sẽ không bị confliect nữa (origin cùng hash với nhau)
- một cách khác để tránh việc lằng nhằng của cách 2, là bạn merge ngược master vào X ngay từ đầu (không bị conflict đâu, vì version của master đã bao gồm nhánh X) để cho origin X bằng origin của master
khi đó X với master là một (tạo thời điểm được merge ngược lại) bạn tiếp tục code trên X, xong thì merge master thôi
@ Ntech Developers @ La biblioteca @ Nguyen Ca @ Tên Gì Cũng Được cảm ơn tất cả mọi người, qua lời giải thích của mọi người em đã hiểu được vấn đề. Hiện tại e đã làm theo cách tạo branch mới để làm, vì nó sẽ rõ ràng minh bạch hơn. Cảm ơn mọi người rất nhiều, mọi người nhiệt tình quá 
em chưa hiểu chỗ này lắm, anh cho em hỏi là mình sẽ đứng ở branch nào để pull --rebase vậy a, do em suy nghĩ là nếu đứng ở branch master để pull --rebase thì nó sẽ ko có những commit mình đang làm dang dở của branch X, còn nếu đứng ở branch X để pull --rebase thì sẽ ko có update nào vì origin/X ko có commit nào mới.
Mình nghĩ nên tạo nhánh mới từ commit mới nhất ở nhánh chính thì ít thao tác nhất, làm xong thì merge lại vào nhánh chính.
Mình giải thích thêm cái rebase này.
Bạn đang ở nhánh X, đã merge feature X lên master, trên master có feature Y
Trên local bạn là nhánh X nhưng đang code dở (mới commit lên chứ chưa push code), khi này trạng thái local của bạn sẽ là X’
Bạn chưa muốn tạo pull request cho feature X + X’ này, nhưng vẫn muốn code mới nhất từ master chưa feature Y về gộp chung với phần X + X’ của bạn.
Khi này bạn dùng rebase nhánh master về local của bạn và merge chung với phần X + X’ kia
Cách sắp xếp rebase nó sẽ ưu tiên code trên master chứa feature Y kia, sau đó gắn thêm code hiện tại của bạn, khi này luôn đảm bảo không mất code của người khác mà lại tiếp tục thực hiện code X’ của bạn đến khi hoàn thành xong hết rồi tao pull request 1 thể.
Hi vọng cách giải thích này có thể giúp bạn hiểu rõ hơn.
Dạ vâng, em cảm ơn anh, vậy nếu trong trường hợp đó e sẽ làm theo những command dưới đây vậy có đúng ko ạ
git checkout master
git pull --rebase
git checkout X
git merge master
Cái này thì chưa đúng lắm. Nguyên nhân là do trước khi rebase phải thực hiện commit code đang chưa stage lên local đã rồi mới switch nhánh rebase => đảm bảo code của mình không mất nếu có conflict.
Sau khi rebase xong thì phải merge master vào nhánh X hiện tại, tiếp tục làm gì thì làm cho đến khi hoàn thành tạo pull request.
Lưu ý quan trong nhất là KHÔNG merge trực tiếp bất cứ thứ gì vào nhánh master, mà phải thông qua pull request và được review.
Thông thường team lead sẽ setup protected nhánh master để chặn mọi thứ push trực tiếp vào thì mới có thể quản lý và review code không bị sót được.
Làm một hai lần sẽ quen thôi.
Mình hay dùng Git UI nên cũng không nhớ chính xác command line cụ thể của git. Mình chỉ mô tả flow giúp bạn thôi, có thể bạn sẽ search thêm command line nếu muốn nhé!
P/s: Mình thường dùng smart git và source tree.
git checkout master
git pull --rebase --> này ko phải rebase, này lấy latest của master repo về master local
git checkout X
git merge master -> Có thể dùng nhưng những dự án lớn, nhiều team ko khuyên dùng. khó trace log.
nên dùng cách này:
git checkout X
git rebase master -> commit của mình sẽ nằm trên cùng (linear history). dễ đọc log
chú ý khi rebase conflict có thể xảy ra. phải resolve từng lần một rồi tiếp tục rebase, cho đến khi success , ok hết rồi thì git push hoặc git push --force
nếu bạn đang sử dụng vscode, mình recommend extension này git graph
sau mỗi lệnh git, bạn có thể xem sự thay đổi của cây git, sẽ trực quan hơn
Qua lời giải thích của mọi người em đã hiểu hơn để giải quyết vấn đề của em rồi ạ, một lần nữa cảm ơn tất cả mọi người, mọi người trả lời nhiệt tình thật, em rất quý trọng những giúp đỡ của mọi người.
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?