GitHub로 협업하기

1. Branch 전략 수립하기

1.1. Branch 전략이란

1.2. Branch 전략의 종류

• Git-flow(main, hotfix, develop, feature, release)

• GitHub-flow(main, branch)

• Feature branch(main, develop, feature)

1.2.1. Git-flow

• feature feature 브랜치는 develop 브랜치에서 생성되고 기능을 구현할 때 생성하는 기능 단위의 브랜치입니다. 생성한 브랜치에서 기능 구현을 완료하였을 경우 develop 브랜치로 기능을 더해 나갑니다. 일반적으로 feature/기능과 같은 이름을 붙입니다.
feature/add 브랜치를 생성하고 아래와 같이 2개의 수를 더해주는 코드를 작성해봅시다. 이렇게 한 기능을 구현한 뒤, develop 브랜치에 기능을 더해 나갑니다. 예를 들면, 빼기나 곱하기, 나누기 등의 기능을 추가할 때마다 push 를 하는 거죠.

//calculator.js
function add(a,b){
	return a+b;
}

• develop develop 브랜치는 feature 브랜치에서 구현된 기능이 모여 브랜치들의 기둥 역할을 하는 브랜치입니다. 일반적으로 develop과 같은 이름을 붙입니다.

//calculator.js
function add(a,b){
	return a+b;
}

function sub(a,b){
	return a-b;
}

function mul(a,b){
	return a*b;
}

function div(a,b){
	return a/b;
}

협업을 진행하는 팀원들이 사칙연산의 각 기능들을 구현하고 develop 브랜치로 구현한 기능들을 더하면, 위의 코드처럼 합쳐집니다.
 

• release release 브랜치는 develop 브랜치에서 생성되며, 실제 배포 전 테스트를 하거나 버그 확인을 하기 위한 브랜치입니다. develop 브랜치에서 계획했던 기능의 구현이 완료되었을 때, 기능 테스트 및 버그 확인을 위해 생성합니다. 일반적으로 release-1과 같은 이름을 붙입니다.

//calculator.js
function add(a,b){
  if(typeof a !== "number" || typeof b !== "number"){
		return "숫자만 입력해주세요."
	}
	return a+b;
}

function sub(a,b){...}
function mul(a,b){...}
function div(a,b){...}

위와 같이 사칙연산의 기능을 가진 서비스를 만들었습니다. release 브랜치에서 테스트하던 중 숫자를 입력하지 않았을 경우에도 계산기가 수행이 되는 버그를 확인하게 되었다고 가정해 봅시다. 이 경우, 기능을 수정한 후에 develop 브랜치로 merge 하고 다시 기존의 release 브랜치에서 배포 전 테스트 및 버그 확인을 진행합니다.
 

• main(master) main 브랜치는 release 브랜치에서 생성되며 실제 배포되는 소스의 브랜치입니다.

• hotfix hotfix는 main 브랜치를 통해 배포가 진행되었는데 문제가 발생한 경우 생성하는 브랜치입니다. main 브랜치를 통해 생성되며 문제가 해결된 이후 main 브랜치와 develop 브랜치로 merge 됩니다. 일반적으로 hotfix-1과 같은 이름을 붙입니다.

1.2.2. GitHub-flow

• main(master) main 브랜치는 배포를 위한 브랜치이며, 전략의 중심이 되는 브랜치입니다.

• (branch) (branch)는 main 브랜치를 통해 생성됩니다. 기존 Git-flow와는 다르게 명시적인 브랜치의 역할이 없는 main(master) 브랜치 이외의 브랜치입니다. 기능 구현(feature)이나 버그 해결(hotfix) 등의 브랜치 목적을 이름에 명시해주어야 합니다.

2. GitHub Projects를 사용하여 프로젝트 관리하기

💡

kanban 템플릿은 칸반보드라 불리는데, 여기서 칸반은 일본어로 ‘간판’이라는 뜻입니다. ‘눈에 보이는 신호’라는 의미로 붙여졌어요. 칸반보드는 업무 진행 단계를 보여주는 열로 구성된 가상의 보드판이며, 프로젝트를 시각적으로 관리하기에 유용한 개발 방법론의 도구입니다. 실무에서 많이 사용하는 프로젝트 관리 툴인 트렐로(trello), 노션(notion), 지라(jira)에서도 이 칸반보드를 지원하고 있죠. 그러니 현업에서 많이 활용되고 있는 칸반보드의 형태를 눈에 잘 익혀두세요!

3. GitHub Issues 생성

3.1. GtiHub Issues란?

3.2. 이슈 생성(open)하기

3.2.1. 이슈 생성 방법

1. 레파지토리 탭 메뉴의 Issues를 클릭 후 우측에 있는 New issue 버튼을 클릭합니다.

1. 이슈 제목과 내용을 작성 후 Submit new issue 버튼을 클릭하여 생성합니다. 우측의 Assigness, Labels 등을 사용하여 더 다양한 협업이 가능합니다. 자세한 내용은 아래 ‘3. 이슈 활용하기’에서 다루겠습니다.

1. 생성된 이슈에 코멘트(comment)를 남길 수 있습니다.

3.2.2. 유용한 마크다운(md) 문법

1. 권한을 부여한 작업자 태그 : @작업자id 로 직접 태그가 가능합니다.

2. 커밋 링크 : 커밋 URL을 복사하여 붙여넣으면 자동으로 커밋 id와 링크로 표시됩니다.

3. 파일 코드 미리보기 링크 (이슈와 같은 레파지토리의 파일이어야 합니다.)
• 미리보기 하고자 하는 파일로 들어가 원하는 줄을 클릭합니다.
• 다중 선택의 경우 시작 줄을 클릭 후 Shift 키를 누른 상태로 마지막 줄을 클릭합니다.
• 좌측에 생성된 메뉴 버튼(···) → Copy permalink를 클릭하여 복사된 링크를 붙여넣기 합니다.

1. 다른 이슈나 코멘트 링크 (이슈와 같은 레파지토리의 파일이어야 합니다.)
• #이슈넘버 를 직접 타이핑하거나 이슈 URL을 복사하여 붙여넣으면 자동으로 표시됩니다.
• 코멘트 링크를 복사하여 붙여넣으면 자동으로 표시됩니다.

3.2.3. 이슈 템플릿 활용하기

1. 이슈 템플릿을 만들기 위해 우선 Settings 탭으로 이동 후 스크롤을 내려 Features → Issues → Set up templates 버튼을 클릭해줍니다.

1. Add template을 누르면 아래와 같이 3개의 template을 기본으로 제공하고 있습니다. 첫 번째는 Bug 관련(Bug report), 두 번째는 기능 관련(Feature request), 세 번째는 사용자 정의 템플릿(Custom template)입니다. 원하는 템플릿을 선택합니다.

1. 선택하시면 기본 템플릿이 생성되며, 수정 및 상세 내역을 보고 싶으신 경우 Preview and edit버튼을 클릭합니다.

1. 내용 수정을 원하는 경우 제목 옆의 수정 버튼(🖋)을 눌러 내용을 수정한 후 Propose changes를 클릭합니다.

1. 이후 생성된 템플릿을 커밋합니다.

1. GitHub repository에 ISSUE_TEMPLATE이 생성되고 새로운 이슈 생성 시 Get started 버튼을 눌러 미리 만들어둔 Template을 사용할 수 있습니다.

3.3. 이슈 활용하기

3.3.1. Assignees

• 본인에게 할당할 경우 : assign yourself를 클릭

• 여러 사용자에게 할당할 경우 : 우측의 톱니바퀴(⚙️)를 클릭하여 리스트에 표시된 사용자들 클릭

3.3.2. Label

• Custom Label 생성하기
1. 이슈 탭에서 Labels를 클릭합니다.

2. New label을 클릭하여 Label name, Description(선택), Color 값을 입력하고 Create label을 클릭하여 생성합니다.

3.3.3. Projects

1. 우측의 톱니바퀴(⚙️)를 클릭합니다.

2. 리스트에 표시된 항목 중 원하는 프로젝트를 선택합니다.
• Recent : 최근에 사용한 project
• Repository : 레파지토리에 생성된 project
• User : 사용자의 project

3.3.4. Milestones

• Milestone 생성하기
1. 이슈 탭에서 Milestones를 클릭하고 이동한 페이지에서 New milestone을 클릭합니다.





 
1. Title, Due date(선택), description(선택)을 입력하고 Create milestone을 클릭하여 생성합니다.

 
1. 완료하면 아래와 같이 표시됩니다.

3.3.5. 커밋과 Issue 연결

3.4. 이슈 종료(close)하기, 재오픈(reopen)하기

3.4.1. 이슈 직접 종료하기

3.4.2. 이슈 재오픈하기

3.4.3. 커밋 메시지로 이슈 종료하기

$ git commit -m "커밋 메시지 - close #[이슈 번호]"

$ git commit -m "커밋 메시지 - fix #[이슈 번호]"

$ git commit -m "커밋 메시지 - resolve #[이슈 번호]"

4. Git pull 전략짜기

warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull:

git config pull.rebase false  # merge (the default strategy)
git config pull.rebase true   # rebase
git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default preference for all repositories. You can also pass --rebase, --no-rebase, or --ff-only on the command line to override the configured default per invocation.

4.1. git config pull.rebase false

4.2. git config pull.rebase true

$ git config --global branch.autosetuprebase always

4.2.1 git rebase

1. main 브랜치에서 feature 브랜치를 생성하고 기능을 구현합니다.

2. main 기준으로 rebase를 실행하기 위해 브랜치를 이동합니다.

$ git checkout feature

1. main 기준으로 rebase를 실행합니다. 이때, main 기준 feature 브랜치의 git history 가 정리됩니다.

$(feature) git rebase main
First, rewinding head to replay your work on top of it...
Applying: added staged command

1. main으로 이동합니다.

$ git checkout main

1. 지금까지의 git history를 main 브랜치에 반영되도록 해줍니다.

$(main) git merge feature

4.3. git pull -ff -only

$ git pull —ff —only 

$ git config --global pull.ff only

4.4 git config 설정 초기화

$ git config --list

git config --global --unset [지울 항목]