Git flow
Các bước khởi tạo và xử dụng git phù hợp với dự án của tôi và có vẻ phù hợp bạn :)
1) Tạo git repo
2) Tạo project mặc định_readme.md [mô tả tối thiểu về project cũng được]
3) Ignore list bin, obj, .suo, .vs ...
4) Thêm 3rd Libs nếu có cần dùng tới
5) Push khởi tạo lên git với branch master
Tạo sẵn branch từ master:
dev: sơ khai từ master và "như tờ giấy trắng_master", tương lai sẽ chứa toàn bộ source code test/CR/bug/hotfix/NF/improve
=> dành cho test nội bộ
stagging: sơ khai từ master và "như tờ giấy trắng_master", tương lai sẽ chứa toàn bộ source code test/CR/bug/hotfix/NF/improve ĐÃ QUA TEST NỘI BỘ VÀ CHỜ KHÁCH HÀNG UAT
=> dành cho khách hàng test
release_version: sơ khai từ master và "như tờ giấy trắng_master", trong tương lai sẽ chứa source code release sau khi nội bộ đã test và khách hàng đã UAT
(*) Dễ mà, xong bước 1 :)
Trong quá trình phát triển dự án (*) Qua thời gian:
1) sẽ có người tham gia thêm..(tốt quá, 1 mình làm sao nổi)
2) sẽ có thay đổi (change request_CR)
3) sẽ có fix bug (ohh no.. bug...)
4) sẽ có hotfix (ohh no... bug... urgent..)
5) sẽ có tính năng mới (new feature_NF_internal)
6) sẽ có tối ưu hóa (UI/UX_performance .._improve_internal)
(*) Qua thời gian:
1) thêm người
=> add/invite thành viên vô git
2) Change request và các yêu cầu 3) 4) 5) 6) có thể làm tương tự:
Giả sử có 2 CR, assign cho 2 thành viên
2.0) Thành viên 1:
_Luôn luôn pull master về local trước khi khởi tạo branch để đảm bảo source mới nhất release ở thời điểm bạn tạo branch mới (*)
1_Tạo branch CR 1 từ master_[vd branch: project_abc_cr_1]
2_=> code/sefl test
3_=> merge [project_abc_cr_1] vào branch dev [thường thì thành viên 1 tự merge]
4_=> yêu cầu tester test
5_=> tester pass
6_=> merge [project_abc_cr_1] vào branch stagging [thường thì leader merge]
7_=> yêu cầu kh test
8_=> kh pass
9_=> yêu cầu tạo mới branch release_version_CR_1 từ [project_abc_cr_1]
10_=> yêu cầu release production source code release_version_CR_1 [comment chi tiết] [thường thì leader merge]
11_=> release production xong :)
12_=> yêu cầu merge branch release_version_CR_1 vào master
13_=> merge vào master [done]
2.1) Thành viên 2:
_Luôn luôn pull master về local trước khi khởi tạo branch để đảm bảo source mới nhất release ở thời điểm bạn tạo branch mới (*)
1_Tạo branch CR 2 từ master_[vd branch: project_abc_cr_2]
2_=> code/sefl test
3_=> merge [project_abc_cr_2] vào branch dev [thường thì thành viên 2 tự merge]
4_=> yêu cầu tester test
5_=> tester pass
6_=> merge [project_abc_cr_2] vào branch stagging [thường thì leader merge]
7_=> yêu cầu kh test
8_=> kh pass
9_=> yêu cầu tạo mới branch release_version_CR_2 từ [project_abc_cr_2]
10_=> yêu cầu release production source code release_version_CR_2 [comment chi tiết] [thường thì leader merge]
11_=> release production xong :)
12_=> yêu cầu merge branch release_version_CR_2 vào master
13_=> merge vào master [done]
(*) Tùy vào qui trình từng dự án mà có stagging hay không, nếu 6) không có thì bỏ qua 7) 8)
(*) Conflict source thường xảy ra từ bước 2.3_=> merge vào branch dev hoặc 6_=> merge vào branch stagging
(*) Source code branch Master sau cùng là bản release khách hàng, đã được nội bộ test, đã được kh UAT và history có thông tin release_**** [vd: release_version_CR_1] để dễ theo dõi source release
Không có nhận xét nào:
Đăng nhận xét