[Git & GitHub] 사용 방법, 협업 방법, 실무에서 사용하는 법 총 정리!

HJoo·2022년 12월 13일
MegabyteSchoolgitgithub개발자취업부트캠프국비지원교육내일배움카드메가바이트스쿨패스트캠퍼스
0

TodayStudy

목록 보기
1/111
post-thumbnail

221213

Git 사용법

git은 파일의 버전 관리 프로그램이다.

파일을 버전 관리가 가능한 영역으로 등록하고, 파일의 버전을 등록하여, 그 버전들 사이의 이동이 자유롭게 한다.

Git 시작하는 법

1. git으로 관리할 폴더 생성 후 git 시작하기

git init

2. git으로 관리되는 파일 지정하기

git add (파일명)
git add . - '현재' 폴더의 내부 파일, 폴더 전체에 대한 수정사항 반영
git add A - git으로 관리되는 '모든' 파일에 대한 수정사항 반영
git status - git으로 관리되는 파일 보기

3. (처음 git을 설치하면 실행할 코드) 이메일과 유저명 등록하기

4에서 commit할 때 함께 기록될 정보

git config --global user.email "(유저 이메일)"
git config --global user.name "(유저명)"

4. 현재 관리중인 파일을 하나의 버전으로 저장하기

자유롭게 작성해도 되지만 실제로는 구체적으로 어떤 수정을 거쳤는지 작성해야한다.
기본적으로 "커밋 타입: 동작이름/함수이름"

git commit -m"(커밋 메세지)"

Git으로 버전 되돌리는 법

1. 버전 확인하기

지금까지 거쳐간 모든 수정사항/commit된 버전들을 확인

git log
git log --oneline

2. 버전 되돌리기

  • git revert (커밋명)를 통해 되돌리기

    현재까지의 commit 기록을 유지하면서 특정한 commit '이전으로' 되돌리는 명령어
    '되돌아가고 싶은 commit'이 아닌 '되돌리고 싶은 commit'의 이름을 적어야 한다.
    revert도 커밋으로써 저장되기 때문에 커밋 메세지도 작성해야한다.

    vim이라는 텍스트 편집기 모드에서 사용하는 명령어

    • esc -> i : 커서가 있는 부분부터 파일 내부의 내용을 작성, 수정할 수 있다.
    • esc -> dd : 커서가 있는 부분의 행을 삭제한다.
    • esc -> :wq : 파일을 저장하면서 에디터를 종료한다
    • esc -> :q : 파일을 저장하지 않고 에디터를 종료한다.
  • git reset (커밋명) 을 통해 되돌리기
    특정 커밋으로 돌아가면서, 그 커밋 이후의 커밋 기록을 삭제하는 명령어
    '되돌아가고 싶은 commit'의 이름을 적어야 한다.
    git reset --soft (커밋번호) : 이후 로그는 삭제되지만 수정사항은 그대로 둔다. 
							 단순히 commit 전 상태로 두는 것(staging 영역)
git reset --hard (커밋번호) : 이후 로그도 삭제하고 수정사항도 완전히 삭제한다.
그 외에
git reset HEAD^ : 가장 최근 커밋이 취소
git reset HEAD~2 : 뒤의 숫자 만큼의 커밋이 최근부터 취소
git reset --mixed : soft와 비슷하지만, 이후 수정사항들을 commit 이전으로 돌리는 것이 아닌 add 이전으로 되돌림

GitHub 사용법

GitHub 시작하는 법

Git 이 단순히 버전을 기록하고, 관리하는 도구라면,

GitHub 는 이 기록들을 온라인 상에 업로드하고, 보관할 수 있게 해주는 서비스이다.

1. Repository 만들기

github의 repository의
를 클릭하여 새로운 repository를 생성한다.


repository name을 설정하고 public으로 설정한다.

2. GitHub의 Repository에 git 등록하기

지금까지 만든 Git 저장소를 온라인상의 저장소인 GitHub에 등록한다.

repository를 생성하면 나오는 주소를 복사하여 VScode의 터미널에 아래와 같이 입력한다. 

git remote add origin (github repo 주소)

앞으로는 git에 저장된 commit 기록들을 올리려면 아래 코드만 실행하면 된다.
브랜치명은 기본적으로 master

git push origin (브랜치명)

GitHub로 협업하는 방법

1. Collaborator 로 등록하기(git clone으로 진행할 경우)

생성한 github repository를 함께 이용할 사람을 등록한다.

초대하고자 하는 사람의 계정을 입력한다.
초대받은 사람은 해당 계정의 메일에서 초대를 수락해야 한다.

2. git clone으로 협업하기

public으로 등록된 repo라면 누구나 git clone을 통해 컴퓨터로 받을 수 있고
private으로 등록된 repo라면 collaborator로 등록이 되어있어야만 가능하다.

git clone은 단순히 다운로드 받는 것이 아닌 지금까지 등록된 모든 기록과 역사를 전부 가져오기 때문에, git reset 등의 명령어를 통해서 이전 기록으로 돌아갈 수도 있고 git pull, gut push 등을 통해서 이 repo에 수정사항을 반영하거나 내려받을 수 있다는 것이다

git clone (repo 주소)

위 코드를 실행하면 현재 폴더에 클론한 폴더가 생성된다.
cd 명령어를 이용하여 해당 폴더로 꼭 이동한 후

git pull origin master

위 코드를 실행하면 다른 곳에서 push 된 수정사항을 반영시킬 수 있다.
반대로 push로 내 수정사항을 repo에 올리기도 가능!

3. git fork로 복제하기

단순히 다른 사람의 저장소를 복제하여 내 github저장소에 새로 만드는 방법
파일 뿐만 아니라 commit 기록까지 모두 복제한다.

clone과 다른 점은 결국 내 컴퓨터로 받아오는 것은 내 repo라는 점!

오른쪽 상단의 fork 클릭

create하면 내 repo로 생성 완료

  • 만약 원본 저장소에 수정사항이 발생했을 경우 그 수정사항을 내 컴퓨터에 반영하고 싶을 때는,
git remote add upstream (원본 repo 주소)

코드를 실행하여 "upstream"으로 원본 저장소를 지정해두고,

git pull upstream (브랜치명)

수정사항을 pull하여 받아올 수 있다!

  • 내 저장소에 push하는 것은 
git push origin (브랜치명)

위 코드를 실행한다.

  • 내 컴퓨터의 수정사항을 원본 저장소에 반영하고 싶을 때는
    일단 push 하고 보면,

    1 commit ahead 라는 버튼이 생긴다.
    이를 클릭해보면

    나의 수정사항을 반영해 줄 것을 요청하는 버튼이 생긴다.
    원본 주인이 이 요청을 받아들일 경우 원본 파일에 내 수정사항이 반영된다.

221214

Branch를 통한 개발관리 방법

1. branch 란

git 자체의 기능으로 '분기' 라는 의미를 갖고 있다.

버전 관리를 분기한다는 것은 현재 작업중인 상태(커밋 기록, 파일) 그대로, 아예 별도로 관리되는 새로운 폴더를 하나 더 만드는 것

  • 브랜치를 새로 만들 때에는 항상 현재 작업중인 브랜치가 있어야 한다.
  • 기본적인 브랜치의 이름은 master, main으로 사용 권장
  • 현재 작업중인 내용을 유지하면서, 파일과 커밋 기록을 별도로 관리하고자 할 때, 브랜치를 분기하게 된다.
  • 브랜치를 분기하게 되면, 그때부터는 파일과 커밋 기록이 완전히 별도로 관리된다.

현업에서는, 하나의 프로젝트의 세부기능을 브랜치로 각각 만들어서 별도로 관리하며 개발을 진행한다. 개발이 완료되면 그 브랜치를 하나로 통합해서 서비스를 완성하는 방식

2. branch 사용법

기본적으로 브랜치의 이름은 master이지만 main으로 사용하길 권장.

  • default 브랜치 이름을 변경하려면 
git config --global init.defaultBranch (변경할 브랜치 이름)
  • 현재 사용중인 브랜치의 이름을 다른 이름으로 변경하려면
git branch -m (변경할 브랜치 이름)
  • 브랜치를 새로 만들면서 분기를 전환하고 싶다면
git switch -c (새로운 브랜치 이름)
  • 현재 존재하는 모든 브랜치들을 확인하고 싶다면
git branch --list
  • 브랜치를 삭제하고 싶다면
git branch -D (삭제할 브랜치명)

3. Branch 병합하기 - merge

main 브랜치에 다른 브랜치의 수정사항을 반영하기 위해서 merge를 진행한다.

git merge (지금 있는 브랜치에 합치고 싶은 브랜치의 이름)
  • merge된 로그를 시각적으로 보고 싶을 때
git log --graph --decorate --oneline

merge를 진행할 때 다양한 conflict가 발생될 수 있다.
두 브랜치에 다른 내용이 같은 자리에 있다면 무엇을 선택하여 main에 남길지 결정해야함!

  • accept current change 를 선택한다면 현재있는 브랜치, 즉 main 브랜치의 내용을 선택
  • accept incoming change 를 선택한다면 병합하는 브랜치의 내용을 선택
  • accept both changes 를 선택한다면 두 브랜치의 내용을 모두 선택(main이 윗줄)

  • 만약 분기되었지만 main 브랜치는 수정사항이 없고, 분기된 브랜치에 수정사항이 있을 때 그냥 merge한다면?
    분기되지 않은 것처럼 main으로 커밋 기록이 만들어진다.
    -> 이런 상황을 fast-forward 라고 한다.

  • 커밋 기록을 꼭 남기고 싶다면?

git merge develop --no-ff

--no-ff 코드를 추가하여 분기를 유지한다.
보통은 분기 기록을 남긴다.

4. Branch 정렬하기 - rebase

특정 브랜치를 base(기준)로 놓고, 커밋 이력을 정렬하는 것

위처럼 브랜치를 나누었을 때

'main'을 기준으로 'rebase develop'을 실행하면
develop의 커밋 이력을 base로 해서 거기에 이어져서 main의 커밋 이력이 정렬된다.

즉 merge되지 않고 하나의 줄기처럼 커밋 이력이 정렬된다.

  • 병합을 위한 방법이 아니고, 커밋 히스토리를 정렬하기 위한 명령어다.
    이미 병합이 되었더라고 거기서 rebase를 하면 커밋 이력을 다시 정렬할 수 있다.
  • 단순히 커밋 이력을 관리하고 싶을 때는 rebase, 변경 이력을 모두 남기고 싶을 때 merge
  • 보통은 merge만 사용

rebase를 할 때에도 conflict가 발생할 수 있다.

  • merge의 경우 수정 후 바로 add, commit을 진행하면 되지만
  • rebase의 경우 수정 후 add, 그리고 
git rebase --continue

를 진행해야 한다.

  • rebase에서 merge conflict가 발생했을 때 rebase를 취소하고 싶다면
git rebase --abort

5. GitHub에서 Branch 활용하기 - pull request

pull request란 '내 담당 브랜치에서 작업이 완료되었으니, 이 브랜치의 코드를 가져가서 병합해주세요' 라는 요청을 보내는 것
잘못된 코드가 main에 바로 merge되는 것을 방지하고자 동료들의 코드리뷰가 끝난 후 검사가 완료되면, 관리자가 병합 요청을 승인하여 그때서야 merge를 시키는 것이다.

Pull Request를 하는 이유

  • 내가 작성한 코드가 바로 merge될 경우 발생할 수 잇는 문제를 미리 방지
  • 현재 코드에 대한 코드 리뷰를 진행
  • 프로젝트에 대한 진행상황을 관리
git push origin (내가 수정을 진행한 브랜치 이름)

위 코드를 실행하면 해당 브랜치의 수정 내용이 github로 올라가게 되고 해당 레포에 가면

다음과 같은 버튼이 뜬다.

버튼을 클릭하면 요청서를 작성할 수 있고, 예를 들어 다음과 같은 내용을 포함하게 작성한다.

  • 현재 PR 요약/개요
  • 코드 변경 이유 (작성 이유)
  • 관련 스크린샷
  • 테스트 내용
  • 리뷰 관련 요청사항

files change에서 코드 라인별로 comment를 남길 수 있고, 바꿀 것이 없다면 approve(승인)를 한다.

모든 수정이 다 이루어졌다면

Pr을 merge하게 된다.
merge는 커밋으로 남기 때문에 커밋 메세지를 작성한다.

merge된 브랜치는 삭제할 수 있다.

삭제해주는 이유는 이미 해당 브랜치에서 할 작업은 끝났기 때문에, 삭제해서 정확히 우리가 작업을 진행 중인 브랜치만 남겨서 확인하기 위함이다.

Pr 완료 후 내 컴퓨터에 내용을 반영하려면 아래 코드를 입력한다.

git pull origin main

github 상에서 브랜치를 삭제했지만 컴퓨터에선 인식을 하지 못한다
두가지의 브랜치가 있는데

  • origin/ 이 붙은 github 상의 브랜치를 제거하려면
git fetch --prune
  • 그 외의 브랜치는 로컬 브랜치이고 이를 제거하려면
git branch -D (),(),() 하나하나 입력해준다

Pr에서 merge conflict가 발생했을 경우 해결방법

git switch (base 브랜치)
git pull origin (base 브랜치)
git switch (head 브랜치)
git merge (base 브랜치)

을 입력하면 conflict를 해결할 수 있다.

221215

프로젝트 진행 상황 관리 방법

1. issue, label, milestone 개념

  • issue는 앞으로 구현할 기능 / 버그 수정 등의 할 일을 정리하는 용도로 사용
  • label은 이 issue가 어떤 카테고리에 해당되는지 알려주는 역할
  • milestone은 issue의 집합으로

2. issue 사용법

  • milestone을 작성하여 모든 작업을 아우르는 제목과 완성 기한, 설명을 작성한다.

  • label로 가서 팀마다 필요한 label을 만든 후 사용한다.

  • new issue를 클릭하여 새로운 issue를 생성한다.

    제목을 현재 진행할 작업을 간단히 표현 "Feat: ~"으로 작성하고
    내용에 해당 작업의 세부 작업으로 무엇이 있는지 체크리스트 형태로 관리할 수 있도록 작성
    assignees로 작업자 지정
    label로 해당 작업의 카테고리를 지정
    milestone으로 해당 작업이 어느 일정에 속하는 지 지정
    issue close를 누르면 issue가 close되고 진행 상황의 %가 채워짐

  • issue 와 pull request 함께 사용하기

  1. issue 마다 부여되는 이슈 번호를 기억!

  2. issue 이름에 맞춰 브랜치를 생성하고 add, commit 후 해당 브랜치를 push 한다.

  3. pull request를 등록한다.

    다음과 같이 close #(이슈 번호) 를 꼬리말에 꼭 입력
    이후 merge까지 완료가 된다면 issue가 자동으로 close됨

close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved 등의 단어를 사용해도 됨

3. wiki 작성

wiki에는 업데이트 사항을 기록할 수 있고
서비스 소개(readme.md에 다 적지 못한 부분), 서비스 기능, 매뉴얼, 해당 프로젝트에 기여할 수 있는 방법을 작성

공부 내용을 정리하는 wiki로 사용해도 굿

4. GitHub actions 사용법

  • 특정 이벤트가 발생했을 때 자동으로 특정한 작업이 실행되도록 하는 기능
  • 메인으로 특정한 브랜치가 merge되었을 때 자동으로 main 브랜치에 있는 코드가 서버에 배포하는 등
  • CI/CD 자동 빌드 및 자동 배포 가능
  • 테스트

5. 실습 - 다같이 readme.md 작성하기

나의 실수
1. 브랜치를 나누고 브랜치를 pull request 한 후에 실수로 바로 merge를 했다
2. 바로 revert를 해서 merge를 취소했다
3. 닫힌 이슈를 reopen했다
4. 다시 파일을 add하고 commit 하려는데 수정사항이 있어야 해서 다시 내용을 추가했다
5. 후에 add, commit을 했고 pr을 했는데 conflict가 발생하여 merge가 되지 않았다

내 생각
push 전에 pull을 안했나.. 안하면 push 자체가 안되지 않나?
revert를 github에서 하는 것을 추천하지 않는다고 했는데 이런 이유였던 것 같다
앞으로 머리속에서 구조를 잘 생각하고 revert 후의 결과를 미리 생각하고 대처해야겠다

현업의 Git/GitHub

1. Git 관리 전략

trunk - 기본적으로 하나의 중심 브랜치로만 관리하는 것
trunk based flow - trunk에서 필요할 때만 브랜치를 분기하는 것

  • 현업에서 사용하는 방식
  1. Git Flow

총 5 종류의 브랜치를 활용
master, develop은 영구적으로 존재
hotfix, release, feature는 필요할 때마다 브랜치를 만들고 merge가 되면 삭제한다

전체적인 merge순서는 feature - develop - release - master
항상 --no-ff 옵션을 붙인다

    • master(main) 브랜치: 소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치
      release 브랜치로부터 pull request 받는다
      부모 브랜치: -
      자손 브랜치 (분기해서 생성되는 브랜치): hotfix, develop
      PR받는 브랜치 (pull request 받는 브랜치): release
      PR나가는 브랜치 (pull request 보내는 브랜치): -
    • hotfix 브랜치
      배포된 서비스에 대한 긴급 버그 수정을 진행하는 브랜치
      hotfix 브랜치는 만들 때 hotfix-* (hotfix-1) 과 같은 형태로 이름을 지정해서 만든다
      수정이 완료되면, develop 과 master 브랜치 각각에 pr 을 날린다
      부모 브랜치: master
      자손 브랜치: -
      PR받는 브랜치: -
      PR나가는 브랜치: develop, master
    • release 브랜치
      배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치
      release 브랜치는 만들 때 release-* (release-1) 과 같은 형태로 이름을 지정해서 만든다
      테스트가 정상적으로 완료되면, develop 과 master 브랜치 각각에 pr 을 날린다. pr merge 가 완료되면, 브랜치를 삭제
      부모 브랜치: develop
      자손 브랜치: -
      PR받는 브랜치: -
      PR나가는 브랜치: develop, master
    • develop 브랜치
      개발 단계의 코드가 있는 (개발의 중심) 브랜치
      개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 develop 브랜치로 pr 을 날린다. 이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, develop 브랜치를 베이스로 해서 테스트를 위한 release 브랜치를 새롭게 만든다
      부모 브랜치: master
      자손 브랜치: feature, release
      PR받는 브랜치: feature
      PR나가는 브랜치: -
    • feature 브랜치
      특정한 기능 (단위 기능) 을 구현하는 브랜치
      feature 브랜치는 만들 때 feature/* (feature/기능명) 과 같은 형태로 이름을 지정해서 만든다
      기능 구현이 완료되면, develop 브랜치로 pr 을 날린다. merge 되면 브랜치는 삭제
      부모 브랜치: develop
      자손 브랜치: -
      PR받는 브랜치: -
      PR나가는 브랜치: develop
  • 큰 규모의 팀
  • 퀄리티 보장이 중요한 프로젝트
  • release 된 프로젝트에 대한 관리 사이클이 긴 경우
  • 작은 규모의 팀 또는 빠른 개발과 업데이트가 중요한 서비스에서는 오히려 비효율적으로 작용
  1. GitHub Flow

딱 두 종류의 브랜치만 사용
배포용 브랜치인 master, 각 단위 기능 구현을 위한 브랜치인 feature로 구성
feature 브랜치는 merge 후에 삭제

    • master 브랜치 (main 브랜치)
      소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치 (해당 브랜치는 push 를 받으면 자동으로 실제 서비스로 배포되도록 설정되어있다)
      feature 브랜치에서 단위 기능 구현이 완료될 때마다 pull request 를 받는다 (여기서 해당 브랜치를 merge 하기 전에 테스트)
      부모 브랜치: -
      자손 브랜치 (분기해서 생성되는 브랜치): feature
      PR받는 브랜치 (pull request 받는 브랜치): feature
      PR나가는 브랜치 (pull request 보내는 브랜치): -
    • feature 브랜치
      특정한 기능 (단위 기능) 을 구현하는 브랜치
      feature 브랜치는 만들 때 git flow 보다 더 구체적으로, 명확하게 작업명을 작성해서 만든다 (단순히 feature/* 가 아니라 버그 해결인지, 기능 추가인지 등을 명확히 명시)
      기능 구현이 완료되면, master 브랜치로 pr 을 날린다. merge 되면 브랜치는 삭제
      부모 브랜치: master
      자손 브랜치 (분기해서 생성되는 브랜치): -
      PR받는 브랜치 (pull request 받는 브랜치): -
      PR나가는 브랜치 (pull request 보내는 브랜치): master
  • 작은 규모의 팀
  • release 된 프로덕트에 대한 관리 사이클이 짧은 경우 (업데이트 주기가 짧은 경우)
  • 빠른 배포와 관리가 필요한 경우
  1. Gitlab Flow

Gitlab Flow 는 4종류의 브랜치를 사용

github flow 는 테스트를 위한 브랜치가 없고, 배포용 브랜치가 따로 없기 때문에 큰 규모의 서비스에는 적합하지 않다. 그래서 github flow 의 단순함과 git flow 의 체계적인 관리를 합쳐서 절충적으로 git 을 활용하는 방식이 바로 gitlab flow

pre-production 브랜치가 테스트를 담당하고, master 브랜치가 개발용 브랜치 담당
feature 브랜치는 다른 flow 와 마찬가지로 merge 되면 삭제

    • production 브랜치
      소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치
      pre-production 브랜치로부터 pull request 받는다.
      부모 브랜치: master
      자손 브랜치 (분기해서 생성되는 브랜치): -
      PR받는 브랜치 (pull request 받는 브랜치): pre-production
      PR나가는 브랜치 (pull request 보내는 브랜치): -
    • pre-production 브랜치
      배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치
      테스트가 정상적으로 완료되면, production 과 master 에 각각 pr 을 날린다.
      부모 브랜치: master
      자손 브랜치: -
      PR받는 브랜치: master
      PR나가는 브랜치: production, master
    • master 브랜치 (main 브랜치)
      개발 단계의 코드가 있는 (개발의 중심) 브랜치
      개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 master 브랜치가 pr 을 받는다. 이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, pre-production 으로 pr 을 날린다.
      부모 브랜치: -
      자손 브랜치: feature
      PR받는 브랜치: feature, pre-production
      PR나가는 브랜치: pre-production
    • feature 브랜치
      특정한 기능 (단위 기능) 을 구현하는 브랜치
      브랜치명은 github flow 처럼 자세하게 작성
      기능 구현이 완료되면, master 브랜치로 pr 을 날린다 merge 되면 브랜치는 삭제
      부모 브랜치: master
      자손 브랜치: -
      PR받는 브랜치: -
      PR나가는 브랜치: master
  • 중간 규모의 팀
  • 퀄리티 보장이 중요한 프로덕트
  • 빠른 배포와 관리가 필요한 경우
  • 스타트업 규모에서는 gitlab flow 정도가 적절
  • git flow는 브랜치가 조금 많은듯함
    이름이 헷갈리지 않게 gitlab flow에서 이름만 다음과 같이 하면 될듯

2. Git commit convention 정하기

커밋 메세지
git commit -m""과 같이 적은 내용은 사실 커밋 메세지의 제목에 해당함
제목과 내용을 모두 입력하고 싶다면 git commit 라고만 입력하면 vim 편집기가 실행되어 전체 커밋 메세지를 작성할 수 있다
제목은 간단하게 해당 커밋의 목적을 요약해서 작성

  • 메세지 규칙 -

    1. 제목과 본문은 한 줄을 띄워서 작성한다.
    2. 제목은 영문 기준 50자 이내로 작성한다.
    3. 제목 첫글자는 무조건 대문자로 작성한다.
    4. 제목 끝에 마침표(.)는 찍지 않는다.
    5. 제목은 개조식 (영어라면 명령문) 으로 작성한다. (Update code, Fix bug 등으로만 작성, 만약에 한글로 작성한다면 ‘abc 함수 수정’ 과 같은 식으로)
    6. 본문은 영문 기준 72자마다 줄바꿈을 한다.
    7. 본문은 무엇을, 왜 에 맞춰서 작성한다.

  • 제목 규칙 -

    1. 50자 이내
    2. 시작할 때는 대문자로 시작 (보통 Fix, Add, Change 등의 명령어로 시작)
    3. 마칠 때 마침표 등의 특수문자 없이 작성,
    4. 개조식으로 작성
    5. “타입: 내용” 의 형식으로 작성

    그리고 단순히 제목의 내용만 적는 것이 아니라,
    앞에 Feat: 이라는 단어가 붙어있는데, 이는 해당 커밋의 타입을 명시

    • Feat : 새로운 기능 추가
    • Fix : 버그 수정
    • Env : 개발 환경 관련 설정
    • Style : 코드 스타일 수정 (세미 콜론, 인덴트 등의 스타일적인 부분만)
    • Refactor : 코드 리팩토링 (더 효율적인 코드로 변경 등)
    • Design : CSS 등 디자인 추가/수정
    • Comment : 주석 추가/수정
    • Docs : 내부 문서 추가/수정
    • Test : 테스트 추가/수정
    • Chore : 빌드 관련 코드 수정
    • Rename : 파일 및 폴더명 수정
    • Remove : 파일 삭제

  • 본문 규칙 -

    1. 한 줄 당 72자 이내
    2. 아무리 길어도 괜찮으니, 최대한 상세히 작성
    3. 무엇을, 왜 변경했는지 작성 (코드 자체를 상세히 적는 것은 지양)

  • 꼬리말 규칙 -

    1. 꼬리말은 어디까지나 선택 사항입니다.
    2. “유형: 이슈번호” 형식으로 작성
    3. 유형은 “Close, Fix, Resolve” 등을 활용 (보통 Close 는 일반 개발 이슈를 닫을 때, Fix 는 버그 이슈를 닫을 때, Resolve 는 문의나 요청사항에 대한 이슈를 닫을 때 사용)

3. issue, pull request template 만들기

폴더 내부에 .github 폴더를 만들고
폴더 내에 issue_template.md, pull_request_template.md 파일을 만든다

그럼 github에서 해당 파일에 작성한 템플릿이 issue, pr을 만들 때 자동으로 입력되어 나타난다
github 내에서 만들 수 있음

4. branch protection 사용하기

main 브랜치에 에러가 있는 브랜치를 바로 merge하는 것을 방지하기 위해서 미리 방지해야 한다.

설정에 들어가서

왼쪽에서 branches 를 선택하고 add rule

보호하고자 하는 브랜치의 이름/패턴을 입력

아래 7가지 옵션을 선택

  1. merge 이전에 pull request 가 필요 (pull request 를 통해서만 해당 브랜치로 merge 가능)
  2. 테스트 결과 (status check) 이상이 없을 시에만 merge 가능
  3. 코드 리뷰에 달린 conversation 이 모두 해결 (resolve) 된 경우에만 merge 가능
  4. 커밋이 sign 되어있어야함 (gpg key 를 가지고 commit 한 경우만 허용)
  5. 분기되지 않고 선형 이력을 가져야 함 (merge commit 자체가 불가능 → 즉, 하나의 이력으로 정리된 경우만 허용)
  6. 배포가 성공한 경우에만 merge 가능 (특정 브랜치를 deploy 용으로 환경을 만들어놓은 경우에만 의미가 있음)
  7. 그 누구도 위 보호 옵션을 우회 (bypass) 할 수 없음 (심지어 github repo 관리자도)

→ 일반적으로 사용하게 될 옵션은 1, 3, 7

1번 옵션의 경우 체크를 하면,

require approvals 는 총 몇번의 approval 코드 리뷰가 필요한지 정하는 옵션
dismiss stale pull request approvals ~~ 는 새로운 리뷰 가능한 커밋이 push 되면 그 이전의 approval 을 자동으로 삭제하는 옵션
require review ~ 는 지정된 코드 관리자로부터 필수적으로 리뷰를 받도록 하는 옵션
→ 여기서는 require approvals 만 사용

그 아래 있는 두가지 옵션은 절대 체크 금지

1번과 7번에 체크를 하게 된다면 바로 merge가 안되고 pr을 이용해야만 함 (추가적으로 옵션 체크로 조건 추가)
그리고 관리자 또한 절대 우회 불가

5. 중요한 파일 숨기는법

git으로 관리되고 있는 폴더에 .gitignore 파일을 생성하고 파일 내부에 숨기고자 하는 파일명을 입력

만약 .gitignore 작성 전에 add, commit을 진행했다면?

git rm -r --cached .

을 입력해서 캐시 제거

6. 협업 과정 총 정리

  1. 우리 팀만의 git 관리 전략 (flow), commit convention, issue/pr template, issue label 을 정한다.
  2. 팀장은 해당 template 등을 적용한 github repo 를 생성한다. (+ 팀원을 등록한다.)
  3. 앞으로 구현할 작업을 기능 단위로 세분화한다.
  4. 기능 단위의 작업에 대해 각자 담당을 정하고, 각 담당자는 github 에 해당 기능에 대한 issue 를 생성한다. (+ 팀장은 작업기한을 정해서 milestone 을 생성한다.)
  5. 팀장은 github repo 에 최초 commit/push 를 진행한다. (이후 branch protection 을 설정한다.)
💡 혹시나 발생할 수 있는 merge conflict 를 막고자, 팀장은 여기서 앞으로 구현할 기능에 대한 파일들/폴더 트리 (물론 지금은 빈 파일) 까지 모두 생성한 상태로 최초의 push 를 진행 (개발 경험이 없다면 이 부분은 어려울 수 있기에 skip해도 됨)
  1. 팀원은 해당 repo 를 clone 받아서, 각자 기능에 대한 branch 를 생성하고, 작업을 진행한다.
  2. 작업이 완료되면 main 브랜치로 pull request 를 날린다.
  3. 팀원들은 pull request 된 코드를 보고 코드 리뷰를 남긴다. 수정사항이 모두 해결이 되면 approval 코드 리뷰를 남긴다.
  4. 팀장은 approval 코드 리뷰가 있는 pull request 에 대해 merge 를 진행한다.
profile
HJoo
안녕하세요. Chat JooPT입니다.
다음 포스트

[IntelliJ#1] 인텔리제이로 Todo 리스트 만들기

0개의 댓글