미래 지향적인 웹 앱 구축: The Codest의 전문가 팀이 제공하는 인사이트
The Codest가 최첨단 기술로 확장 가능한 대화형 웹 애플리케이션을 제작하고 모든 플랫폼에서 원활한 사용자 경험을 제공하는 데 탁월한 성능을 발휘하는 방법을 알아보세요. Adobe의 전문성이 어떻게 디지털 혁신과 비즈니스를 촉진하는지 알아보세요...
이 문서는 회사 내부의 Git Flow 규칙을 통일하기 위해 작성되었습니다. 이 방법은 순수한 Git Flow를 소개하는 것이 아니라, 오랜 기간 동안 회사의 모범 사례에 따라 Git Flow와 GitLab Flow를 혼합한 것입니다. 리포지토리의 이력을 깔끔하고 읽기 쉽게 유지하고 변경 사항과 프로젝트 라이프사이클을 더 잘 제어하는 데 도움이 됩니다.
이 문서는 회사 내부의 GitFlow 규칙을 통일하기 위해 작성되었습니다. 이 방법은 순수한 GitFlow를 도입한 것이 아니라, 오랜 기간 동안 회사의 모범 사례에 따라 GitFlow와 GitLab Flow를 혼합한 것입니다. 리포지토리의 깔끔하고 읽기 쉬운 기록을 유지하고 변경 사항을 더 잘 제어하는 데 도움이 됩니다. 프로젝트 수명 주기.
리포지토리를 초기화한 후, 리포지토리에 개발 그리고 마스터 브랜치가 기본적으로 포함되지 않은 경우. 개발 브랜치에는 개발 코드 새로운 기능이 포함된 마스터 브랜치의 미러입니다. 마스터에는 프로덕션 상태를 나타내는 안정적인 버전의 코드가 포함되어 있습니다. 둘 다 수명이 무한하며, Git Flow의 다른 브랜치에 비해 절대 제거되지 않습니다. 적절한 보호 규칙을 설정하세요: 병합하기 전에 풀 리퀘스트 검토 필요 그리고 병합하기 전에 상태 확인을 통과해야 합니다.. 선택한 항목만 허용하는 것도 고려할 수 있습니다. 팀 멤버를 사용하여 변경 내용을 마스터에 병합합니다.
$ git init
$ git commit --allow-empty -m "초기 커밋"
$ git 체크아웃 -b 개발 마스터
참고: 예를 들어 사용 가능한 환경을 표현하기 위해 프로젝트에 무한 분기를 더 추가하는 것이 중요한 경우가 있습니다. 하지만 가능하면 '2의 법칙'을 유지하세요.
특정 기능으로 작업을 시작할 때는 먼저 다음 사항을 확인하세요. 개발 브랜치가 동기화되었습니다.
$ git 체크아웃 개발 && git pull --rebase
그런 다음 기능 브랜치로 체크아웃합니다. 각각 지정된 스키마로 이름을 지정합니다: feature-JIRA-TASK-ID 또는 해당 규칙을 깨고 이름을 다르게 지정할 수도 있습니다. 이 경우 릴리스, 핫픽스, 버그픽스, 개발 또는 마스터 브랜치를 위해 예약된 패턴과 충돌하지 않는지 확인하세요. JIRA 작업 ID를 유지하면 기능 브랜치를 보다 효과적으로 관리하는 데 도움이 됩니다.
$ git 체크아웃 -b feature-JIRA-TASK-ID develop
이 브랜치는 지정된 기능이 개발된 후 상위 브랜치에 병합되는 동안 존재해야 합니다. 로컬 브랜치에 커밋하려면 다음 명령을 따르세요:
$ git add .
$ git commit -m "JIRA-TASK-ID: 작업 설명"
"커밋은 일찍 그리고 자주" 규칙에 따라 로컬 브랜치에 더 많은 커밋을 추가하는 것이 좋습니다. 하지만 결국에는 JIRA 태스크를 나타내는 하나의 커밋으로 뭉쳐야 합니다. 자주 커밋하면 개발 이력을 관리하는 데 도움이 됩니다. 기능이 준비되면 풀 리퀘스트를 열어 브랜치를 개발할 차례입니다. 먼저, 너무 많이 밀어붙이지 않았다면 로컬 브랜치를 밀어붙일 수 있습니다:
$ git 푸시 오리진 기능-JIRA-TASK-ID
브랜치가 준비되면 풀 리퀘스트 이 문서를 따라가 보세요: https://help.github.com/en/articles/creating-a-pull-request
풀 리퀘스트를 열기 전에 다음 사항을 확인하세요:
$ git 체크아웃 개발 && git pull --rebase
$ git 체크아웃 기능-JIRA-TASK-ID && git 리베이스 개발 # 스쿼시에는 -i 플래그 사용
$ git push -f origin 기능-JIRA-TASK-ID # -f 플래그가 원격 리포지토리를 덮어쓰므로 주의해서 사용하세요.
이제 변경 사항을 병합하여 브랜치를 개발할 때입니다:
이 작업은 프로젝트 관리자나 기능 개발자가 수행할 수 있습니다. 병합을 수행하려면 다음 단계를 따르세요:
$ git 체크아웃 개발
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git 브랜치 -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID
이제 JIRA 작업 상태를 변경할 수 있습니다.
릴리스 브랜치는 현재 릴리스를 담당하는 담당자가 만들어야 합니다. 일반적으로 릴리스는 주기적으로 만들어지는데, 예를 들어 스프린트 수명 주기.
릴리스 브랜치에 적절한 이름과 해당 태그를 지정하는 것은 처음부터 쉬운 일이 아닙니다. 시맨틱 버전 관리(https://semver.org/)을 사용하면 더 잘 제어할 수 있고 git 기록을 더 쉽게 읽을 수 있습니다. 버전 문자열은 메이저.마이너.패치 스키마에 따라 구성됩니다:
베타 또는 레거시 브랜치를 나타내는 접미사 등 특수 접미사를 사용하거나 사전 릴리스를 만들 수도 있습니다. 이 경우 1.1.0-beta.4, 1.1.0-beta.5 또는 1.1.0-alpha와 같이 적절하게 이름을 지정하세요.
릴리스 브랜치는 개발 브랜치의 자식 브랜치여야 하며 버그 수정과 관련된 커밋만 포함할 수 있습니다.
브랜치 이름은 릴리스 버전에 따라 릴리스- 접두사를 붙여야 합니다: release-major.minor.패치. 릴리스 브랜치는 다음과 같아야 합니다. 자동 및 수동 테스트 모두 완료 에서 스테이징 환경. 버그가 발생하면 이 시점이 적절한 수정 사항을 푸시하고 전체 프로세스를 다시 실행할 수 있는 마지막 기회입니다(긍정적으로 확인되지 않고 추가 처리할 준비가 되어 있지 않은 한). 그런 다음 package.json과 같은 파일에 현재 릴리스 버전 문자열을 변경하여 릴리스 커밋을 푸시해야 합니다. 또한 CHANGELOG.md 파일에도 영향을 미쳐야 합니다. 이렇게 하면 적절한 릴리스 전에 모든 변경 사항을 추적하고 병합 프로세스가 완료되면 GitHub 릴리스를 위한 콘텐츠를 준비하는 데 도움이 됩니다. 단일 파일 업데이트는 기능, 수정 및 유지 관리의 세 가지 범주로 그룹화된 모든 릴리스 변경 사항으로 구성되어야 합니다.
하지만 첫 번째 단계에서는 개발 브랜치와 마스터 브랜치를 모두 최신 상태로 유지해야 합니다.
$ git 체크아웃 마스터 && git pull --rebase
$ git 체크아웃 개발 && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P
$ git add .
$ git commit -m "제품 이름 M.M.P 릴리스"
$ git 푸시 오리진 릴리스-M.M.P
이 시점에서 릴리스 브랜치로 마스터에게 또 다른 풀 리퀘스트를 만들 수 있습니다. 원격 컴퓨터에서 모든 테스트가 잘 통과하는지 추가 검사를 실행하는 것이 좋습니다.
$ git 체크아웃 마스터
$ git merge release-M.M.P
$ git 태그 -a M.M.P # 추가 메시지는 -m 플래그를 통해 설정 가능
$ git push origin M.M.P
$ git push origin 마스터
$ git 브랜치 -d release-M.M.P
$ git push origin :release-M.M.P
그런 다음 GitHub 릴리스 페이지로 이동하여 "새 릴리스 초안 작성" 버튼을 누릅니다. 표시된 양식에서 현재 버전 태그를 선택하고 릴리스 커밋과 유사한 릴리스 제목(제품 이름 M.M.P 릴리스)과 적절한 설명을 설정한 다음 CHANGELOG.md 파일을 기반으로 적절한 설명을 입력합니다. 공개 프로젝트의 경우 설명에는 현재 릴리스에 포함된 모든 PR 목록이 포함되어야 합니다.
릴리스 브랜치에 일부 버그 수정이 적용된 경우 개발 브랜치를 업데이트해야 합니다:
$ git 체크아웃 개발 && git 병합 마스터
$ git push origin developo
버그와 핫픽스의 주요 차이점은 대상 브랜치에 있습니다.
버그 수정은 릴리스 브랜치를 마스터에 병합하기 전에 코드를 업데이트하는 유일한 형태로 패치해야 합니다. 먼저 현재 기능 브랜치에서 브랜치를 만듭니다. 로컬에 최신 버전이 있는지 확인하세요.
$ git 체크아웃 릴리스-M.M.P && git pull --rebase
$ git 체크아웃 -b 버그픽스-M.M.P
그런 다음 필요한 변경 사항을 커밋합니다. 프로세스가 완료되면 풀 리퀘스트를 만들고 릴리스 브랜치로 대상을 지정합니다. 기능 브랜치 섹션의 안내를 따르세요. 최종 커밋 제목은 주어진 스키마와 일치해야 합니다: "버그픽스 M.M.P: 문제 본질 수정". 풀 리퀘스트가 승인되면 현재 릴리스에 병합할 차례입니다.
$ git 체크아웃 릴리스-M.M.P
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
마스터 브랜치에 핫픽스를 수행하려면 대상 브랜치가 이제 마스터 브랜치라는 점을 염두에 두고 버그 수정과 매우 유사한 단계를 수행해야 합니다.
$ git 체크아웃 마스터 && git pull --rebase
$ git 체크아웃 -b 핫픽스-X.Y.(Z+1) # M.M.P는 현재 릴리스를 나타냅니다.
그런 다음 일반적인 개발 단계를 따르고 프로세스가 완료되면 마스터 브랜치를 대상으로 풀 리퀘스트를 생성합니다. 최종 커밋은 주어진 스키마 "핫픽스 X.Y.(Z + 1): 문제 본질 수정". 모든 체크포인트가 성공적으로 통과되면 마스터로 Merge를 수행합니다. 이 단계는 현재 릴리스 버전을 변경해야 하므로 버그 수정의 경우와 다릅니다.
$ git 체크아웃 마스터 && git pull --rebase
$ git merge hotfix-X.Y.(Z+1)
$ git 태그 -a X.Y.(Z+1) # 추가 메시지는 -m 플래그를 통해 설정 가능
$ git push origin X.Y.(Z+1)
$ git push origin 마스터
$ git 브랜치 -d 핫픽스-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git 체크아웃 개발 && git merge 마스터
$ git push origin develop
$ git init
$ git commit --allow-empty -m "초기 커밋"
$ git 체크아웃 -b develop master
$ git push origin develop
$ git push origin master
$ git 체크아웃 개발 && git pull --rebase
$ git 체크아웃 -b feature-JIRA-TASK-ID develop
$ git add .
$ git commit -m "IRA-TASK-ID: 작업 설명" 1TP63초기 커밋
$ git push origin feature-JIRA-TASK-ID
$ git 체크아웃 개발 && git pull --rebase
$ git 체크아웃 기능-JIRA-TASK-ID && git 리베이스 개발 # 스쿼시에는 -i 플래그 사용
$ git push -f origin 기능-JIRA-TASK-ID # -f 플래그가 원격 리포지토리를 덮어쓰므로 주의해서 사용하세요.
$ git 체크아웃 개발 # 브랜치는 이 단계에서 개발 브랜치와 동기화되어야 합니다.
$ git merge 기능-JIRA-TASK-ID
$ git push origin develop
$ git 브랜치 -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID
$ git 체크아웃 마스터 && git pull --rebase
$ git 체크아웃 개발 && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P
$ git add .
$ git commit -m "제품 이름 M.M.P 릴리스" 1TP63초기 커밋
$ git push origin release-M.M.P
$ git 체크아웃 마스터 # 브랜치는 이 단계에서 마스터 브랜치와 동기화되어야 합니다.
$ git merge release-M.M.P
$ git 태그 -M.M.P # 추가 메시지는 -m 플래그를 통해 설정할 수 있다.
$ git push origin M.M.P
$ git push origin 마스터
$ git 브랜치 -d release-M.M.P
$ git push origin :release-M.M.P
$ git 체크아웃 릴리스-M.M.P && git pull --rebase
$ git 체크아웃 -b 버그픽스-M.M.P
$ 커밋 수정
$ git add .
$ git commit -m "버그픽스 M.M.P: 문제 본질 수정" 1TP63초기 커밋
$ git push origin bugfix-M.M.P
$ git 체크아웃 릴리스-M.M.P # 브랜치는 이 단계에서 현재 릴리스 브랜치와 동기화되어야 한다.
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git 브랜치 -d 버그픽스-M.M.P
$ git push origin :bugfix-M.M.P
$ git 체크아웃 마스터 && git pull --rebase
$ git 체크아웃 -b 핫픽스-X.Y.(Z+1) # M.M.P는 현재 릴리스를 나타냅니다.
$ 커밋 수정
$ git add .
$ git commit -m "핫픽스 M.M.P: 문제 본질 수정" #initial 커밋
$ git push origin 버그픽스-M.M.P
$ git 체크아웃 마스터 # 브랜치는 이 단계에서 현재 마스터와 동기화되어야 한다.
$ git merge 핫픽스-X.Y.(Z+1)
$ git 태그 -a X.Y.(Z+1) # 추가 메시지는 -m 플래그를 통해 설정할 수 있다.
$ git push origin X.Y.(Z+1)
$ git push origin 마스터
$ git 브랜치 -d 핫픽스-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git 체크아웃 개발 && git merge 마스터
$ git push origin develop
자세히 읽어보세요: