이 문서는 회사 내부의 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

풀 리퀘스트를 열기 전에 다음 사항을 확인하세요:

• a 적절한 설명 가 주어진 경우 - 일반적으로 JIRA 작업 연결로 설정할 수 있지만 현재 코드와 관련된 몇 가지 유용한 정보를 포함할 수도 있습니다.
• CircleCI 단계가 성공적으로 통과되었습니다.
• 당신의 팀원이 할당되었습니다. - 모든 팀원을 할당자로 포함하는 것이 좋습니다.
• 의 리뷰어가 선정되었습니다. - 검토자 수는 팀에 따라 다릅니다.
• 코드가 실제로 검토할 준비가 되었습니다. 코드를 다시 한 번 살펴보고 리팩터링할 부분이 남아 있는지 다시 생각해보고 로컬에서 테스트합니다. 를 클릭하고 다음 단계를 수행할 준비가 되었는지 확인합니다.
• 있습니다 병합 충돌이 없고 브랜치가 개발 중인 최신 상태입니다. - 있는 경우 먼저 해결하십시오.

$ git 체크아웃 개발 && git pull --rebase
$ git 체크아웃 기능-JIRA-TASK-ID && git 리베이스 개발 # 스쿼시에는 -i 플래그 사용
$ git push -f origin 기능-JIRA-TASK-ID # -f 플래그가 원격 리포지토리를 덮어쓰므로 주의해서 사용하세요.

• 중요한 커밋만 보관 - 예를 들어 각 커밋은 JIRA 작업으로 표시되어야 합니다, JIRA-TASK-ID: 새로운 기능 구성; 기타는 다음과 같아야 합니다. 리베이스하는 동안 찌그러짐 개발 브랜치가 있는 브랜치
• 당신은 적절한 대상 지점 선택
• 잊지 마세요 JIRA 작업의 상태 변경

기능 브랜치 병합하기

이제 변경 사항을 병합하여 브랜치를 개발할 때입니다:

• 풀 리퀘스트가 선택된 팀원들에 의해 승인되었습니다.
• 모든 테스트가 성공적으로 완료되었습니다.
• 병합 충돌이 없고 커밋 기록이 정상적으로 보입니다.

이 작업은 프로젝트 관리자나 기능 개발자가 수행할 수 있습니다. 병합을 수행하려면 다음 단계를 따르세요:

$ 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 기록을 더 쉽게 읽을 수 있습니다. 버전 문자열은 메이저.마이너.패치 스키마에 따라 구성됩니다:

• MAJOR - 호환되지 않는 API 변경 사항을 나타내는 변경 사항
• MINOR - 이전 버전과 호환되는 방식으로 새로운 기능 추가
• 패치 - 이전 버전과 호환되는 버그 수정 추가

베타 또는 레거시 브랜치를 나타내는 접미사 등 특수 접미사를 사용하거나 사전 릴리스를 만들 수도 있습니다. 이 경우 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

자세히 읽어보세요:

• 소프트웨어 구축을 위한 Codest의 모범 사례: CircleCI
• 넷플릭스 자막 스타일러를 사용하여 구글 크롬 확장 프로그램을 만드는 방법은 무엇인가요?
• React: 가장 인기 있는 JavaScript 프레임워크