1 giờ pull code 1 lần thì rát thiệt chứ.. team đông lắm mới cần thế. Chứ tui nghĩ tầm 1 ngày update 2 lần , đầu ngày và cuối ngày là ổn
chia task sao cho mỗi thằng 1 chức năng đỡ dính nhau còn update code thì mỗi ngày 1 lần vào đầu ngày thôi cũng dc , quan trọng lúc có pull request biết chắc là sẽ bị vưới thằng kahcs
Nếu đã làm riêng từng PR rồi mà vẫn phải pull liên tục thế thì không ổn lắm nhỉ, như vậy thì depend nhau quá nhiều, quất cha chung 1 nhánh rồi mn commit - pull rebase - push liên tục cho rồi, đằng nào chả phải cập nhập liên tục, lock force push lại, giờ nó muốn push thì phải resolve conflic thôi . Còn đã chia mỗi đứa 1 PR thì phải hạn chế liên quan nhất có thể.
Pull mỗi ngày 1-2 lần là đc rồi, chứ mỗi tiếng thì 1 là structure codebase có vần đề, 2 là chia task có vấn đề
há há, 1 trong những câu hỏi phỏng vấn ưa thích của mềnh là chiến lược merge code mà bạn thường dùng khi làm việc với team là gì thường thì đã chia microservice ở backend rồi thì trong 1 sprint mỗi thằng 1 task liên quan đến 1 service thì ko lo bị conflict. Chỉ có thằng frontend là 2,3 thằng cùng chui vào để thêm sửa xoá. Thằng nào mà nghịch vào đống common component thì đúng là ối dồi ôi, cuối sprint chỉ có đi resolve conflict. Tiện đây hỏi ae chiến lược CI/CD mà mọi người đang thực hiện. Bên mình thì có 3 môi trường: local (máy của mỗi dev) / staging (môi trường dev deploy tính năng để qc test) / prod (môi trường khách hàng sử dụng). Repo thì có 2 nhánh quan trọng là dev và master, tương ứng với 2 môi trường staging và prod. Flow bên mình là như thế này: - Đầu sprint, sau khi nhận task thì dev sẽ checkout 1 nhánh feature mới từ branch dev của repo frontend, đặt tên theo template feature/PROJECT_TASK_ID-short-description, ví dụ: feature/JIRA-369-login-form (gọi là feature-A), tương tự thằng dev khác trong team sẽ có 1 nhánh khác là feature-B. Các dev code trên nhánh của mình ở môi trường local của mỗi dev - A xong trước thì A sẽ thực hiện việc tạo pull request vào nhánh dev, leader approve và merge thì sẽ tự động được build và deploy trên môi trường staging để QC test. - B xong sau thì sẽ thực hiện như sau ở môi trường local: git checkout dev // chuyển sang nhánh dev git pull origin dev // lấy code mới nhất về (đã merge feature-A) git checkout -b deploy/feature-B // tạo nhánh mới từ dev git merge feature-B // merge feature-B vào nhánh vừa tạo -> resolve conflict git push --set-upstream origin deploy/feature-B // push tạo nhánh mới trên repo tạo pull request merge deploy/feature-B vào lại nhánh dev, leader approve và merge để build lại trên staging. Sau đó QC sẽ vào test
phương án trên giải quyết việc mọi pull request đều ko có conflict, thằng leader chỉ việc review logic, convention và merge. Oái oăm nảy sinh khi mà QC test xong rồi đến phần fix bug, A và B tiếp tục sửa trên nhánh feature của bọn nó. Cái dở ở chỗ, có những lúc bug nó lại phát sinh khi 2 bên đã merge và resolve conflict dev ở A QC test ở (A -> dev) ra bug -> quay lại A tái hiện được bug -> fix tiếp được dev ở B test ở B -> (A -> dev) ra bug -> quay lại B để fix ko thấy bug xuất hiện .
Cái này thì là git feature branch workflow, cộng đồng nó đã ra đưa ra tiêu chuẩn chắc cũng phải chục năm rồi. Đa số chỗ mình đã làm thì đều làm theo vậy nhưng trường hợp code base viettel của bạn kia thì mình nghĩ là áp dụng cũng không giảm được conflict vì nghi là có mấy cái như sau: toàn bộ model vứt vào một file, service với các module không chia rõ ràng vứt lung ta lung tung gộp chung vào file mấy chục nghìn dòng code nên người mới không biết code vào đâu còn người cũ thì thấy nó cũng quá to nên cũng lười để sửa thành ra cũng vứt lung tung nên sửa phát tỉ lệ đá nhau chan chát cao vcl
Phần bôi đậm : sao ko merge/rebase trực tiếp vào branch feature-B luôn mà tạo ra branch phụ mần gì nhỉ ? Nhiều branch quá lại rối thêm, git thì cứ simple thôi Git scenario thì cứ follow theo common git flow thôi. Chỉ cần nhấn mạnh với dev là bắt buộc phải merge/rebase + resolve conflict trước khi push và tạo PR
Chia module nhỏ ra mà code, ez. Thời đại nào rồi mà phải check tay. Setup CI auto test, pass được thằng máy rồi mới cần người review lại. Trừ khi refactor lại core thôi
nếu rebase/merge nhánh (dev+A) vào nhánh B thì thằng B sẽ mang cả code của thằng A -> code này có thể còn lỗi, nếu đến lúc cần merge thằng B vào master để lên product thì lại phải cherry pick
Nguyên tắc khi merge vào dev thì source code ở branch feature-A ít nhất phải chạy được (không chạy đc mà merge thì do ông review rồi) . Nếu có lỗi thì lại fix bằng 1 branch khác . Còn theo ý của fen thì chờ cho A chắc chắn hết lỗi mới xài code của A sao Theo mô hình như fen đang làm thì sẽ có case code ở 2 branch deploy/feature-B và feature-B nó không đồng bộ với nhau .. lúc đó thì tha hồ mà compare á
Flow của a mà dính quả 1 trong 2 feature lùi lại sprint sau, cái còn lại thì đẩy prod là mệt đấy, staging (dev) đã dính code của 2 feature nên ko đẩy lên prod (main) đc, trc e quả này, sát ngày deploy thì PO bảo dời 1 feature, thế là phải tạo staging_A từ revision lúc đầu sprint, merge A, bỏ B rồi test lại 1 lượt, xong xóa mẹ staging hiện tại, base mới staging_A sang dev, lúc base trứng cút lô tô vkl. À phỏng vấn git phần rebase cũng vui phết, hỏi có nên dùng rebase cho branch nhiều ng code chung là biết ngay có quen dùng git hay ko
