Git 협업하기 개념 정리 2️⃣ (코드 리뷰, 브랜치 관리 전략, 협업 자동화)

이번 글은 코드잇 강의를 수강하면서 배운 내용을 주로 하여 정리되어 있습니다. (코드잇 스프린트 데이터 애널리스트 트랙 1기 훈련생)

---

코드 리뷰

---

코드 리뷰 문화

코드 리뷰의 중요성

1. 트럭 팩터 증가

트럭 팩터(또는 버스 팩터)는 프로젝트의 핵심 지식을 얼마나 많은 개발자가 공유하고 있는지를 나타내는 지표입니다. 트럭 팩터가 ‘1’인 프로젝트는 한 명의 개발자만이 중요한 지식을 가지고 있다는 의미입니다. 만약 그 개발자가 프로젝트에서 떠난다면, 프로젝트는 큰 위험에 처할 수 있습니다. 코드 리뷰는 이러한 문제를 완화하는 데 중요한 역할을 합니다. 코드 리뷰를 통해 모든 팀원이 서로의 코드를 검토하고 이해할 수 있게 되면, 트럭 팩터가 증가하여 프로젝트의 안정성이 높아집니다.

2. 코드 품질 향상

코드 리뷰는 코드 품질을 향상시키는 데 중요한 역할을 합니다. 개발자들은 코드 리뷰를 통해 다른 사람이 자신의 코드를 볼 것을 예상하고 더 신중하게 코드를 작성하게 됩니다. 이는 코드의 가독성을 높이고, 버그를 줄이며, 코드 유지 보수를 쉽게 만듭니다. 또한, 리뷰 과정에서 발생할 수 있는 문제들을 사전에 발견하고 해결할 수 있습니다.

3. 협업과 지식 공유

코드 리뷰는 팀원 간의 협업을 촉진하고 지식을 공유하는 중요한 수단입니다. 코드 리뷰를 통해 팀원들은 서로의 작업을 이해하고, 프로젝트의 진행 상황을 파악할 수 있습니다. 이는 팀의 일관성을 유지하고, 새로운 팀원이 빠르게 프로젝트에 적응할 수 있도록 도와줍니다.

팀 내에 코드 리뷰 문화 만들기

코드 리뷰 문화를 정착시키는 것은 도전적인 일이지만, 몇 가지 방법을 통해 성공적으로 도입할 수 있습니다.

1. 정기적인 코드 리뷰 시간 설정

정기적인 코드 리뷰 시간을 설정하여 팀원들이 리뷰를 할 수 있도록 합니다. 이 시간 동안에는 서로의 코드만 리뷰하는 것을 원칙으로 합니다. 이렇게 정기적인 시간을 설정하지 않으면 코드 리뷰는 선택 사항으로 간주될 수 있습니다.

2. 상호 존중의 문화 형성

피드백은 항상 상호 존중의 분위기에서 이루어져야 합니다. 피드백은 코드 작성자 개인이 아닌 코드 자체에 집중해야 합니다. 또한, 피드백을 줄 때는 지적보다는 제안의 형태로 주는 것이 좋습니다.

3. 받은 리뷰에 대응하기

동료들의 피드백에 동의하면 코드를 수정하고, 지금 당장 반영하기 어려운 피드백은 이슈로 분리하여 추후 처리할 것임을 알려줍니다. 피드백을 반영할 수 없는 상황이라면 그 이유를 설명하는 것이 중요합니다. 받은 피드백에 아무런 대응이 없다면, 코드 리뷰에 대한 동기 부여가 줄어들고, 코드 리뷰가 활성화되지 않을 수 있습니다.

코드 리뷰 시 유의할 점

1. 명확하고 구체적인 피드백

피드백은 구체적이고 명확해야 합니다. 모호한 피드백은 코드 작성자가 이해하기 어렵습니다. 예를 들어, "이 부분을 개선하세요"보다는 "이 변수명을 더 명확하게 바꾸는 것이 좋겠습니다"와 같은 구체적인 피드백이 더 도움이 됩니다.

2. 긍정적인 피드백

잘 작성된 코드에 대해서도 긍정적인 피드백을 주는 것이 중요합니다. 이는 코드 작성자가 올바르게 하고 있는 부분을 강화하고, 동기 부여를 유지하는 데 도움이 됩니다.

3. 개선 제안

코드 리뷰는 단순한 지적보다는 개선 제안을 포함해야 합니다. 예를 들어, "이 부분의 로직이 이해하기 어려운데, 더 간단하게 작성할 수 있는 방법이 있을까요?"와 같은 질문을 통해 개선 방향을 제안할 수 있습니다.

---

Github에서 코드 리뷰하기

GitHub는 협업을 효과적으로 지원하기 위해 다양한 코드 리뷰 기능을 제공합니다. 이번 목차에서는 기본적인 기능부터 시작하여 도움이 되는 기능들을 소개하겠습니다.

1. Pull Request 페이지 탐색

동료가 PR을 올리고 리뷰 요청을 했다고 가정해 보겠습니다. PR 페이지에 들어가서 상단 메뉴에서 Files changed를 클릭하면, 파일의 변경 사항들을 볼 수 있습니다.

2. 라인 별로 코드 리뷰하기

변경된 코드 라인의 오른쪽에 마우스 커서를 올리면 코멘트를 달 수 있는 창이 나옵니다. 여기서 + 버튼을 클릭하여 코멘트를 작성할 수 있습니다.

 

Suggested Change 사용하기

코멘트를 작성할 때, 변경 사항을 제안하고 싶다면 Suggested change 기능을 사용합니다.

3. 리뷰 제출하기

리뷰를 제출하는 방법은 두 가지입니다:

• Add single comment: 즉시 다른 개발자들이 볼 수 있도록 코멘트 형태로 리뷰가 남습니다.
• Start a review: 작성한 코멘트가 Pending 상태가 되며, 리뷰가 모두 완료되었을 때 한꺼번에 제출할 수 있습니다.

4. 멀티라인 코드 리뷰하기

여러 줄의 코드를 수정하고 싶을 때는 멀티라인 코멘트 기능을 사용합니다. 시작하는 라인 번호의 좌측을 클릭한 후, Shift 키를 누르고 다른 라인의 좌측을 클릭하면 범위를 선택할 수 있습니다.

5. Viewed 기능 사용하기

한두 개의 파일만 있는 경우에는 상관없지만, 여러 파일이 변경된 경우 어떤 파일을 리뷰했는지 파악하기 어렵습니다. 이를 해결하기 위해 Viewed 기능을 사용합니다. 리뷰한 파일을 Viewed로 표시하면 다음 번에 변경 사항이 없는 경우 접혀 있게 됩니다.

6. 커밋별로 리뷰하기

커밋 단위로 리뷰를 하려면 Commits 탭을 클릭합니다. 여기서 특정 커밋을 클릭하면 해당 커밋의 변경 사항만 확인할 수 있습니다. 연속된 여러 커밋을 확인하려면 Shift 키를 누른 채 보고 싶은 범위의 커밋을 선택하면 됩니다.

7. 리뷰 제출하기

모든 리뷰가 완료되면 Review changes 버튼을 클릭하여 리뷰를 제출합니다. 여기서 세 가지 옵션 중 하나를 선택할 수 있습니다:

• Comment: 개선점, 의문점, 제안 등을 남기기 위해 사용됩니다.
• Approve: 코드가 문제없다는 의견을 전달합니다. 필요하다면 승인 없이 머지할 수 없게 설정할 수 있습니다.
• Request changes: 개선이 필요하거나 수정이 요구되는 사항이 있을 때 사용됩니다.

만약 리뷰어가 Approve를 주지 않았다면 머지할 수 없기 때문에 코드 작성자는 이런 리뷰를 반영해서 새로운 커밋을 올릴 것입니다.

그때 리뷰어인 여러분들은 해당 커밋을 다시 리뷰하고 적절하게 코드가 수정 됐다면 Approve를 통해 코드 머지를 승인할 수 있습니다.

---

코드 리뷰를 위한 좋은 commit 만들기 가이드라인

1. 의미 있는 단위의 작업을 해야 합니다.
   • 한 개의 커밋이 하나의 기능이나 작업을 완성해야 좋은 커밋입니다.
   • 커밋 단위는 작게 유지하되, 지나치게 작은 단위는 피합니다.
   • 의미 있는 단위는 함수, 메소드, 클래스 또는 인터페이스 간의 연결 관계 등을 포함합니다.
   • 조직의 기준이나 동료들의 합의에 따라 작업 단위를 결정합니다.
2. 생성된 커밋은 동작이 가능한 형태이어야 합니다.
   • 커밋이 정상적으로 동작하는지 검증해야 합니다.
   • 프로젝트 전체의 동작을 방해하지 않는지도 확인합니다.
   • 자동화된 테스트나 수동 테스트를 통해 검증합니다.
3. 커밋 메시지는 명확하고 간결하게 작성되어야 합니다.
   • 히스토리를 이해하는데 큰 도움, 문제가 발생했을 때, 원인을 찾는데도 도움
   • 커밋 메시지는 코드 변경 사항을 빠르게 파악할 수 있도록 작성합니다.
   • Conventional Commit 규칙을 따릅니다: <type>(<scope>): <subject>
   • 자주 사용하는 type:
     • feat: 기능 개발
     • docs: 문서화
     • test: 테스트 관련
     • fix: 버그 수정
     • chore: 코드와 관련 없는 수정
     • CI: CI/CD 관련 작업

---

프로그래밍 언어의 코드 작성 스타일 및 자동화 도구

코드 작성 스타일과 규칙

• 대부분의 프로그래밍 언어는 커뮤니티에서 권장하는 코드 작성 스타일이 있으며, 공식 문서로 수십, 혹은 수백 가지 규칙들이 나열되어 있습니다.
• 이러한 규칙들을 모두 외우고 적용하는 것은 어렵기 때문에 자동으로 규칙 체크를 해주는 도구가 필요합니다.

규칙 체크 도구 : Linting과 Formatter 도구

• Linting: 소스 코드에서 스타일, 문법, 오류 등을 특정 규칙에 어긋난 것이 없는지 자동으로 체크해 주는 도구.
• Formatter: 코드 스타일을 자동으로 맞춰주는 도구.

Linting 도구의 효과

• 동일한 코딩 스타일 유지.
• 코드 가독성 향상.
• 잠재적인 버그와 오류 사전 발견.
• 코드 리뷰 시간 단축.

Linting 규칙의 통일

• Linting 도구들은 설정 파일을 통해 규칙을 지정할 수 있으며, Git을 통해 설정 파일을 공유하면 팀원 간의 규칙을 통일할 수 있습니다.

Python의 Linting 및 Formatting 도구

1. Flake8 : Python의 대표적인 Linting 도구.
2. Black : Python 코드 Formatter.
3. isort : Python 파일의 import 구문을 정렬해 주는 도구.

---

브랜치 관리 전략

---

브랜치 관리 전략이란?

브랜치 관리 전략은 소스 코드의 버전을 체계적으로 관리하기 위한 방법론입니다.(복잡한 작업 흐름을 구조화하며, 코드의 안정성과 개발 효율을 높이는 역할)

• 기능 개발, 버그 수정, 리팩토링 등 복잡한 작업이 동시에 이뤄질 때 프로젝트가 서로 영향을 받지 않도록 지침을 제공합니다.
• 이 전략은 코드의 안정성과 개발 효율을 높이며, 기능별 브랜치 생성, 버그 수정 브랜치 관리, 배포 준비 브랜치 등을 포함합니다.

대표적인 브랜치 관리 전략 : GitFlow / Github Flow / Gitlab Flow / Trunk Based Development

브랜치 관리 전략의 필요성

• 브랜치 관리 전략을 적용하는 것은 제약일 수 있지만, 과거 개발자들의 지혜가 담긴 베스트 프랙티스입니다.
• 전략을 공부하면 개발 프로세스를 명확하게 이해하고, 현재 작업 환경과 목표에 적합한 전략을 선택할 수 있습니다.
• 이는 코드 효율성뿐만 아니라 팀원 간의 원활한 소통과 협업에도 기여합니다.

---

Github Flow

GitHub에서 제안한 브랜치 전략으로, 단순하고 명확한 작업 방식을 제안합니다.

핵심 브랜치(main 또는 master)에서 작업 브랜치를 생성하고, Pull Request를 통해 코드 리뷰 후 머지하는 방식입니다.

핵심 브랜치의 코드는 항상 배포될 준비가 되어 있어야 합니다.

Feature 브랜치

• 새로운 기능이나 수정 사항마다 별도의 브랜치를 생성하여 작업하는 방식입니다.
• 다양한 기능이나 수정 사항을 독립적으로 개발할 수 있어, 여러 개발자가 동시에 작업할 때 충돌을 최소화할 수 있습니다.
• Feature 브랜치 : 새로운 기능을 개발하기 위한 브랜치이며, 새로운 기능을 개발할 때 main 브랜치에서 분기하여 개발을 진행하고 개발이 완료되면 main 브랜치로 다시 머지합니다. (main 브랜치 : 항상 배포 가능하도록 준비된 브랜치)

GitHub Flow 작업 과정

1. 메인 브랜치에서 새로운 브랜치 생성:
   • 작업 브랜치를 생성하여 시작합니다.
   • 브랜치 이름은 작업 내용을 직관적으로 알 수 있게 지정합니다.
   • 메인 브랜치는 브랜치 보호 룰을 설정하여 보호합니다.
2. 브랜치에서 작업:
   • 필요한 모든 변경 사항을 커밋하고, GitHub에 브랜치를 푸시하여 협업합니다.
3. Pull Request 생성:
   • 작업이 완료되면 Pull Request를 생성하여 변경 사항을 설명합니다.
4. 코드 리뷰:
   • 팀원들이 Pull Request를 리뷰하고 의견이나 수정 요청을 남깁니다.
   • 코드 리뷰가 완료되면 브랜치 보호 룰에 따라 머지합니다.
5. 머지:
   • 수정 사항이 반영된 후 머지하고, 불필요해진 브랜치는 삭제합니다.
   • GitHub 설정을 통해 Pull Request가 머지될 때 자동으로 브랜치를 삭제할 수 있습니다.

GitHub Flow의 핵심

• 배포 가능 상태 유지: main**/ master 브랜치**는 항상 배포 가능 상태(=항상 코드로 만들어진 프로그램이 의도한대로 동작하는 상태)여야 합니다.
• 코드 리뷰: 코드 리뷰를 통해 오류를 사전에 방지합니다.
• 테스트: 기능이 제대로 동작하는지 확인하는 자동화된 테스트를 통해 배포 가능성을 보장합니다.
• CI 도구: 지속적 통합(CI) 도구를 사용하여 자동으로 빌드하고 테스트합니다.

GitHub Flow를 적용할 때의 현실적인 고민들

• 프로젝트 초기 단계: 초기에는 전체 구조가 바뀔 가능성이 많아 GitHub Flow 적용이 어려울 수 있습니다. 프로젝트 방향성, 규칙, 구조 등을 먼저 정의하고 협의한 후에 적용하는 것이 좋습니다.
• Feature 정의: Feature를 명확하고 구체적으로 정의하며, 독립적으로 배포 가능하고 호환성을 유지하며 적절한 크기로 유지해야 합니다.

---

GitFlow

Git Flow는 2010년에 Vincent Driessen이 제안한 Git 브랜치 전략으로, 프로젝트의 규모와 복잡성에 따라 다양한 브랜치를 활용하여 개발 프로세스를 체계적으로 관리하는 방법입니다.

Git Flow에는 main 브랜치와 feature 브랜치만 존재하는 GitHub Flow와는 다르게 develop / hotfix / release라는 브랜치 개념이 더 존재하고 있습니다.

Git Flow의 주요 브랜치

1. main 브랜치
   • 실제 사용자에게 제공되는 안정적인 버전의 코드를 관리
   • 최종적인 프로덕션(배포) 브랜치 (영구적으로 존재)
   • 항상 배포 가능 상태여야 함
2. develop 브랜치
   • 최신 개발 기능이 모이는 브랜치
   • GitHub Flow의 main 브랜치와 유사하지만, 항상 배포 가능 상태를 유지할 필요는 없습니다.
3. feature 브랜치
   • 새로운 기능을 개발하기 위한 브랜치
   • develop 브랜치에서 시작해 develop 브랜치로 병합
4. release 브랜치
   • 배포 준비를 위한 브랜치
   • develop 브랜치에서 분기하여 메타데이터 수정 및 최종 버그 수정을 진행
   • 완료 후 main과 develop 브랜치로 병합
5. hotfix 브랜치
   • 프로덕션에서 발생한 긴급한 버그 수정을 위한 브랜치
   • main 브랜치에서 바로 분기하여 수정 후 main과 develop 브랜치로 병합

Git Flow의 작업 과정

1. feature 브랜치 생성 및 작업
   • checkout from: develop
   • merge into: develop
2. release 브랜치 생성 및 작업
   • checkout from: develop
   • merge into: develop and main
3. hotfix 브랜치 생성 및 작업
   • checkout from: main
   • merge into: develop and main

Git Flow의 장점과 단점

• 장점:
  • 복잡한 프로젝트에서 다양한 브랜치를 활용하여 명확하게 개발 프로세스를 관리
  • 각 브랜치의 역할이 명확하여 코드의 안정성과 품질을 유지
• 단점:
  • 브랜치와 병합이 많아 복잡하고 관리가 어려움
  • 작은 프로젝트나 빠른 개발 주기를 필요로 하는 프로젝트에서는 오버헤드가 큼

이번에 설명한 Git Flow는 대규모 프로젝트와 복잡한 개발 환경에서 유용하지만, GitHub Flow는 단순하고 빠른 개발 주기를 지원하며 협업을 쉽게 만듭니다.

Git을 통해 협업을 하는 경우에 프로젝트와 팀의 특성에 맞는 브랜치 전략을 선택하여 적용하는 것이 중요합니다.

---

Github Flow vs GitFlow

먼저, CI/CD에 대해 간략히 소개하겠습니다.

CI / CD

CI / CD는 소프트웨어 개발과 배포를 최적화하기 위한 전략적인 접근 방식을 말합니다.

 

• CI (Continuous Integration)
  • Continuous Integration (CI)은 개발 팀이 코드 변경 사항을 중앙의 코드 저장소에 빈번하게 통합하는 과정을 의미합니다.
    CI의 목적은 코드 변경 사항을 빠르게 검증하고, 자동화된 테스트로 문제를 빠르게 파악할 시에 즉시 해결하여 개발의 효율성과 코드 품질을 높이는 것입니다.
• CD (Continuous Delivery & Continuous Deployment)
  • Continuous Delivery는 CI 과정을 통해 검증된 코드가 프로덕션 환경에 배포될 준비가 되어 있음을 의미합니다.
    → 실제로 자동으로 배포가 되지는 않고, 실제 배포는 수동 트리거에 의해 실행됩니다.
  • Continuous Deployment는 CI 과정을 통해 검증된 코드가 자동으로 프로덕션 환경으로 배포되는 것입니다.
    → 사용자의 개입 없이 코드 변경이 바로 배포

CI/CD를 기점으로 변화된 개발 환경

2010년대의 개발 환경에서는 Git Flow 방법을 활용하여 복잡한 브랜치 구조로 프로젝트 요구사항, 버그 수정, 신기능 개발을 체계적으로 관리했습니다.

• 당시 소프트웨어 배포는 주기적이고 준비 시간이 필요했으며, CD는 널리 대중화되지 않음.

현대의 개발 환경은 CI/CD의 발전으로 배포가 더 쉬워지고 빈도가 빨라져서 GitHub Flow라는 간결하고 직관적인 브랜칭 모델이 탄생하게 되었습니다.

Git Flow에서 GitHub Flow로의 변화

이러한 개발 환경의 변화와 발전으로 인해 복잡한 구조의 GitFlow에서 간단한 GitHub Flow가 탄생하게 되었습니다.

• 이유:
  • 복잡한 Git Flow의 단순화
  • 빠른 개발 주기와 쉬운 협업을 지원
  • 최신 소프트웨어 개발 방식에 적합
• 적용 환경:
  • 작은 프로젝트, 빠른 개발 주기가 필요한 프로젝트, CI/CD 환경에서 효과적

Git Flow와 GitHub Flow 비교

• GitHub Flow:
  • 장점: 빠른 개발 사이클, 즉각적인 배포, 단일 브랜치 중심
  • 단점: 복잡한 릴리즈 관리나 여러 버전 동시 관리에 한계
• Git Flow:
  • 장점: 복잡한 배포 관리, 여러 버전의 소프트웨어 동시 관리에 유용
  • 단점: 프로젝트 복잡도를 증가시킬 수 있고, 빠른 배포 주기에는 부적합

---

버전 관리 전략

브랜치 관리 전략은 소프트웨어를 어떻게 배포하고 관리할지 규격을 만드는 것입니다.

위 과정에서 가장 중요한 부분이 바로 버전 관리인데, 올바른 버전 관리 전략은 프로젝트의 이력을 명확하게 표현하며, 개발자들이 변경 사항을 쉽게 추적할 수 있게 하고, 사용자들에게 소프트웨어의 상태와 변화를 명확하게 알려줍니다.

그래서 올바른 버전 관리 전략을 구성한다면 개발 및 배포 프로세스의 투명성과 효율성을 높이는 효과를 불러올 수 있습니다.

버전 관리 전략에서 버전 번호는 소프트웨어의 변화와 그 중요도를 나타내는 지표로서의 역할을 합니다. 어떻게 버전을 명명하고 관리하는지에 따라 개발 및 배포 프로세스의 투명성과 효율성이 크게 달라질 수 있습니다. 밑에서 버전 번호에 대한 설명을 이어가도록 하겠습니다.

Semantic Versioning (SemVer)

구조: MAJOR.MINOR.PATCH

1. MAJOR: 주요 변경 사항이 있을 때 증가합니다.
   • 예: API 호환성이 깨지는 변경이나 큰 구조 변경
   • 예시: 2.0.0 -> 기존 버전과 호환되지 않는 큰 변화가 있음
2. MINOR: 새로운 기능이 추가되거나 미세한 변경 사항 있지만 기존 기능과 호환성을 유지할 때 증가합니다.
   • 예: 새로운 기능 추가, 성능 개선
   • 예시: 2.1.0 -> 호환성을 유지하며 새로운 기능이 추가됨
3. PATCH: 버그 수정과 같은 작은 변경 사항이 있을 때 증가합니다.
   • 예: 버그 수정, 사소한 기능 개선
   • 예시: 2.1.1 -> 기존 기능에 영향을 주지 않는 작은 수정

• 1.0.0 - 소프트웨어의 첫 메이저 릴리즈 버전
• 1.5.3 - 1.0.0 버전 이후에 호환되는 새로운 기능이 5번 추가되었고, 그 과정에서 호환되는 버그가 3번 수정되었음을 나타냅니다.

프리릴리즈 (Pre-release)

프리릴리즈 버전은 일반 버전 번호 뒤에 하이픈(-)을 붙여 나타냅니다. 이는 아직 완전하지 않거나 안정되지 않은 버전을 나타내며, 알파(alpha), 베타(beta), 릴리즈 후보(rc: release candidate) 등으로 표시합니다.

• 예시: 1.0.0-alpha, 1.0.0-beta.1, 1.0.0-rc.1
• 1.0.0-alpha는 1.0.0 정식 버전보다 이전의 미완성 버전임을 의미합니다.

빌드 메타데이터 (Build Metadata)

빌드 메타데이터는 버전 번호 뒤에 더하기(+) 기호를 붙여 추가합니다. 이는 빌드 시점이나 환경 등의 추가 정보를 제공하지만, 버전 순서에는 영향을 미치지 않습니다.

• 예시: 1.0.0+linux, 1.0.0-alpha+001
• 1.0.0+abc와 1.0.0+xyz는 동일한 버전으로 간주됩니다.

Date-based Versioning

날짜 기반 버전 관리 방식은 버전 번호를 날짜로 명명합니다. 이는 주로 빠른 개발 주기를 가진 프로젝트에 유용하며, 사용자가 소프트웨어의 최신 상태를 쉽게 파악할 수 있도록 돕습니다.

• 예시: 2023.08.08
• 주요 장점: 버전 릴리즈 날짜를 명확하게 알 수 있음. 이는 특히 빠른 개발 주기를 가진 프로젝트에서 유용하며, 사용자가 소프트웨어의 최신 상태를 쉽게 파악할 수 있게 해줌.
• 단점: 변화의 크기나 중요성에 대한 정보가 부족함

GitHub에서의 버전 관리

GitHub에서는 Tag 기능을 통해 버전을 관리할 수 있으며, 이를 통해 릴리즈 노트를 제공하고 소스 코드를 다운로드할 수 있습니다. 또한, Pull Request를 기반으로 자동으로 릴리즈 노트를 작성할 수 있는 기능도 제공됩니다.

 

GitHub Releases

1. Release 페이지: 프로젝트의 Release 페이지로 이동합니다.
   • URL 예시: https://github.com/{username}/{yourprojectname}/releases
2. 새 릴리즈 생성: "Create a new release" 버튼을 클릭합니다.
   • 태그를 입력하고, "Generate release notes" 버튼을 클릭하여 릴리즈 노트를 자동으로 생성할 수 있습니다.
3. 릴리즈 관리: 생성된 릴리즈는 자동으로 해당 브랜치의 헤드에 태그가 생성되며, 릴리즈 노트가 작성됩니다.
   • Pull Request의 제목을 잘 작성하면 자동 생성된 릴리즈 노트도 유용하게 활용할 수 있습니다.

---

더 다양한 브랜치 관리 전략(GitLab Flow, Trunk Based Development)

GitLab Flow

GitLab Flow는 GitHub Flow와 Git Flow의 장점을 혼합하고 CI/CD 환경에 최적화된 브랜치 전략입니다.

구조:

• main 브랜치: 항상 배포 가능한 상태를 유지합니다.
• feature 브랜치: 기능별로 분리하여 개발을 진행합니다.
• environment 브랜치: 특정 환경에 배포하기 위해 사용합니다. 예: QA, stage, production.

특징:

• environment 브랜치: 다양한 서버 환경 (QA, 스테이징 등)을 관리하는 브랜치. 각 환경에 코드가 병합되면 해당 환경으로 배포가 이루어지도록 CI/CD 파이프라인이 구성됩니다.

장점:

• CI/CD 파이프라인과 통합이 쉽습니다.
• 다양한 배포 시나리오와 프로젝트 요구에 유연하게 대응 가능합니다.
• 각 브랜치의 역할이 명확하여 팀원 간 협업을 원활하게 할 수 있습니다.

단점:

• 초기 학습 곡선이 높습니다.
• 브랜치 간 동기화와 머지 작업에 추가적인 관리 노력 필요합니다.

활용법:

• CI/CD를 적극 활용하고, 여러 환경에서 테스트와 배포 작업을 자주 하는 경우.
• 구조화된 브랜치 전략을 원하는 경우.

Trunk Based Development

Trunk Based Development는 간결하고 빠른 릴리즈 주기를 목표로 하는 브랜치 관리 전략입니다.

구조:

• main (또는 trunk) 브랜치: 주요 개발 활동이 이루어지는 브랜치입니다.
• 짧은 수명의 feature 브랜치: 필요 시 생성되며 가능한 빠르게 main 브랜치로 병합합니다.

특징:

• feature toggle: 특정 기능을 활성화/비활성화할 수 있도록 구현, 아직 완성되지 않은 기능을 main 브랜치에 머지할 때 feature toggle을 통해 비활성화할 수 있습니다.
• 짧은 Pull Request 주기: 작은 단위의 기능도 빠르게 main에 병합합니다.

장점:

• 코드 베이스에 큰 변화가 일어나는 것을 방지할 수 있습니다.
• 배포에 대한 리스크 줄일 수 있습니다.

단점:

• 개발자들이 자주 커밋하고 테스트해야 합니다.
• 빠른 배포 주기에 대한 부담을 줄 수 있습니다.

활용법:

• 빠른 피드백과 반복적인 배포를 통해 제품의 품질을 높이고 사용자의 요구에 민첩하게 대응해야 하는 경우.

---

Github를 활용한 협업 자동화

---

.Github 디렉토리로 시작하는 협업 자동화

GitHub는 개발자들의 협업을 극대화하기 위해 다양한 도구와 기능을 제공합니다.

그중에서도 .github 디렉토리는 프로젝트와 관련된 설정, 템플릿, 워크플로우 등을 정의하여 일관성 있게 규칙을 적용하고 코드에 대한 기여를 표준화하는 중요한 역할을 합니다.

이 디렉토리를 활용하여 구현되는 다양한 기능을 밑에서 설명하겠습니다.

Code Owner 기능

Code Owner는 특정 파일 또는 디렉토리에 책임자를 지정하여 코드 변경 시 자동으로 리뷰어가 되도록 하는 기능입니다.

설정 방법:

1. 프로젝트 루트에 .github 디렉토리를 생성합니다.
2. .github/CODEOWNERS 파일을 생성합니다.
3. 다음과 같이 파일에 책임자를 지정합니다.

# 특정 파일에 대한 책임자 지정
README.md   @username

# 디렉토리 전체에 대한 책임자 지정
/docs/     @organization/doc-team

# 패턴을 통한 책임자 지정
/src/*   @organization/python-team

# 레포지토리의 모든 코드에 대한 책임자 지정
*   @username

주의 사항:

• @username은 프로젝트의 협업자로 추가되어 있어야 합니다.
• 팀(@doc-team, @python-team)은 조직 내 팀이어야 하며, 팀 멤버들도 협업자로 추가되어야 합니다.

확인 방법:

• 커밋 후 GitHub에서 코드 소유자가 올바르게 지정되었는지 확인할 수 있습니다.
• Pull Request 생성 시, 지정된 Code Owner에게 자동으로 리뷰가 할당됩니다.

Pull Request 템플릿 기능

Pull Request 템플릿은 PR을 생성할 때 일관된 형식을 제공하여 리뷰어가 목적과 변경 사항을 명확하게 파악하도록 돕는 기능입니다.

설정 방법:

1. .github 디렉토리 내에 PULL_REQUEST_TEMPLATE.md 파일을 생성합니다.
2. 다음과 같이 템플릿을 작성합니다.

## PR 요약:
- PR의 주요 변경 사항

## 변경 사유:
- 변경이 필요한 이유나 배경

## 체크리스트:
- [ ] 코드의 변경 사유와 목적이 명확하게 기술되었나요?
- [ ] 새로운 단위 테스트가 추가되었나요? 기존 테스트는 모두 통과하는가요?
- [ ] 변경된 코드가 기존 기능에 영향을 주지 않도록 설계되었나요?
- [ ] 변경된 파일에 대한 문서나 주석이 업데이트되었나요?
- [ ] 코드의 스타일과 컨벤션을 준수하였나요? (예: PEP8, ESLint)

## 추가 사항:
- 리뷰어에게 알려야 할 추가적인 정보나 주의 사항

확인 방법:

• Pull Request 생성 시, 위에서 작성한 템플릿이 자동으로 적용됩니다.
• 템플릿을 통해 모든 필요한 정보가 포함된 Pull Request를 쉽게 작성할 수 있습니다.

추가적인 템플릿:

• 여러 종류의 Pull Request 템플릿을 제공하려면 .github/PULL_REQUEST_TEMPLATE/ 디렉토리를 생성하고, 여기에 여러 .md 파일을 추가합니다.

---

Github Workflow

GitHub Workflow는 위의 개념들과 다르게 브랜치 관리 전략이 아니지만 위에서 셜명한 브랜치 관리 전략을 지원해 줄 수 있는 강력한 툴입니다.

그리고 GitHub Actions를 활용하여 코드 변경에 반응하거나 특정 조건에서 다양한 작업을 자동으로 수행할 수 있는 기능입니다. 이를 통해 CI/CD를 구축하고 작업을 자동화할 수 있습니다.

Workflow와 YAML 파일

Workflow는 GitHub 프로젝트 내 .github/workflows 디렉토리에 YAML 파일 형식으로 저장됩니다. YAML (YAML Ain't Markup Language)은 간단하고 읽기 쉬운 구조로 데이터를 표현하는 언어입니다.

워크플로우 YAML 파일의 기본 구성

1. name: 워크플로우의 이름을 지정합니다.
2. on: 어떤 이벤트에 워크플로우를 실행할지 정의합니다.
3. jobs: 실행할 작업들을 정의하는 섹션입니다. 각 작업은 여러 단계로 나눌 수 있습니다.

워크플로우 예제

다음은 기본적인 워크플로우 예제입니다. 이 파일을 .github/workflows/example.yaml에 저장하고 커밋, 푸시합니다.

name: Basic Workflow Example

on: [push]

jobs:
  example_job:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Print Hello
      run: echo "Hello, GitHub!"

설정 후:

1. GitHub 리포지토리의 Actions 탭에서 워크플로우 실행을 확인할 수 있습니다.
2. Actions 탭은 리포지토리의 좌측 상단에 위치합니다.

워크플로우 YAML 파일 분석

1. name: 워크플로우의 이름은 "Basic Workflow Example"입니다.
2. on: push 이벤트 발생 시 워크플로우가 실행됩니다.
3. jobs: 하나의 작업 example_job이 정의되어 있습니다.
4. runs-on: 작업이 ubuntu-latest 환경에서 실행됩니다.
5. steps: 각 작업은 여러 단계를 가집니다.
   • Checkout code: 리포지토리를 클론하고 체크아웃합니다.
   • Print Hello: "Hello, GitHub!" 메시지를 출력합니다.

Steps의 속성

워크플로우를 작성할 때 가장 많이 사용하는 것이 steps입니다. 주요 속성은 다음과 같습니다:

1. name:
   • step의 이름을 지정합니다.
   • 로그에서 표시됩니다.
2. run:
   • 해당 step에서 실행할 shell 명령어나 스크립트를 지정합니다.
   • 여러 줄 명령어를 실행할 수 있습니다.
3. uses:
   • 특정 Action을 사용하도록 지정합니다.
   • 예: uses: actions/checkout@v3
4. with:
   • uses로 지정한 Action에 전달할 인수나 설정 값을 지정합니다.

이 외에도 env, if, continuous-on-error, timeout-minutes 등 다양한 속성을 활용해 워크플로우를 구성할 수 있습니다. 자세한 내용은 GitHub 공식 문서에서 확인할 수 있습니다.

---

코드 리뷰와 브랜치 관리 전략, 그리고 GitHub를 활용한 협업 자동화는 현대 소프트웨어 개발에서 필수적인 요소입니다. 이를 통해 코드 품질을 높이고, 팀 내 협업을 원활하게 하며, 효율적인 배포를 가능하게 할 수 있습니다. 지속적인 학습과 실천을 통해 최적의 워크플로우를 구축하여 프로젝트의 성공을 도모할 수 있습니다.

감사합니다.

---

출처 및 참고자료 : 코드잇 사이트 강의 'Git 협업하기' https://www.codeit.kr/topics/collaborating-with-git