Mình tay nhỏ. Kinh nghiệm cá nhân.Bám theo work flow làm là đỡ nhất. Vài rule cơ bản: 1 task 1 branch, branch trước khi checkout -b, cần đc pull code về, rebase khi cần, 1 task 1 commit, message, tittle, décription viết ngắn gọn, đủ ý.
cho em hỏi , giả sử thằng A push code mới lên mà task của mình đang cần dùng code ý với đang ở branch khác thì mình lại git checkout -b tiếp ạ^ git reflog đc mà. Nhớ backup lại là đc. Checkout -b hoặc push lên remote cũng ổn
Em thấy đối với newbie, copy folder là dễ nhất trong đám này.^ git reflog đc mà. Nhớ backup lại là đc. Checkout -b hoặc push lên remote cũng ổn
Merge branch nó vào branch mình.cho em hỏi , giả sử thằng A push code mới lên mà task của mình đang cần dùng code ý với đang ở branch khác thì mình lại git checkout -b tiếp ạ
Cos thể mẻger hoặc rebase branch code của nó về mình. Mà thật tế nó đẩy lên nhánh chính kéo về chứ ai éo kiểu đó.cho em hỏi , giả sử thằng A push code mới lên mà task của mình đang cần dùng code ý với đang ở branch khác thì mình lại git checkout -b tiếp ạ
cherry-pick hoặc merge, rebase tùy tình hình,cho em hỏi , giả sử thằng A push code mới lên mà task của mình đang cần dùng code ý với đang ở branch khác thì mình lại git checkout -b tiếp ạ
thường thì sẽ đợi nó đc merge vô nhánh chính kiểu development hay staging gì đó ... sau đó mình sẽ merge hoặc rebase tuỳ theo b ... chứ đừng merge hay rebase từ nhánh b đang cần code ... làm v thì cũng đc nhưng nó k đúng lắm đâu vì biết đâu code nó k đc merge hay s đó thì phải đi revert hoặc reset ~~ khá oải đấycho em hỏi , giả sử thằng A push code mới lên mà task của mình đang cần dùng code ý với đang ở branch khác thì mình lại git checkout -b tiếp ạ
Thím nói sơ qua các tình hình nên chọn được kocherry-pick hoặc merge, rebase tùy tình hình,
git stash để lưu tạm công việc , pull rebase code của thằng kia về nhánh dev - > rồi sau đó rebase từ Dev về nhánh đang làm -> lấy stash ra làm tiếpcho em hỏi , giả sử thằng A push code mới lên mà task của mình đang cần dùng code ý với đang ở branch khác thì mình lại git checkout -b tiếp ạ
Ví dụ như code của nó ở branch AThím nói sơ qua các tình hình nên chọn được ko
rebase -i branch A, để 3 commit đó xuống dưới cùng.Ví dụ như code của nó ở branch A
Và branch A đó đang có 3 commit mới so với master.
Bạn chỉ muốn lấy 1 commit trong đó ra để phục vụ cho code của mình, thì bạn dùng cherry-pick.
(với điều kiện là commit được cherry-pick độc lập vs 2 commit còn lại)
Nếu 3 commit đó kiểu liên quan tới nhau, ví dụ bạn cần commit thứ 3, và commit thứ 3 có sử dụng code của 2 commit đầu, thì lúc này cherry-pick cả 3 commit thì hơi mất công, nên sử dụng rebase hoặc merge.
Nếu muốn log git đẹp, và dễ review. Có thểrebase -ibranch A, để 3 commit đó xuống dưới cùng.
Sau đó mình có thể gộp lại bằng squash với tên commit là "NO_REVIEW" chẳng hạn, (NO_REVIEW tức là code này ko phải của t, m ko cần review nó trong pull request của tao, tao chỉ đi sử dụng lại)
Cá nhân mình thì không thích sử dụng merge khi 1 feature đó vẫn chưa hoàn thiện, vì merge xong, sau lại có commit fixup khác nữa, merge tiếp, lúc đó nhìn cái log ngứa mắt.
Theo mình 1 là cherry-pick trước xong squashBác nói đúng case của em khi đung cherry-pick lun. Hồi trước em có bị case này. Lúc đó phải chery cả 3 cái commit liên quan lun.
Mà có cách nào squash lại rồi cherry-pick cái squash đó k nhỉ?
Sent from Vsmart Active 3 using vozFApp
