Khi làm dự án phần mềm, việc nhiều người cùng edit chung 1 file và sử dụng các tool version control để quản lý các phiên bản gần như là không thể tránh khỏi, git và các ứng dụng mở rộng của nó (github/gitlab/bitbucket) đang hầu như thống trị tuyệt đối mảng này. Mặc dù là 1 công cụ rất mạnh được sinh ra để giải quyết vấn đề, nhưng nếu cách sử dụng không đúng, thì việc sử dụng git lại có thể gây ra rất nhiều vấn đề 😄 có nhiều best practice có thể áp dụng để tránh giẫm chân nhau, nổi tiếng nhất có thể kể đến git-flow của bác Vincent Driessen, mà sau đó Github và Gitlab chế lại của bác ấy thành Github Flow và GitLab Flow Bên dưới là 1 trong những cách như vậy, cái này lấy ý tưởng từ git-flow, và điều chỉnh một chút cho phù hợp với quy trình ở công ty mình đang làm việc, hy vọng giúp ích cho các bạn Pre-conditionĐã có khái niệm cơ bản về version control và git Target audienceAll member trong dự án dự định sử dụng Git, hoặc đang áp dụng Git và thấy nó "chẳng khác gì xx" Giả địnhDự án có áp dụng các môi trường theo mô hình tương tự như thế này: Trong đó - Test environment là môi trường của team tester nội bộ
- Staging environment là môi trường cho khách hàng nghiệm thu
- Production environment là môi trường vận hành
Core Idea
- nhánh
master CHỈ chứa source production, nói cách khác, tất cả các phiên bản trong nhánh master phải là deployable nghĩa là khi có chuyện xảy ra với phiên-bản-vừa-được-deploy, bạn chỉ đơn giản là nhảy-lui 1 version và re-deploy - nhánh
staging chứa source chờ nghiệm thu (*) - nhánh
testing chứa source đang được tester chạy test - nhánh
develop chứa source ngon đang chờ dồn 1 cục rồi đưa lên testing - mỗi members push code hàng ngày vào
feature/{username}/{id}-feature-name hoặc `git`0 - nhánh `git`1 chỉ để xử lý bug production "thực-sự-hot" và nên do người chuyên trách hoặc người có trách nhiệm cao nhất về code trong dự án xử lý, tránh các lỗi bất cẩn không đáng có.
Nguyên tắc
- KHÔNG BAO GIỜ
git`2 vào `master
trong master chỉ chứa source được merge.
note: để phòng tránh việc này, gitlab nó default protect luôn cái branch master và chỉ cho maintainer push vào, trong các dự án lớn, thì chỉ set PM + CM(*) là `git`5, còn members bình thường thì quyền `git`6 là ổn. - tag trong master thì phải tương ứng với `git`7
- `git`8 trong các branch thì tùy ý, thích đặt sao thì đặt, nhưng nên có convention thống nhất trong dự án
git`8 có thể là `git-flow`0, `git-flow`1... hoặc `git-flow`2, `git-flow`3... tùy miễn khi khách bảo "tôi phát hiện một cái lỗi trong phiên bản xx\ thì các bạn biết được rằng cái lỗi đó phát sinh ở đâu mà fix, vì có những lúc, như ví dụ trong hình dưới của tôi, lúc tôi đã deliver v4.0 thì khách lại bảo "cái 4.0 tao chưa nghiệm thu đâu, nhưng lúc check source của cái 2.0 thì tao thấy 1 bug" 😑
- LUÔN LUÔN
git-flow`4 source từ `develop vào branch của mình và xử lý conflict trước khi tạo merge request
merge request tùy tiện rồi lòi ra 1 đống conflict rồi bị CM chửi thì đừng hỏi tại sao 😅
Tag convention
- phiên bản để gửi cho tester test, thì nằm trong nhánh
testing và có tag name là `git-flow`7, ví dụ `git-flow`8 hoặc `git-flow`9, thường thì đánh version kiểu `master`0 nhìn nó "chuyên nghiệp" hơn, đồng thời có ý nghĩa hơn - phiên bản để gửi cho khách hàng nghiệm thu (trong trường hợp dự án có môi trường
staging) nên có tag name là `master`2, ví dụ: `master`3 - phiên bản để gửi lên môi trường production, nằm trong nhánh
master và có tag name là `master`5, ví dụ: `master`6
mấy cái convention này nếu như dự án nào áp dụng CI/CD thì có thể dùng để trigger build node / intergration node chạy luôn, tuy nhiên đấy là câu chuyện khác không nằm trong scope của post này Customize
Dự án 1 ngườiTrong một số dự án siêu nhỏ & đơn giản, ví dụ như "dự án 1 người" thì bạn cũng có thể trực tiếp push vào master cho đỡ việc, tuy nhiên việc gắn tag name thì nên tuân thủ convention trên, ít nhất là có 2 tag: master`3 và `master`6 được gắn cùng vào 1 `master`9 trên `master nếu như khi gửi UAT và release và khách hàng confirm "không có lỗi gì" không có testerĐôi khi, trong một số công ty nhỏ, làm app nội bộ, "khách hàng" lúc này đồng thời là tester, vậy thì có khi cũng không cần phải tạo thêm nhánh develop & testing gì cho rách việc, chỉ cần master`3, `staging, master là OK đương nhiên, nếu làm chuẩn và sử dụng hotkey/script tinh tế, thì cho dù có đủ 4 branch, bạn vẫn không tốn quá nhiều công sức cho các thao tác này, mà việc control 1 bộ source ngăn nắp sẽ giúp bạn tiết kiệm effort hơn nhiều | 
