팀플 깃 전략 (git Organizations)

우선 팀의 책임자가 Organizations을 생성한다.

팀원을 초대한 이후, new Organizations을 클릭하면 기존 우리가 사용하던 것 처럼 리포지토리를 만드는 창이 뜨는데 여기서 프로젝트 이름이나 ReadMe같은 선택을 할 수 있다. 여기서 public으로 생성하지 않으면 팀원의 잔디가 심어지지 않는다고 하니, 우리 같이 공부하는 학생들이라면 이 부분 주의해서 생성하길 바란다.

또 리포지토리에서 팀원을 다 초대해준다.

팀원의 권한에 따라서 맞는 권한을 부여하면 되는데 우리는 모두가 코딩을 하기 때문에 팀장인 내가 (깃 생성한 본인)이 자동으로 Admin이고 나는 나머지 팀원은 전부 write 권한으로 돌렸다.

만약 공동 책임자가 있다거나 하면 Maintain (리포지토리 관리)이나 Admin을 부여해줘서 깃을 같이 관리하면 된다.

프로젝트에 기존하던 것 처럼 Organizations 깃을 연결이후 master 푸쉬까지 해준다.

이제 깃 관리 전략이 무엇인가하면,

master 브랜치

우선 만약 지금 사용중인 브랜치가 메인 브랜치라면 이렇게 바꿔주고.

git checkout main
git branch -m master
git push origin master

푸쉬한다면 이런식으로 화면이 바뀌어 있을 것이다. 여기서 세팅으로 들어가준다.

세팅 탭에서 브랜치로 ㄱㄱ

Branch protection rules에서 add branch ruleset 클릭

그럼 이 설정창에서 룰의 이름을 정하고, Active(활성화)시켜준다. Targets에서 디폴트로 주면 디폴트가 master니까 그걸로 설정된다.

그 다음으로는 룰 설정을 하면 된다.

1. Restrict deletions (브랜치 삭제 제한) - 활성화

• 이 옵션을 체크하면 master 브랜치를 실수로 삭제하는 일이 없게 됨.
  브랜치 보호를 위해 필수적인 설정.

2. Block force pushes (강제 푸시 방지) - 활성화

• 강제 푸시를 막아, 실수로 master 브랜치의 기록을 덮어쓰거나, 기존 커밋을 변경하는 걸 방지할 수 있어.
  이 설정은 필수, 안전하게 푸시할 수 있게 해주기 때문.

3. Require a pull request before merging (PR 없이는 병합 불가) - 활성화

• PR을 통해서만 master 브랜치로 병합할 수 있게 설정하는 규칙.
  팀 협업 시 코드 리뷰를 반드시 거치도록 할 수 있어서 필수적인 설정.

4. Require status checks to pass (상태 체크 후 병합) - 선택 사항

• 이 옵션은 CI/CD 테스트를 통과한 후에만 병합이 가능하게 함. 만약 자동화된 테스트를 설정해두었다면 활성화하는 것이 좋음.
  하지만 CI/CD가 설정되어 있지 않다면 생략해도 됨.

난 일단 이렇게 설정을 했다.

여기 내가 작성한 3번 탭이 또 세분화 되어있어서 이해가 쉽게 예를 들어 설명을 하자면.

1. Required approvals (필수 리뷰 수)
   설정 예시: PR이 병합되기 전에 최소 1명이 리뷰를 해야 해.

• 왜 필요해?: 한 사람만 작업한 코드를 그대로 병합하면 실수가 발견되지 않을 수 있어. 그래서 팀의 다른 사람이 코드를 확인한 후 승인해야 병합할 수 있도록 하는 규칙이야.

• 쉽게 말하면: 내가 코드를 작성한 후 PR을 보내면, 팀원 중 최소 1명이 "이 코드 괜찮다!"라고 승인해야 master 브랜치에 들어갈 수 있어.

2. Dismiss stale pull request approvals when new commits are pushed (새로운 커밋이 추가되면 기존 승인은 무효)
   설정 예시: PR을 리뷰하고 승인했는데, 그 뒤에 새로운 코드가 추가되면 이전 승인은 자동으로 무효화돼.

• 왜 필요해?: 만약 코드 리뷰 후 새로운 변경 사항이 추가되면, 새로운 코드도 다시 리뷰가 필요할 수 있어. 그걸 반영한 설정이야.

• 쉽게 말하면: 내가 PR을 보냈는데 리뷰어가 승인을 해줬어. 그런데 추가로 코드를 수정해서 푸시했으면, 리뷰어는 새로 추가된 코드도 다시 확인해야 해.

3. Require approval of the most recent reviewable push (가장 최근에 추가된 코드도 승인 필요)
   설정 예시: PR에 추가된 가장 최신의 커밋도 승인받아야 병합 가능.

• 왜 필요해?: PR을 리뷰하다 보면, 여러 번의 수정이 있을 수 있어. 이 설정은 최종 수정된 코드가 꼭 리뷰를 통과하도록 보장해.

• 쉽게 말하면: 내가 여러 번 코드를 수정해서 푸시했으면, 마지막에 수정한 코드도 리뷰어가 "확인 완료!" 해줘야 master에 병합할 수 있어.

4. Require conversation resolution before merging (리뷰 대화가 해결된 후에만 병합 가능)
   설정 예시: 리뷰어가 남긴 코멘트(질문이나 수정 요청)가 모두 해결되지 않으면, 병합 불가.

• 왜 필요해?: 리뷰어가 코드에 대해 의견을 남겼을 때, 그 의견을 충분히 반영하거나 답변한 후에만 코드가 병합되도록 하는 규칙이야.

• 쉽게 말하면: 리뷰어가 "이 부분은 왜 이렇게 했어?" 같은 질문을 남기면, 대답하거나 수정해서 문제가 해결된 후에만 병합이 가능해.

솔직히 나도 잘 이해가 안되서 일단 다 체크는 했다. 사용법은 나중에 익히면 되겠지.

암튼 이렇게 룰을 생성.

이후 룰 확인을 해봤는데

---

default 가 지금 main으로 되어있는 것 발견. 난 main 쓰기 싫으니까 이걸 이제 고쳐보자.

Default 브랜치 변경 방법:

1. GitHub 리포지토리 페이지로 이동.
2. 상단 메뉴에서 Settings 탭 클릭.
3. 왼쪽 메뉴에서 General 클릭.
4. Default branch 섹션에서 현재 설정된 기본 브랜치가 main으로 되어 있을 것.
5. Default branch 옆에 있는 Change 버튼 클릭.
6. master 브랜치를 선택하고 Update 버튼을 눌러 기본 브랜치를 master로 변경.

이렇게 하면 기본 브랜치가 master로 변경됨!

바꿔주고. rule도 다시하면 확인해보자.

됐구만.

우리는 main은 아예 사용하지 않을거라. main은 아예 지워버리자.

이제 메인은 존재하지 않는 브랜치.

master의 설정은 끝났다. 이제는 develop 생성,

develop 브랜치

로컬에서 develop 브랜치를 생성하고 원격 저장소에 푸시

git checkout master  # master에서 브랜치 생성
git checkout -b develop  # develop 브랜치 생성
git push origin develop  # 원격 저장소에 develop 브랜치 푸시

이제는 테스트는 develop에서 하게 된다!!

팀원의 각자 브랜치 생성. (feature)

원래는 feature에서 기능을 각각 업로드 하는 것 같은데 그럼 브랜치가 너무 많아져서 헷갈릴 것 같으니 팀원의 각자 이니셜로 각자 분담한 내용을 기억하면 된다. (소규모라 가능할듯.)

그래서 feature는 총 네개.

일단 팀장인 나. 한영신
팀원 1 2 3, 최은서 박태은 조해령.

각각의 feature는

git checkout develop  # 먼저 develop 브랜치로 이동
git checkout -b feature-이니셜  # 이니셜로 브랜치 생성

이렇게 생성하면 된다.

나로 예를 들면

git checkout develop  # 먼저 develop 브랜치로 이동
git checkout -b feature-hys  # 이니셜로 브랜치 생성

가 된다.

푸쉬까지 완료.

이렇게 보이는데 아마 다른 팀원이 보면 your branches에는 아무것도 없을 걸로 예상된다. (두명이 해외로 떠나서 확인할 방도가 없다 ㅠㅠ)

일단 이렇게 했고. 주의 사항을 정리해서 올리자면.

---

팀 프로젝트 Git 협업 규칙

1. 브랜치 전략

• master 브랜치: 최종 배포용 코드가 있는 브랜치. 직접 작업 금지.
• develop 브랜치: 각 feature 브랜치가 병합되는 브랜치. 모든 기능 테스트 후 master에 병합.
• feature 브랜치: 팀원이 각자 기능 개발을 위해 만드는 브랜치.
  • 브랜치 명명 규칙: feature-이니셜 (예: feature-hrj, feature-ces)

2. 브랜치 생성 및 작업 규칙

• 새로운 작업을 시작할 때:

  1. develop 브랜치로 이동 후, 최신 코드를 pull 받기.

     git checkout develop
     git pull origin develop

  2. 자신의 feature 브랜치 생성:

     git checkout -b feature-이니셜

  3. 작업 완료 후 로컬에서 commit하고, 원격 저장소에 push:

     git add .
     git commit -m "작업 내용 작성"
     git push origin feature-이니셜

  4. GitHub에서 Pull Request(PR) 생성:

     • PR 대상: develop 브랜치
     • 리뷰 후 병합.

3. 작업 중 코드 충돌 방지 및 Pull 방법

• 작업 도중 다른 팀원이 develop에 병합한 경우:

  1. develop 브랜치로 이동:

     git checkout develop

  2. develop 브랜치에서 최신 코드 pull:

     git pull origin develop

  3. 자신의 feature 브랜치로 돌아가기:

     git checkout feature-이니셜

  4. develop 브랜치의 최신 변경 사항을 feature 브랜치에 병합:

     git merge develop

  5. 충돌이 발생할 경우 직접 충돌을 해결하고, 다시 commit 및 push:

     git add .
     git commit -m "충돌 해결"
     git push origin feature-이니셜

4. PR(Pull Request) 규칙

• 작업이 끝나면 GitHub에서 PR을 생성하고, 팀원들에게 리뷰 요청.
• PR 제목은 간결하게 작업 내용을 요약.
• PR 작성 시 작업한 내용을 간단히 설명하고, 리뷰어가 이해하기 쉽게 변경 사항을 정리.

5. 병합 규칙

• 모든 PR은 최소 1명의 리뷰어가 승인한 후에 병합.
• 코드 충돌이 없고 테스트가 완료된 경우에만 develop에서 master로 병합.