✔ 브랜치 (Branch)

: 소프트웨어를 개발할 때에 여러 개발자들이 동일한 소스코드를 공유하며 동시에 다양한 작업을 할 수 있게 만들어 주는 기능

• 각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경할 수 있음
• 분리된 작업 영역에서 변경된 내용은 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있음
• 브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념
  필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있음
  

브랜치 사용

1. 새로운 기능추가

• Main 브랜치의 경우 정상적으로 동작하는 안정적인 브랜치이기 때문에 새로운 기능을 추가할때는 Main 브랜치의 최신 커밋으로 부터 새로운 브랜치를 생성해서 개발

• 이때 개발, 코드리뷰, 테스트까지 모두 완료해서 이상이 없으면 Main 브랜치로 병합

2. 버그 수정

• 버그가 발생하면 Main 브랜치로 부터 새로운 브랜치를 생성해서 작업

• 이때 브랜치 이름은 hotFix , 또는 bugFix 같은 이름을 사용
• 버그 수정이 끝나면 Main 브랜치로 병합
• 새로 개발한 내용을 Main 브랜치로 병합할때 버그 수정으로 인해 충돌이 생길 수 있기 때문에 주의

3. 병합과 리베이스 테스트

• 병합과 리베이스는 입문자에게 가장 까다로운 일 임, reset 명령을 이용해서 언제든지 취소 할 수 있지만 어려울 수 있음

• 이 때 임시 브랜치를 만들어서 병합과 리베이스 테스트를 해보면 편리함
  잘못되었을때 그냥 브랜치를 삭제하면 됨
  

4. 이전 코드 개선

• 이미 구현은 완료되었는데, 코드가 마음에 들지가 않아서 함수의 로직을 개선하고 싶을때 주석처리하고, 그 아래 새로운 개선 코드를 작성하기보다 브랜치 사용할 수 있음

• 새로운 브랜치를 만들어 이전 코드는 삭제하고 새 코드를 작성하면 다른 브랜치에 이전 커밋이 잘 돌아가는 코드가 남아있어 걱정할 필요가 없음

5. 특정 커밋으로 돌아가고 싶을때

• 이미 저장되어있는 특정 커밋으로 돌아가고 싶을때 일반적으로 hard reset 나 revert 를 사용함
But 효과적인 방법으로 브랜치를 생성하는 방법이 있음

• hard reset의 경우 커밋이 없어질 수 있기 때문에 추천하지 않고, revert는 사용이 조금 까다로운데, 이 때 브랜치를 만들어서 작업하고, 이후 리베이스나 병합을 사용하는 것이 좋음

Git Branch 전략

Git Branch 전략

1) main
운영 환경에 최종 배포가 되는 프로젝트를 담는 브랜치

2) develop
배포하지는 않았지만, 기능 개발을 완료한 프로젝트를 담는 브랜치
- master 브랜치로부터 파생

3) feature
필요한 각 기능을 작업하는 브랜치
- ex) feature/기능
- develop 브랜치로부터 파생.
- 해당 브랜치에서 작업을 완료하면 develop 브랜치로 병합

4) release
최종 배포 전 통합 테스트를 할 프로젝트를 담는 브랜치
- develop 브랜치로부터 파생
- 테스트 중 발견한 버그 수정
- 테스트가 완료되면 master 브랜치와 develop 브랜치에 병합

5) hotfix
운영 환경 중 발견된 버그를 수정할 때 사용하는 브랜치
- main 브랜치로부터 파생
- 버그 수정 후 master 브랜치와 develop 브랜치에 병합

메인 브랜치(항시 유지) : master, develop
보조 브랜치(머지 후 삭제 ) : feature, release, hotfix

Git Flow 그림

Branch merge시 Code Quality를 위한 CI 연동사항

브랜치 병합 시 코드 품질을 보장하기 위해 CI(Continuous Integration) 연동을 통한 다양한 검증 절차를 설정
→ 코드의 품질과 안정성을 높임

1. 정적분석 : 정적 분석 도구를 사용하여 코드 품질을 분석하고, 잠재적인 문제를 조기에 발견

2. 리그레션 (단위 테스트) : 기존 기능이 새로운 변경 사항에 의해 영향을 받지 않는지 확인

   • Lev1 : 엔진핵심 로직이나 알고리즘에 대한 단위 테스트 (JUnit, PyTest, NUnit)
     - 개별 함수, 메서드의 정확성
   • Lev2 : 기능 주요 기능의 동작을 검증하는 테스트 (Selenium, Cypress)
     - 기능의 동작 확인
   • Lev3 : Full Test : 전체 시스템 통합 테스트(Selenium, JMete)
     - 시스템의 통합된 동작

3. 코드리뷰 : 동료 개발자가 코드를 검토하고 피드백 제공

✔ GIT 계정 여러 개 사용

자격증명관리자

1. 자격 증명 관리자에서 git에 대한 정보 확인 가능
   
2. 편집을 눌러 사용자 정보 바꾸어가며 사용하는 방법

✔ 소규모 협업

1. 팀 프로젝트 생성 (팀장)

• 모든 팀원이 공통적으로 사용하는 라이브러리, 설정 등을 원격 레파지토리에 올림

  예시)

  • 팀원들이 사용할 라이브러리
    : maven - pom.xml, gradle - build.gradle
  • 기본 설정파일
    : application.property 세팅
  • 기본 설정
    : Spring security, JWT 등

2. 메인브랜치 보호세팅 (팀장)

• Branch name pattern에 보호 할 브랜치명 작성
• Require a pull request before merging (PR요청)
  : Merge 하기 전 pull request 요청하도록
  • Require approvals
    PR을 병합하기 전에 특정 수의 승인이 필요하도록 설정할 수 있음
    

• 팀장은 main, dev 를 승인 없이 push 가능
• 팀원은 main, dev 브랜치를 승인 없이 push 할 수 없음
  - 팀원은 별도의 브랜치 (topic 브랜치)를 생성후 push 하고 merge 요청(PR : Pull Request)
• 팀장 이 승인후 dev 브랜치에 머지
• dev 브랜치에 머지후 topic 브랜치를 삭제

3. 팀원 추가 (팀장)

4. invite 승인 (팀원)

5. 프로젝트 클론받기 (팀원)

• $ git clone 원격레파지토리주소

6. 브랜치 생성 및 작업 (팀원)

• 주의점 : 별도의 브랜치를 만들어 작업해야 함 (main 브랜치는 보호되어있음)

1) 브랜치 확인 및 생성

• $ git branch : 현재 브랜치 확인 (위치한 브랜치는 *로 표시)

• $ git branch 새 브랜치 명 : 내가 위치한 브랜치에서 커밋된 정보를 복사한 브랜치 생성
  

• $ git checkout 브랜치명 : 해당하는 브랜치로 작업 이동

• main 브랜치에서 새로운 브랜치를 생성 시,
  main 브랜치의 작업 내용 새로운 브랜치가 그대로 받아왔음을 git log에서 확인 가능
  

2) 작업 후 커밋

• 작업 후 개발자 브랜치에 push (현재는 임의로 dev에서 작성함)

  • 작업을 main에서 하지 않도록 git branch로 작업 브랜치 확인하기
  • 만약 main에서 실수로 작업했다면 main에서 별도의 새로운 브랜치를 만들어 push 해야함

6. pull request 요청 (팀원)

• dev_ggr 브랜치에서 main 브랜치로의 merge를 요청
  

7. pull request 확인 후 승인 (팀장)

• 어떤 브랜치에서 어떤 브랜치로의 merge 요청인지 확인
  
  
• 변경사항 확인 후 Merge pull request 체크 후 클릭
  
• confirm merge 하면 main에 merge 됨
  

⇒ 새로운 변경사항이 main에 병합되었다는 것 팀원에게 알리기

9. 기존 브랜치는 삭제하고 병합된 main 가져오기(팀원)
1) 병합된 main 가져오기

• main으로 checkout 하고
• $ git pull origin main
  

2) main에 통합한 개발자 브랜치 삭제

• $ git branch -d 삭제할브랜치
  

• 팀장이 pull request 승인 후 해당 브랜치 삭제할 수 있음
  

3) pull 한 main에서 새 브랜치 생성 후 작업