github - 협업준비하기.

안녕하세요, 해당포스팅에선

깃 저장소생성부터,브랜치, review, commit (컨벤션), push, pull 까지 모두 해보는 과정을 작성해보려합니다.

정말 하나하나 다 작성할거라 글이 조금 길어지고 루즈해질 수 있는데 필요하신 부분만 찾아서 보셔도 좋을거같습니다. 

(정신없게 작성해서 가독성이 댕 구리지만 조금이라도 도움이 되기를 바랍니다..)

!!! 해당 글은 제가 혼자 공부하면서 알게된 것들이나 제가 해온 방식을 설명 드리는 것이니 절대적인 정답이 아닙니다.
브랜치 전략이나, 저장소 관리, 협업하는 방식등 회사마다, 팀마다 다 다르니 참고용으로만 봐주시길...

목차

1. 저장소 생성하기

2. 저장소 받아오기

3. 브랜치 생성하기

4. main branch merge 방지하기

5. 커밋 푸시( 커밋 컨벤션에관하여)

6. 리뷰요청, 리뷰하기

7. 스쿼시로 커밋병합하기

8. 작업이 끝난 브랜치 삭제하기

add. 이미 push가 된 상태에서 수정이 필요한 경우

 

1. 저장소 생성하기

먼저 저장소 생성하기입니다.

깃허브에 로그인후 프로필사진을 클릭해 Repositories 라는 버튼을 클릭해주자.

그럼 아래와 같은 화면이 나올텐데 저기서 초록생의 New 버튼을 클릭해주자.

 

이제 아래와 같은 화면이 보일텐데 저희는 빨간색 박스만 알아보겠습니다.. 

1. 저장소의 이름입니다. 주로 단어와 단어 사이는 "-" 으로 이어서 작성하고 소문자로 작성합니다. (참고자료 1)

2. 해당 저장소의 간단한 설명을 나타냅니다.

3. 저장소의 공개 여부를 설정합니다.

4. 기본 readme 추가 여부를 설정합니다. (만약 description이 있다면 readme에도 똑같이 작성됩니다)

저는 아래와같이 설정하고 create repository 버튼을 클릭해 주었습니다.

그럼 아래와같이 저장소가 정상적으로 생성된 것을 확인할 수 있습니다.

 

해당 방법 외에도 인텔리제이에서 바로 저장소를 생성 할 수도있습니다.

 

1-2. 팀원추가하기

다들 아시겠지만 팀원 추가 방법은 settings 에 collaborators 에 add people해서 상대반 github 이메일혹은 닉네임으로 초대를 보낼 수 있습니다.

초대 수락 방법은 내가 가입한이메일로 들어가면 메일이 와있을건데 승락 버튼 눌러주면 끝입니다.

2. 저장소 받아오기

자, 이제 깃허브에 각자만의 저장소가 생성 되었습니다.

그럼 이 저장소를 내 컴퓨터에 받아와서 작업을 해야겠죠?

여기서 깃허브에 저희가 방금 만든 저장소를 원격저장소, 내 컴퓨터에있는 깃저장소를 로컬저장소라고 부릅니다.

 

그럼 지금부터 원격 저장소를 제 컴퓨터에 옮겨와 로컬 저장소를 생성해주겠습니다.

 

먼저 생성한 저장소에서 code버튼을 클릭해주세요.

그럼 아래와 같은 창이하나 뜰텐데 복사 버튼을 클릭하여 저장소 링크를 복사 해주세요.

외에 다른 옵션들 ssh, github cli 같은 친구들은 해당 포스팅에선 사용하지 않으나, 혹시 개념적으로 궁금하신 분들은 참고자료2를 확인해주세요.

이후 cmd창을 열어서 원하는 경로로 이동해 git clone 복사한 URL 을 넣어줍니다.

그러면 뭐라뭐라 하면서 마지막에 done. 이라고 알려줄 것입니다.

(혹시 이 과정에서 에러가 발생한다면 인증관련 이슈 일 수있으니 찾아보시다 어려우시면 이슈 알려주시면 같이 해결 해드리겠습니다.)

그럼 아래 처럼 로컬 저장소가 잘 생성된것을 확인 할 수 있습니다.

3. 브랜치 생성하기

다음으로 브랜치를 생성해보겠습니다.  먼저 원격 저장소에서 브랜치를 생성 하는 방법입니다.

( 브랜치에 대한 개념은 따로 다루지 않겠습니다.)

3-1. 원격 저장소에서 브랜치 생성 및 동기화.

아래의 main을 눌러 View all branches 를 클릭합니다.

매우 감사하고 직관적이게도 new branch 라는 버튼이 보이네요 클릭해줍시다.

저는 우선 dev라는 이름의 브랜치를  생성해주고 source 는 당연히 main으로 받았습니다.

그럼 이제 dev브랜치가 생성된것을 볼 수 있습니다. 그럼 이제 끝인가?

아니오, 이제 로컬 저장소에서 원격 저장소에 생성된 브랜치를 동기화 시켜줄 것 입니다.

 

인텔리제이로 이동 해보겠습니다.

터미널에서 git branch 명령어를 입력하면 main 브랜치만 있는 것을 확인 할 수있습니다.

이는 지금 원격 저장소와 로컬 저장소가 서로 일치 하지않은 상태이기 때문입니다.

 

아래 명령어를 통해 원격 저장소 정보를 최신 상태로 갱신합니다.

git fetch origin

 

그럼 [new branch] 하면서 새로운 브랜치를 감지하고 가져온거 처럼 보입니다 

하지만 다시한번 브랜치 목록을 확인해봐도 새로운 브랜치는 생성 되지 않았습니다.

왜일까요?

여기서 fetch 명령어는 원격 저장소의 최신 커밋/브랜치 정보를 가져오고 반영하지 않기때문입니다. 

(정보 동기화(O) / 코드 반영(X))

그렇다면 왜 한번에 반영하지 않고 나눠둔 것일까요?

원격 저장소(GitHub 등)의 최신 변경 사항을 로컬 저장소로 가져오되,

현재 작업 중인 로컬 브랜치의 파일은 전혀 바꾸지 않고 안전하게 확인만 하기 위해서입니다.

원격 저장소에 있는 브랜치를 확인하기 위해 git branch -r 옵션을 사용해봅시다(원격 저장소 확인옵션)

git branch -r

dev와 main이 있는것을 확인할 수 있습니다.

 

아래의 명령어를 통해 브랜치를 만들 수 있습니다.

 git checkout -b dev origin/dev

명령어를 분석해보자면,

 

checkout : 브랜치 이동하는 명령어입니다.

-b : 옵션을 붙임으로서 생성과 동시에 해당 브랜치로 전환 하라는 의미입니다.

dev : 생성할 브랜치 이름입니다

origin/dev : 시작 지점 설정, 원격저장소의 dev 브랜치 상태를 기준으로 로컬 브랜치를 생성합니다.

그럼 여기서 드는 한가지 생각이, 그냥 fetch 없이 dev브랜치를 만들어도 동작 하는거 아닌가? -> 맞습니다.

당연히 동작은 합니다 다만, 여러 문제가 발생하지만 무엇보다 원격저장소의 origin/dev브랜치와 아무런 상관이없는 새로운 브랜치가 되는것이므로 동기화가 안된다는 치명적인 이슈가 발생 할 수 있습니다.

3-2. 로컬 저장소에서 브랜치 생성하기.

다음으로는 로컬 저장소에서 브랜치를 생성하여 원격 저장소에 동기화 시키는 방법인데, 해당 방법은 매우 간단합니다.

 

그냥 새로운 브랜치를 git checkout -b [브랜치 명] 같은 명령어를 통해 생성하고, 

해당 브랜치에서 작업 후 push하면 자동으로 생성 해줍니다.

자동으로 생성 된 브랜치.

4. main branch merge 방지하기

다음으로 다룰 내용은 merge방지하기 입니다.

이건 배경을 이해를 해야하기에 하나의 흐름을 보겠습니다.

 

1. 우리는 10명 이상이 같이 협업하는 팀입니다.

2. branch 는 main, dev, feature/1 , feature/2, feature/3 이렇게 나우어져 있습니다. main 브랜치는 운영중인 브랜치입니다.(실제 사이트)

3. 신입사원이 들어왔습니다.

4. 신입사원이 feature/1 에서 작업 후 push를 하였습니다.

5. 신입사원이  feature/1에서 dev가 아닌 main으로 pr을 요청하였습니다.

6. 신입사원이 리뷰없이 merge를 해버렸습니다. 그런데 그 코드엔 오류가있었고 서버가 터질 수 있는 치명적인 버그가 발생했습니다.

 

이런 상황이 발생한다면 정말 끔찍할것입니다, 내가 저 팀장이어도 혹은 새로들어온 신입사원이어도, 이런 끔찍한 상황을 방지하기 위해 우리는 브랜치에 merge를 함부로 할 수 없게 막는전략을 택해야합니다.

 

저장소에서 settings 에 들어가고 rulesets 에 들어가 새로운 룰을 추가합니다.

 

Ruleset Name : 해당 룰의 이름을 정의합니다, 여기선 default 로 정의하겠습니다 .

Enforcement status : 해당 규칙이 실제로 적용될지 결정하는 부분입니다.

Bypass list : 해당 규칙을 무시할수 있는 사람(권한) 을 설정합니다.

Target branches : 해당 규칙을 적용할 브랜치를 설정합니다.

 

예시,

dev = (dev 브랜치),

dev/*  =  (dev 하위 브랜치 단, dev미포함)

다음은 규칙들인데 이건 너무 많아서 따로 참고자료3 을 확인 해주세요.

일단 두가지 옵션을 켰습니다.

Require a pull request before merging 를 키면 아래 하위 옵션들이 나옵니다.

 

Required approvals : 리뷰 승인을 받아야하는 인원 수를 정할 수 있습니다.

Require approval of the most recent reviewable push :자신에 pr엔 자신이 아닌다른사람들의 승인을 받아야합니다.

 

 

이제 merge를 하려고하면 2명이상의 승인을 받기 전까지 merge를 할 수 없도록 방지할 수 있습니다.

지금은 매우 간단하게 만 막았는데 실제 실무에선 아마 훨씬 빡빡하게 제약을 둘 수 있습니다.

 

5. 커밋 푸시 ( 컨벤션 )

여기선 커밋 푸시방법이아닌 커밋 컨벤션에 대한 이야기를 하려고 합니다.

 

커밋 컨벤션이란?

커밋 메시지를 일관된 형식과 규칙에 따라 작성하기 위한 팀 또는 프로젝트의 작성 규칙입니다.

이는 가독성 향상, 커밋 히스토리 관리 등에 용이합니다.

 

컨벤션 구조입니다.

<타입>[적용 범위(선택 사항)]: <설명>

[본문(선택 사항)]

[꼬리말(선택 사항)]

 

Commit Type

Feat	새로운 기능의 추가.
Fix	버그의 수정
Refactor	코드 리팩토링
Docs	README같은 문서 편집
Style	코드 로직 변경 없이 포맷팅, 세미콜론, 공백, 린트 수정 등
Chore	빌드 설정, 패키지 관리, CI 설정 등 코드 로직과 직접 관련 없는 작업
Test	테스트 코드

 

제목은 아래와 같은 규칙을 가지고있습니다.

• 제목은 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
• 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기한다.(과거 시제를 사용하지 않는다.)
• 제목은 개조식 구문으로 작성한다. --> 완전한 서술형 문장이 아니라, 간결하고 요점적인 서술을 의미

예를들면 이런 형태로 작성하는 것입니다.

feat (auth) : 로그인 서비스 추가

feat (auth): Add login service 

 

저기서 Auth 라는 태그를 작성했는데 저건 무엇일까요? 해당 작업이 어떤 Scope (도메인,서비스) 등을 가지고있는지 나타내는 것입니다. 선택사항이지만 어떤 작업을 수행했는지 한눈에 파악하기 쉽기때문에 붙이는 것을 권장합니다.

 

본문이랑 꼬리말은 잘 사용하지 않으니 생략하도록 하겠습니다. 컨벤션의 경우 구글에 검색하면 정말 정리가 잘 된 글이 많아서 한번쯤 찾아 읽어 보시는걸 추천 드립니다.

 

6. 리뷰 요청, 리뷰 하기.

6-1. 리뷰 요청하기

리뷰 요청의 경우 매우 간단합니다.

생성한 PR 에 들어가서 reviewers 에 톱니 바퀴를 누르면 선택 할 수 있는 팀원들이 나오고 원하는 팀원들에게 요청을 보낼 수 있습니다.

아래 사진처럼 노란 불이 들어왔다면 리뷰 요청이 완료 된것입니다.(copilot 은 AI입니다.)

6-2. 리뷰 작성방법 

 

누군가 본인에게 리뷰를 요청하면 우측 상단의 프로필 옆에 파란색 알람이 떠있을 것 입니다.

박스친 곳을 보면 review requested 라는 요청이 온것을 확인 할 수 있습니다.

\

해당 PR로 들어가 Files changed 를 클릭하면 리뷰를 남길 수 있습니다. 

보면 코드줄마다 저렇게 + 할 수 있는데 여기를 클릭하면 해당 코드에 대한 리뷰를 달 수 있습니다.

 

이렇게 리뷰가 달린것을 볼 수 있습니다. 

 

두번째로 submit review 버튼을 보겠습니다. 

해당 버튼을 클릭하면 내가 해당 커밋에서 작성한 리뷰를 볼 수 있고, 

단순 댓글인 commnet

승인 approve

수정 요청 request changes 이렇게 선택하여 리뷰를 보낼 수 있습니다.

 

저희는 지금 나 이외에 다른 사람2명이 승인을 해줘야 하기때문에 제가 작성할 수 있는 리뷰는 commnet 이고 다른 팀원들은 approve 해줄 수 있습니다.

완료 하면 이렇게 승인이 된것과 설정한 인원 수 가 모두 승인했다면 merge 버튼이 활성화 된것을 볼 수 있습니다.

 

7. 스쿼시로 커밋 병합하기.

자, 저희는 지금까지 작성했던 커밋과 새롭게 여러 커밋을 만들고 dev브랜치로 모든 작업내용을 합친 뒤 테스트를 끝냈습니다.

그럼이제 dev 브랜치에 있는 모든 내용을 main으로 올려야겠지요??

위에 사진을 보면 여러개의 pr과 commit 기록들이 있는것을 볼 수 있습니다. 

이걸 그냥 merge 해볼까요??

 

main 브랜치의 커밋 기록에 모든 커밋 기록 test1,test2 merge pull request.... 모든 것들이 하나하나 나누어서 등록 된것을 볼 수 있습니다.

 

이게 만약 너무 많은 작업 내용을 올린다면, 버전관리가 쉽지많은 않아보입니다.

 

이번엔 squash and merge 라는 기능을 사용해봅시다 기존 merge 버튼의 화살표 버튼을 누르면 선택 할 수 있습니다.

스쿼시를 하면?

위에 사진처럼 Dev(#9) 라는 하나의 커밋으로 관리되는 것을 확인 할 수 있습니다.

물론 스쿼시할때도 커밋 메세지를 내가 원하는 방식으로 설정할 수 있습니다.

8. 작업이 끝난 브랜치 삭제하기.

이제 작업이 끝난 브랜치는 삭제처리 할 것입니다.

???????

아니 지금까지 열심히 만들고 똥꼬쇼 해서 겨우 만든 브랜치를 왜 삭제하고 다시 만들어????? 해당 브랜치를 동기화 시키면 되는겅아냐??

이런 의문이 들것입니다.

 

1. 브랜치는 "작업용 임시 공간" 입니다.

2. 삭제하지 않으면 레포가 점점 더러워진다.

 

• feature/login
• feature/login-v2
• feature/login-final
• feature/login-real-final
• feature/login-final-real
• ....

 

3. 동기화 가 기술적으로 가능하나 히스토리가 더러워진다.

동기화 할때 생기는 merge나 rebase도 모두 커밋 기록으로 관리 됩니다. 이는 히스토리를 더욱 복잡하게 만듭니다.

4. 충돌 지옥 발생

파일 구조변경이나 리팩토링 기능추가등으로 코드가 바뀌면 충돌이 발생하는데 그것을 해결하는 시간을 투자할 바에, 새로운 브랜치를 만들어 작업하는게 훨씬 효율적입니다.

작업이 끝난 브랜치를 삭제하는 이유는

해당 브랜치가 이미 main(또는 develop)에 병합되어역할이 끝난 작업용 브랜치이기 때문입니다.

브랜치를 계속 유지하며 동기화하는 것도 가능하지만, 오래된 브랜치를 재사용할 경우 히스토리가 복잡해지고
충돌 가능성이 높아지기 때문에
“작업 완료 → 병합 → 브랜치 삭제 → 새 브랜치 생성”
흐름을 표준으로 사용합니다.

즉, 브랜치 삭제는 코드의 삭제가 아니라불필요한 작업 공간을 정리하는 과정에 가깝습니다.

 

이유를 알아보았으니 방법을 알아봅시다. 

원격 저장소는 매우 간단합니다. 

우리가 아까 merge한 PR에 들어가 볼까요??

저장소의 Pull request에 closed 에 들어가면 볼 수 있습니다.

어머나 개이득으로 여기서 delete branch 하라고 알려주네요 친절하게. 

저 버튼 딸깍하면 원격 저장소에서 삭제됩니다.

 

그럼 이제 로컬 저장소는 어떨까요.

당연하게도 아직 남아있습니다.

 

git fetch --prune

git branch -d [삭제할 브랜치 이름]

 

위 명령어를 수행하면 정상적으로 삭제 된것을 볼 수 있습니다.

 

이제 위에 방법처럼 다시 브랜치를 만들고 작업하고 머지하고, 삭제하고 이 과정을 반복 하면 됩니다.

 

추가 작성.

이미 브랜치 PR이 올라간 상태에서 수정이 필요한 경우

만약 여러분들이 커밋만하고 작업브랜치에 push를 하지 않은경우, reset --soft 등의 기능으로 커밋을 되돌리고 작업 할 수 있습니다, 하지만 만약 이미 작업 브랜치(feature/login) 같은 브랜치에 push가된 상황이고 코드 리뷰에서 수정요청을 받았다면, 
그냥 해당 브랜치에서 수정 커밋을 더 쌓고 새 PR review 요청이 가장 안전합니다.

 

만약 이미 main에 merge가 되어있다면.. git revert 같은 명령어로 되돌리거나 마찬가지로 수정 커밋을 새로 올려서 고치는 방법이 안전합니다.

 

참고자료

1. 깃허브 이름 명명 규칙

https://coffeebaralog.tistory.com/40

[GIT] Repository 명명 규칙 및 이름 변경

2. 깃허브 SSH 사용하기

https://twosky.tistory.com/63

[Github] SSH를 통해 Git Clone 하기

3. 깃허브 rules

https://nameisris.tistory.com/47

[Git] Branch Ruleset 설정