06/09/2017

Git flow

 


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