GitHub 흐름의 구성 요소

완료됨

이 단원에서는 GitHub 흐름의 다음 구성 요소를 검토합니다.

• 분기
• 커밋
• 끌어오기 요청
• GitHub 흐름
• Git 흐름

GitHub Flow의 구성 요소

GitHub 관련 워크플로에 들어가기 전에 GitHub Flow가 Git의 기본 개념을 기반으로 직접 빌드된다는 것을 이해하는 것이 도움이 됩니다.

Git은 시간이 지남에 따라 코드의 변경 내용을 추적하고 관리하는 도구를 제공합니다. GitHub는 분기, 커밋, 끌어오기 요청 및 협업을 위한 시각적 인터페이스와 같은 기능을 통해 이러한 도구를 더 쉽게 사용할 수 있도록 하여 이를 기반으로 합니다. 먼저 GitHub에서 이러한 개념이 어떻게 작동하는지 살펴보겠습니다.

브랜치란 무엇인가요?

마지막 섹션에서는 리포지토리에 새 파일과 새 분기를 만들었습니다.

분기는 GitHub 환경의 필수적인 부분입니다. 기본 분기에 영향을 주지 않고 변경할 수 있습니다.

브랜치는 새로운 기능이나 수정 사항을 실험할 수 있는 안전한 장소입니다. 실수를 하면 변경 내용을 되돌리거나 더 많은 변경 내용을 푸시하여 실수를 해결할 수 있습니다. 브랜치를 병합할 때까지 기본 브랜치에서 변경 내용이 업데이트되지 않습니다.

참고

또는 터미널에서 git을 사용하여 새 분기를 만들고 체크 아웃할 수 있습니다. 명령은 git checkout -b newBranchName입니다.

커밋이란?

이전 단원에서는 커밋을 푸시하여 리포지토리에 새 파일을 추가했습니다. 커밋이 무엇인지 간략하게 살펴보겠습니다.

커밋은 분기에서 하나 이상의 파일을 변경하는 행위입니다. 각 커밋은 명령줄을 통해 또는 GitHub의 웹 인터페이스에서 직접 만들어지는지 여부에 관계없이 고유한 ID, 타임스탬프 및 기여자로 추적됩니다. 커밋은 파일 또는 연결된 항목(예: 문제 또는 끌어오기 요청)의 기록을 검토하는 모든 사용자에게 명확한 감사 내역을 제공합니다.

다음을 사용하여 터미널에서 Git을 사용하여 커밋을 만들 수 있습니다.

git commit -m "Add a helpful commit message"

git 리포지토리 내에서 파일은 버전 제어 프로세스를 거치면서 여러 유효한 상태로 존재할 수 있습니다. Git 리포지토리의 파일에 대한 기본 상태는 추적되지 않음 및 추적됨입니다.

추적되지 않음: 아직 Git 리포지토리에 속하지 않은 파일의 초기 상태입니다. Git은 해당 존재를 인식하지 못합니다.

추적됨: 추적된 파일은 Git에서 적극적으로 모니터링하는 파일입니다. 다음 하위 상태 중 하나일 수 있습니다.

• 수정되지 않음: 파일이 추적되지만 마지막 커밋 이후 수정되지 않았습니다.
• 수정됨: 마지막 커밋 이후 파일이 변경되었지만 다음 커밋을 위해 이러한 변경 내용이 아직 준비되지 않았습니다.
• 스테이징됨: 파일이 수정되었으며 변경 내용이 준비 영역(인덱스라고도 함)에 추가되었습니다. 이러한 변경 내용을 커밋할 준비가 된 것입니다.
• 커밋됨: 파일이 리포지토리의 데이터베이스에 있습니다. 파일의 커밋된 최신 버전을 나타냅니다.

이러한 상태는 팀이 각 파일의 상태와 버전 제어 프로세스의 위치를 이해하는 데 도움이 됩니다.

끌어오기 요청이란 무엇일까요?

끌어오기 요청은 특정 분기의 커밋을 다른 분기에 병합할 수 있음을 알리는 데 사용하는 메커니즘입니다.

끌어오기 요청을 제출하는 팀 구성원은 1명 이상의 검토자에게 코드를 확인하고 병합을 승인하도록 요청합니다. 이러한 검토자는 변경 사항에 관한 설명을 달고, 자신의 변경 사항을 추가하거나, 끌어오기 요청을 사용하여 추가 논의를 진행할 수 있습니다.

GitHub는 아직 검토할 준비가 되지 않은 끌어오기 요청을 열 수 있는 끌어오기 요청 초안도 지원합니다.

변경 내용이 승인되면(필요한 경우) 끌어오기 요청의 원본 분기(비교 분기)가 기본 분기에 병합됩니다.

분기, 커밋 및 끌어오기 요청의 작동 방식을 살펴보았으므로 GitHub Flow에서 분기, 커밋 및 끌어오기 요청의 작동 방식을 살펴보겠습니다.

GitHub 흐름

GitHub 흐름은 변경 내용을 안전하게 만들고 공유하는 데 도움이 되는 간단한 워크플로입니다. 분기, 끌어오기 요청 및 병합을 사용하여 아이디어를 시도하고 팀과 공동 작업하는 데 유용합니다.

참고

GitHub 흐름은 몇 가지 인기 있는 워크플로 중 하나입니다. 그 외에는 Git 흐름 및 트렁크 기반 개발이 포함됩니다.

이제 GitHub의 기본 사항을 알게 되었으므로 GitHub 흐름 및 해당 구성 요소를 안내할 수 있습니다.

1. 먼저 분기를 만들어 변경, 기능 또는 수정 사항이 주 분기에 영향을 주지 않도록 합니다.
2. 다음으로, 분기에서 업데이트를 합니다. 워크플로에서 지원하는 경우 병합하기 전에 이 분기의 변경 내용을 배포하여 테스트할 수 있습니다.
3. 이제 끌어오기 요청을 열어 피드백을 초대하고 검토를 시작합니다.
4. 그런 다음, 의견을 검토하고 팀의 피드백에 따라 필요한 업데이트를 만듭니다.
5. 마지막으로 변경 내용에 대한 확신이 있으면 승인을 받고 끌어오기 요청을 주 분기에 병합합니다.
6. 그런 다음 분기를 삭제하여 리포지토리를 정리하고 오래된 분기를 사용하지 않도록 합니다.

Git 흐름

GitHub Flow는 지속적인 업데이트를 위해 설계된 간단한 워크플로이지만 , Git 흐름 은 릴리스 기반 환경에서 자주 사용되는 보다 구조화된 분기 모델입니다. Git 흐름이 GitHub Flow보다 길어졌으며 기본 분기 대신 main 사용된 용어 master 가 계속 표시되어 있을 수 있습니다.

Git 흐름 분기 형식

Git 흐름은 다음과 같은 몇 가지 수명 및 임시 분기를 사용합니다.

• master: 항상 프로덕션 준비 코드를 반영합니다.
• 개발: 다음 릴리스에 대한 최신 개발 작업을 포함합니다.
• feature/*: 새 기능을 만드는 데 사용됩니다. 분기되고 develop 완료되면 다시 병합됩니다.
• release/*: 새 프로덕션 릴리스를 develop준비합니다. 최종 테스트 및 사소한 버그 수정이 가능합니다.
• 핫픽스/*: 프로덕션 문제를 신속하게 패치하는 데 사용됩니다. 에서 분기됩니다 master.

Git 흐름 프로세스 작동 방식

1. 개발자는 새로운 기능을 빌드하기 위해 기능 분기develop 를 만듭니다.
2. 릴리스 시간이 되면 릴리스 분기 가 .에서 develop만들어집니다. 이렇게 하면 릴리스 준비 작업이 격리되므로 개발이 중단 없이 계속될 수 있습니다.
3. 버그 수정은 릴리스 분기에 추가할 수 있지만 주요 기능은 향후 릴리스를 기다려야 합니다.
4. 준비가 되면 릴리스 분기가 병합 master 되고 버전 번호로 태그가 지정됩니다. GitHub는 이러한 태그를 사용하여 릴리스 정보를 생성할 수 있습니다.
5. 동기화 상태를 유지하려면 동일한 릴리스 분기를 develop 다시 병합해야 합니다.
6. 중요한 프로덕션 버그가 발생하면 핫픽스 분기 가 만들어집니다 master. 일단 수정되면 두 가지 모두 master 에 병합됩니다 develop.

Git 흐름을 사용하는 경우

• 예약되거나 버전이 지정된 릴리스가 있는 프로젝트에 가장 적합합니다.
• 여러 프로덕션 버전(예: 장기 지원 분기)을 유지 관리하는 경우에 유용합니다.
• 더 느리고 구조화된 개발 주기(예: 엔터프라이즈 또는 규제 환경)에 이상적입니다.
• 추가 분기 관리로 인해 GitHub Flow보다 더 많은 "중량"으로 간주됨

참고

Git 흐름은 분기를 통합하기 위한 병합 커밋을 가정합니다. 재베이스 또는 스쿼시 병합을 사용하면 분기 구조 및 기록 추적을 방해할 수 있습니다.

GitHub를 사용하는 많은 팀의 경우 GitHub Flow는 더 간단하고 빠릅니다. 그러나 팀이 예측 가능성을 중시하고 더 많은 릴리스 계획이 필요한 경우 Git 흐름이 더 적합할 수 있습니다.

축하합니다! 전체 GitHub Flow를 살펴보았으며 Git 흐름이 릴리스 기반 프로젝트에 대한 구조화된 대안을 제공하는 방법을 살펴보았습니다.

다음 섹션으로 이동하여 문제와 토론의 차이점을 살펴보겠습니다.