ồ, sợ, hoang mang vì 1 đống thứ phải lo..
vài ngày định tâm suy nghĩ và tiến tới tự học lại kiến thức chuyên ngành, tìm nộp hồ sơ pv
cuối cùng cũng OK, lại nhận việc cty mới, chiến đấu thôi ;)
ồ, sợ, hoang mang vì 1 đống thứ phải lo..
vài ngày định tâm suy nghĩ và tiến tới tự học lại kiến thức chuyên ngành, tìm nộp hồ sơ pv
cuối cùng cũng OK, lại nhận việc cty mới, chiến đấu thôi ;)
Sách sẽ đọc (đã đọc) 2019
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
Một ngày đẹp trời, ẻm im ru, gọi điện nhắn tin tìm kiếm các kiểu ko có thông tin gì
Vài ngày gặp lại thái độ hững hờ lạnh tanh
Em chọn xa ta :)
Chính thức trở thành đơn vị cung cấp dịch vụ đăng ký tên miền quốc tế, tên miền Việt Nam hosting, máy chủ, cloud hosting, cloud server, ema...