app branching strategy
1.0.0
왜 S를 이해합니까?
master -> 최신 및 가장 큰 개발 테스트 코드다른 영구 트렁크는 없습니다.
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number> 분기를 해제하기 위해 밀려 난 모든 변경에 대해 PRS를 마스터하기 위해 PRS를 모으는 데 사용 YYMM.DD.NN
NN ➡️ 패치 번호
예 : 2301.25.00 , 2302.01.04
master 에게 PR 합병? On-merge-master.yml 마스터 마스터 마스터 우리는 정식 버전을 업데이트합니다. 기존 버전이 이전 날짜 인 경우 주요 사소한 버전이 수정됩니다. 그렇지 않으면 패치 번호 만 증가합니다.
예 :
기존 버전 : 2301.25.02
2023 년 1 월 25 일에 새로운 커밋이 추진되면 버전은 2301.25.03 됩니다.
2023 년 1 월 26 일에 새로운 커밋이 추진되면 버전은 2301.26.00 됩니다.
release/**? on-merge release.yml
release* 모든 커밋에서 우리는 release* 브랜치에서 패치 번호를 업데이트합니다.
master 에 release/** 밀어 넣습니다 ? on-merge release.yml release* release* 는 auto-backmerge/<pr_number> 분기를 통해 해당 PR을 master 위해 해당 PR을 트리거합니다.
충돌이없는 경우 PR이 자동으로 병합됩니다.
? repay-a-release.yml 지점 이름의 올바른 버전과 함께 최신 마스터에서 릴리스 브랜치를 만듭니다.
행위
? 제작 태그 release.yml 태그 올바른 버전 태그 및 릴리스 노트가있는 릴리스 브랜치의 최신 커밋
행위
%% {init : { 'gitgraph': { 'MainbranchName': 'master', 'showcommitlabel': true}}} %%
gitgraph
커밋 ID : "? 2301.25.00"
분기 수정/프레임 버그
커밋 ID : "논리 수정"
Commit ID : "UI 수정"
결제 마스터
분기 기능/DM
커밋 ID : "DB 추가"
커밋 ID : "소켓 추가"
결제 마스터
Merge Fix/Frames-Bug ID : "PR : 프레임 버그"
커밋 ID : "? 2301.25.01"
결제 기능/DM
병합 마스터 ID : "풀 마스터"
커밋 ID : "UI 추가"
결제 마스터
기능 병합/DM ID : "PR : 기능 DM"
커밋 ID : "? 2301.25.02"
master (Actions)에서 릴리스 브랜치를 자릅니다master 브랜치에서 버그 수정 및 2 단계로 이동 %% {init : { 'gitgraph': { 'MainbranchName': 'master', 'showcommitlabel': true}}} %%
gitgraph
커밋 ID : "? 2301.25.02"
지점 릴리스/V-2301.25
결제 마스터
Commit ID : "PR : 새로운 기능"유형 : 하이라이트
커밋 ID : "? 2301.26.00"
체크 아웃 릴리스/V-2301.25
지점 수정/릴리스 버그
커밋 ID : "수정 버그"
체크 아웃 릴리스/V-2301.25
Merge Fix/Release-Bug ID : "PR : 릴리스 버그"
체크 아웃 릴리스/V-2301.25
지점 자동 백 커지/릴리스 버그
병합 마스터 ID : "업데이트 브랜치"
체크 아웃 릴리스/V-2301.25
커밋 ID : "? 2301.25.03"태그 : "V-2301.25.03"
결제 마스터
Auto-Backmerge/Release-Bug ID 병합 : "Backmerge"
결제 마스터
커밋 ID : "? 2301.26.01"
행위
일단 우리는? 모든 테스트에서 위의 내용을 수행하여 릴리스 브랜치에서 최신 커밋을 태그하고 자동 릴리스 노트가있는 GitHub 릴리스를 만듭니다. 아티팩트를 앱 스토어에 업로드하십시오
현재 생산 빌드에서 문제 수정 ( v-2301.16.01 )
v-2301.16.01 > 분기 : release/v-2301.16 )나머지는 정상 릴리스 흐름과 동일합니다
%% {init : { 'gitgraph': { 'MainbranchName': 'release/v-2301.16', 'showcommitlabel': true}}} %%
gitgraph
커밋 ID : "2301.16.04"태그 : "V-2301.16.04"
분기 핫픽스/충돌
Commit ID : "충돌 수정"
체크 아웃 릴리스/V-2301.16
Hotfix/Crash ID 병합 : "PR 충돌"
커밋 ID : "? 2301.16.05"
분기 핫픽스/버그
커밋 ID : "수정 버그"
체크 아웃 릴리스/V-2301.16
HOTFIX/BUG ID 병합 : "PR BUG"
커밋 ID : "? 2301.16.06"태그 : "V-2301.16.06"
선형 기록은 여러 가지 이유로 바람직합니다. 모두 다시 단순성으로 끓습니다.
단일 트렁크와 스쿼시를 합치는 것은 선형 기록을 달성하는 가장 간단한 방법입니다. 아무도 생각할 필요가 없습니다. 올바른 일은 자동으로 발생합니다.
또한 일반적으로 사람들은 커밋 메시지보다 PR 타이틀과 관련하여 더 나은 징계를 가지고 있으므로 변경 로그도 좋아 보입니다.
서버 앱과 달리 모바일 앱 릴리스 프로세스는 길다. 점진적 롤아웃을 10%> 20%> 50%> 100%로 포함하는 동안 안정성과 메트릭을 관찰하는 경우 2 주 이상이 소요됩니다.
한편, 기고자들은 지금 마스터하기 위해 합병하는 것이 안전한지에 대한 모호성을 가져서는 안됩니다 .
릴리스가 만들어지고 커밋이 태그가 붙으면 목적이 없습니다. 그래서 릴리스 후 삭제합니다.
간트
제목 앱 개발 및 릴리스
DateFormat yyyy-mm-dd
Tickinterval 3day
섹션 개발 1
기능 2 : A, 2022-01-13, 15d
마스터에게 병합 : Crit, Milestone, After, 0d
섹션 개발 2
기능 1 : B, 2022-01-12, 2d
마스터에게 병합 : B, 0D 이후 Milestone
라이브러리 업그레이드 :️ : L, 2022-01-16, 1d
마스터에게 병합 : L, 0D 이후 Crit, Milestone
R1, 2D 후 기능 1? : B2를 수정하십시오
릴리스에 병합 : B2, 0D 이후 이정표
프레임 워크 업그레이드 grade️ : F, 2022-01-22, 1d
마스터에게 합병 : f, 0d 이후 Crit, Milestone
섹션 릴리스
릴리스 2201.14 : B, 0D 이후의 이정표를 준비하십시오
테스트 기능 1 : R1, B, 4d 이후
테스트 기능 1 : R2, B2, 1d
롤아웃 2201.14.1 10% -10% : R2, R2, 7d 이후
릴리스 2201.31 준비 준비 : Milestone, 2022-01-31, 0D
마스터와 합병? 릴리스가 진행되는 경우에도 안전하고 권장됩니다.
날짜 기반 버전 설정 체계이기도합니다
semver 비교와 호환됩니다.2301.16.00 > 2212.31.07 )와 호환됩니다.그리고 무엇보다도 질문을 피하십시오 - 이 버전을 언제 출시 했습니까? 영원히, 팀 전체의 모든 사람으로부터
위의 질문에 대답하는 것이 팀에게 그다지 중요하지 않더라도 semver 보다 낫지는 않지만 똑같이 좋습니다. 대부분의 팀은 기본적으로 사용합니다. 시맨틱 버전싱 ( semver )은 라이브러리에 적합합니다. 도서관의 소비자는 변경 사항이 언제 나오고 언제 없는지 알고 싶어합니다. 패키지 관리자는이 컨벤션을 활용하여 종속성을 안전하게 업그레이드합니다. 모바일 앱 사용자 / 앱 스토어는 앱 버전에 대한 기대치가 없습니다. 그들은 간신히 돌보지 않습니다.
우리 팀은 1 년 이상 날짜 기반 버전 구성 체계를 사용해 왔으며 훌륭합니다!
