Thì branch chung ai dám rebase Rule của rebase nó nói rõ luôn mà Nên vẫn xài merge khi cần merge vào branch chung đó
Dùng vì thích thôi fen Cái nào tiện với quen tay thì làm Chứ suốt ngày chạy theo mấy caí best practice với must-do thì chỉ có toang dự án
Cũng chưa bao giờ xài Rebase luôn :( Mới biết đến thằng Git GUI này qua video giới thiệu của lão Scott Chacon, co-founder Github. https://gitbutler.com/ Xem qua giới thiệu thấy khá tiện cho dân quen dùng Git GUI mà ít khi dùng Git CLI như mình :v
Trông ổn phết, trc giờ thấy git gui ngon nhất là của intellij mà kèm ide (chủ yếu xử lý conflict), dùng thử sublime merge với source tree thì k ngon lắm, để dùng thử thằng này xem. Btw dùng cli đi, dùng gui sẽ k cover hết đc mấy case bựa khi xử lý.
feat-A nhập vào dev để triển khai staging cho QC test mà, sao đảm bảo ko có lỗi đc mặc dù vẫn chạy đúng tính năng. Quy trình fix bug ở staging sẽ là: QC báo bug staging -> dev A checkout nhánh deploy/feat-A ở local, rebase lại origin/dev để đảm bảo lấy code mới nhất -> tái hiện bug ở trên nhánh feat-A -> tái hiện thành công -> merge feat-A vào deploy/feat-A rồi tạo PR merge vào dev tiếp flow như thế nên : feat-A < deploy/feat-A < dev case này gặp hoài, vì ko phải sprint nào cũng đẩy được toàn bộ các feature lên. mà chiến lược deploy prod ko phải là đẩy từ merge từ dev vào prod mà làm tương tự như merge feat vào dev ấy từ master checkout ra nhánh release/feat-A, sau đó merge feat-A vào nhánh này, resolve hết conflict rồi mới tạo PR merge nhánh release/feat-A vào master
với cái chiến lược này, nhánh dev ở staging cực kỳ hổ lốn nhưng được cái các nhánh feat rất là độc lập, ko bị dính tí ti commit nào của feat khác. Rồi đến khi merge vào master cũng đc đảm bảo là ko mang commit của feat khác lên. Còn nhánh dev, ae thống nhất, sau 2,3 sprint là revert về lại = master . Revert chứ ko phải rebase nhé :v kiểu delete đi và checkout lại từ master ấy )
Mình thấy nhánh dev bác y chang nhánh it-qc, chỉ là merge vào rồi build cho qc test, khi xong cũng merge nhánh feat vào main chứ k vào dev thế thì sao k tách cha nhánh feat từ main, khi muốn build cho qc test thì cứ merge thẳng nhánh feat vào nhánh dev luôn, tạo nhánh tạm xong làm đủ thứ chi cho cực? Xong sprint thì xóa bà nhánh dev rồi tạo lại từ main cho nhanh.
Thi thoảng vẫn phải lọ mọ search git command để fix lỗi trên ... MacOS do bọn Intellij nó drop cái AppCode r
Khi featA deploy thì đã merge với dev rồi sao không sync/push code fix lên thẳng featA local luôn mà còn tạo deploy/featA làm gì cho khổ nữa. Nhiệm vụ merge feature vào prod là của tech lead, ông ấy tự merge feature ở local master rồi đấm thẳng lên origin master cho nhanh, chứ flow của ông khác gì tự tạo PR rồi tự accept đâu Việc không đẩy dev lên master cũng sẽ làm 2 branch này càng ngày càng xa nhau, nên tốt nhất là 2 bên phải sync nhiều nhất có thể.
Cái vụ featA phải tạo thêm branch để resolve conflict là khi prod thiếu nhiều feature so với staging. Trình tự sẽ là tạo featA từ nhánh prod, code các kiểu xong rồi sẽ tạo 1 branch staging/featA từ thằng featA để pull code staging về resolve conflict trước khi merge vào staging. Còn thằng featA để lại để sau này khách hàng request thì merge vào nhánh prod thôi.
^ cái vụ pull từ prod giống flow hotfix bug. Bình thường thì bỏ công làm cái feature flag để on/off feature cho phẻ, merge prod thường xuyên. Làm kiểu trên cho feature thì lúc lên prod rất áp lực, 1 chuyến đò nhiều feat đi lên, bị sự cố khó tìm cha. Với ngâm feat ở stage thì cái definitiom of done của team là dừng ở stage à
Dod thì tùy dự án, stage chỉ để test chức năng, dev team dừng ở stage, còn prod do po với team lead xử lý. Hồi outsource cho viettel thì dod của team mình là bàn giao module, test stage ngon nghẻ (cả 2 bên qc) thì bàn giao trả tiền và thêm thời gian bảo trì fix bug phát sinh khi merge prod. Còn phải đồng bộ code và test lần cuối trên preprod trc khi bàn giao và bảo trì nữa anh ạ, trc e làm thì vụ "kh request thì merge vào prod" nó làm tồn kho ticket rất nhiều, do kh thích request lúc nào thì kêu, có ticket tận 1 năm, nên tồn kho có lúc vài chục ticket nhỏ, vài ticket lớn muốn điên cái đầu vì k bàn giao đc, bị chậm dòng tiền, sau e nghỉ outsource cho viettel cũng vì cái này. Chưa kể ba bên kia hoạch họe sửa chỗ này chỗ kia ngoài scope bực lắm. Con mẹ thằng apple, nó bỏ support xcode 14.2 đẩy app store năm ngoái làm mình chật vật lúc bàn giao vkl, đi sang kh ở hải phòng đúng lúc nó bỏ sp 14.2 trong đêm (cùng lúc macos 14 ra) làm team mình phải mua con macmini để đẩy code lên testflight. Mà chả hiểu bọn apple làm ăn kiểu gì xcode dùng ngu vkl,éo tin nổi cty ngàn đô k làm nổi cái ide ra hồn, giờ chuyển sang flutter và ci build app cloud hết, éo dùng nổi xcode. Con macbook 2015 cũng bỏ xó, vừa dùng opencore up lên macos 13 dùng thấy cũng mượt, xem kéo dài tuổi thọ đc bao lâu
DoD ở staging hợp lý với trường hợp trên, nhưng pull code từ prod để làm feat thì nói thật là ít gặp, trừ khi cái đó cần lên prod gấp, và nếu gấp thì đã không ngâm cả năm ko deploy. Làm feat thì cứ pull từ stage/dev chứ nhỉ.
