[Git & Github] 14. Git 협업 워크플로우

Critical     ● 중앙 집중형(단일 브랜치) 작업의 문제     ● 피처 브랜치의 워크플로우     ● 풀 리퀘스트(Pull Requests, PR)     ● 포크(Forks)     ● 포크와 클론의 워크플로우 Important     ● 브랜치 보호 규칙

 

중앙 집중형 워크 플로우에서는 모든 사람이 단일(주로 main) 브랜치에서 작업한다.

원격 및 로컬 저장소에서 단일 브랜치를 사용한다면 협업에 큰 문제가 생길 수 있다.

 

예를 들어서 미완성된 작업물에 대해 도움을 받기 위해 공유를 위해서 push를 하게 되면 브랜치가 하나밖에 존재하지 않기 때문에 미완성된 작업물 그대로 브랜치에 커밋이 되어버린다. 이렇게 되면 모두가 미완성된 작업물을 가지게 되므로 아주 큰 문제가 발생한다.

 

브랜치가 단일로 존재하기 때문에 어느 누구도 기본 코드를 건드리지 않고서는 작업할 수가 없다.

게다가 커밋 충돌이 너무 자주 일어나기 때문에 시간의 낭비도 심해진다.

---

 

위와 같은 문제는 피처 브랜치를 사용함으로써 해결할 수 있다. 각자의 작업을 종류나 중요도에 관계 없이 개별 브랜치에서 수행하면 된다.

 

미완성된 작업을 push하더라도 브랜치가 다르기 때문에 main 브랜치에 영향을 주지 않고 해당 작업을 받아서 협업하는 쪽도 fetching을 하기 때문에 main 브랜치나 자신이 작업중인 브랜치에 전혀 영향을 미치지 않는다.

 

일반적으로 main 브랜치는 언제나 배포 가능한 상태로 유지한다.

 

 

 

* 풀 리퀘스트(Pull Requests, PR)
피처 브랜치에서 작업한 내용은 언젠가는 누군가에 의해 main 브랜치로 병합이 될 것이다.
다만 여기서 누구나 main 브랜치에 push 및 merge를 하게 된다면 문제가 발생하기 때문에 작업물 검토를 요청해서 병합을 승인하거나 반려해달라고 할 수 있다.

movie 브랜치의 병합을 요청한다

 

브랜치를 병합할 때, 빨리 감기 또는 충돌에 의한 병합 커밋이 만들어 지는 것을 알고있다.

PR 역시 병합이기 때문에 충돌 발생 시 처리를 해주어야 한다.

파일이나 수정사항이 몇개 되지 않는다면 깃허브의 웹 상에서 처리 할 수 있지만 작업량이 많다면 깃허브에서 처리하는 것은 불편하므로 로컬에서 처리하는 것이 편할 것이다.

 

기본적인 처리 과정은 로컬에서 빨리 감기 여부와 관계 없이 병합 커밋을 만들어서 main 브랜치에 push하는 것이다.

 

추가로 PR은 깃의 기능이 아니라 깃허브같은 원격 저장소의 기능이다.

---

 

* 브랜치 보호 규칙 설정

 

브랜치 보호 규칙은 특정 브랜치(예: main)에 대해 강제적인 규칙을 설정하여 변경을 제한하는 기능이다. 예를 들어, 코드를 직접 푸시하는 것을 금지하거나, Pull Request 없이 병합되지 않도록 하는 등의 조건을 걸 수 있다.

 

🛠️ 설정 방법 (과정 설명)

1. 저장소의 Settings 메뉴로 이동

    ● Github 저장소 우측 상단의 Settings 탭 클릭

2. 좌측 메뉴에서 Branches 선택

    ● Code and automation 카테고리 아래의 Branches 클릭

3. [Add branch ruleset] 클릭

    ● 보호 규칙이 없다면, 버튼을 클릭해 새 규칙을 생성한다.

4. 규칙 이름 입력 (Branch name pattern)

    ● 예: main, release/* 등

    ● *를 사용하여 와일드 카드 패턴도 설정 가능

5. 옵션 예시들

    ● ✅ Require a pull requests before merging : PR 없이는 병합 금지

    ● ✅ Require status checks to pass before merging : 테스트/빌드 통과 여부 확인

    ● ✅ Include administrators : 관리자에게도 규칙 적용

    ● ✅ Restrict who can push to matching branches : push 가능한 사용자 제한

 

---

 

* 2025-04-30 현재 브랜치 보호 규칙을 작성하는 방법이 강의와 약간 달라 추가 서술

 

1. 메뉴로 접근 > branch ruleset 추가

Settings > Branches > Add branch ruleset

 

2. Ruleset 이름 작성

Ruleset 이름 설정

 

3. Ruleset 활성화/비활성화 설정

해당 규칙에 대해 활성화/비활성화 설정

 

4. Bypass list 설정

 

어떤 규칙이든 반드시 예외 사항은 필요하기 때문에 해당 규칙을 무시할 수 있는 목록을 설정할 수 있다.

여기서 어드민 역할이나 저장소의 할당된 역할을 Bypass 목록에 추가할 수도 있고 해당 조직에서 사용하는 팀이나 앱을 지정하는 것도 가능하다. 이렇게 추가한 Bypass 목록은 항상 허용할지 Pull Request에서만 허용할지도 지정할 수 있다.

For PR only

 

5. Target Branch 설정

 

default 브랜치나 모든 브랜치 혹은 위에서 서술된 패턴에 해당하는 브랜치들을 ruleset 적용 시킬 수 있다.

 

6. 제한 사항 적용 후 branch ruleset Create

 

필요한 제한사항을 체크 후 Create 버튼을 클릭해 branch ruleset을 만든다.

---

 

* Fork란?

다른 원격 저장소를 나의 원격 저장소로 복사한다.

클론이 원격 저장소를 나의 로컬 저장소에 복사하는 것이라면 포크는 원격 저장소를 나의 원격 저장소에 복사하는 것이다. 둘의 차이는 클론은 공동 작업자로 등록되지 않는 이상 push 권한이 없다는 것이지만 포크는 나의 원격 저장소이기 때문에 권한이 있다.

 

마치 로컬-원격의 관계처럼 원격-원격 관계가 성립한다. 정확히는 로컬-원격-원격일 것이다.

그렇기 때문에 포크해온 나의 원격 저장소에 변경된 작업을 push하고 해당 브랜치를 원래 프로젝트에 PR할 수도 있다.

 

기본적으로 원격 저장소에 참여해서 push할 권한을 가지려면 공동 작업자로 등록하는 절차가 반드시 필요하다.

하지만 규모가 매우 큰 오픈 프로젝트의 경우라면 매번 공동 작업자로 등록하는 절차가 번거로울거이다. 이 때, 원격 저장소를  포크해서 변경사항을 PR한다면 기여자로써 등록이 된다.

 

Fork 역시 PR과 마찬가지로 깃의 기능이 아니다.

 

Fork > Create a new fork

 

원격 저장소를 Fork 하려면 위 이미지처럼 동작시키면 된다.

Fork한 원격 저장소에서 일정 작업을 마친 후, 원본 원격 저장소에 PR을 생성시켜주고 싶다면 Pull requests 메뉴에서 PR을 생성하면 된다.

---

참고

1) https://www.udemy.com/course/best-git-github

2) https://erikanes.tistory.com/376

[Git & Github] 14. Git 협업 워크플로우

3) https://blog.outsider.ne.kr/1724

GitHub의 조직 차원에서 저장소에 적용할 규칙을 관리할 수 있는 Repository Rules :: Outsider's Dev Story