코딩하는 폴제트

tag는 release 버전을 서버에 배포할때 조작한다.

• github repository에서 조작할 수 도 있고 local respository에서도 조작할 수 있다.

과정

1. develop에서 나가는 release 브랜치 생성
   • master: 제품으로 출시될 수 있는 브랜치
   • develop : 다음 출시 버전을 개발하는 브랜치
   • release : 이번 버전으로 출시하는 브랜치
   • hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
   • git checkout -b relase develop
2. 이후 커밋한 내용은 이번 버전에 넣을 내용일 경우 release에 넣고 다음 버전에 넣어도 될 개발은 develop에 넣는다.
3. release를 master에 merge한다
   • [master] git merge --no-ff release
     • merge된 모든 커밋이 표시되며 Merge branch 'release' into master 문이 생성된다
4. master branch에 tag를 붙인다.
   • git tag -a 1.0.0
5. origin master에 push 한다.
6. develop에서는 master를 rebase한다
   • 다른회사의 gitflow를보면 develop에서도 위와같이 rebase없이 merge 하지만 이러면 merge message가 두개 뜨게되어 보기 좋지않기때문에 본인은 rebase를 택했다.

예시

develop의 rebase master 없이 merge하는 경우와 rebase 한 경우와 비교를 해보자.

먼저 다음의 공통 상황이후부터 차이가 시작된다.

1. master와 develop에 commit 1이 다음과 같이 들어있다
2. 새로운 개발 commit develop 2가 들어왔다.여기서 이제 새로운 버전을 생성하기로 하고 release branch를 열었다.
3. 이번 버전에 급하게 release하기위한 commit release 3가 생겨 release branch에 commit 했다.
   

   

   

no rebase

1. 이제 버전을 tag하기 위해 release를 develop과 master에 merge했다. 이후 release branch는 삭제한다.
2. 버전 업그레이드를 할 시기가 또 왔다. 현재 develop에는 develop 4 가 commit 되어있고 이 내용을 위와같이 release한 결과는 mster와 develop이 각각 다음과 같다.
   

   

   

yes rebase

1. 이제 버전을 tag하기 위해 release 를 master에 merge한후 develop에는 master를 rebase 한다. 이후 release branch는 삭제한다.
2. 버전 업그레이드를 할 시기가 또 왔다. 현재 develop에는 develop 4 가 commit 되어있고 이 내용을 위와같이 release한 결과는 mster와 develop이 각각 다음과 같다.
   

   

   

지금까지 회사업무로 인해 issue 관리 툴로 atlassian의 jira를 사용해 왔다. 팀원들간 개발내역 및 내가 하고 있는 일을 쉽게 공유 할 수 있기때문에 협업 프로젝트를 하면서 꼭 필요한 툴이라고 생각한다.

하지만 큰 프로젝트가 아닌 작은 프로젝트를 하는데 과연 다른 사이트에 회원가입 및 스페이스를 따로 열면서 까지 해당 툴로 이슈 관리를 해야할 필요가 있을지 의문을 가지게 되었다.

마침 깃으로도 이슈관리를 할 수 있다는 사실을 알았고 깃을 이용한다면 Repository 를 여는 순간 이슈관리 스페이스를 따로 생성할 필요가 없고 별도의 회원가입 및 프로젝트 팀원의 권한관리를 할 필요가 없다는 점에서 작은 프로젝트를 하기엔 jira보다 편할것이라고 생각했다.

그럼 깃으로 프로젝트를 관리하는 방법을 평소 하나의 이슈가 발급되고 닫힐때 까지 과정을 바탕으로 순서대로 알아보도록 하자.

1. 이슈 발급

 - 이슈 탭 활성화 및 이슈 템플릿(양식) 생성

  먼저 이슈를 발급하기 위해서는 먼저 깃에 이슈 발급 환경을 구성해야한다.

  세팅에 들어가서 이슈 탭 활성화 및 템플릿을 설정하도록한다.

  여기서 추가되는 템플릿은 나중에 이슈 생성 시 등록 양식으로 사용할 수 있다.

  Bug report와 Feature request 템플릿은 깃에서 제공하는 템플릿이고

  Custom issue template은  사용자가 직접 작성한 양식을 지정할 수 있는 템플릿이다.

 - 이슈 발급

  이슈 발급은 다음과 같이 하면된다.

  이후 위에서 지정한 추가한 템플릿을 선택 후 이슈 내용을 작성하여 이슈를 발급하면된다.

2. 이슈 관리

  이슈를 열었으면 이제 이슈를 관리할 수 있어야한다.

  이슈 관리의 핵심 요소는 크게 다음과 같다.

• Asignee : 이슈 해결을 전담 받은 사람
• Labels : 이슈 카테고리 (ex, bug, new feature, question
• Status : 이슈의 상태 (ToDo, In Progess, Done)

  먼저 Asignee와 Label은 이슈 생성단계 및 Issue 설정 정보에서 등록/수정 가능하다.

 Status 관리를 위해서는 Project(jira에서는 Epic에 해당) 등록을 한다. Project는 Jira에 Epic 해당한다고 보면 좋다. Jira의 Epic은 task(issue) 의 모음이다.

 각 이슈는 Project에 등록을 할 것이며 각 이슈의 status 또한 Project 내에서 관리하게 될 것이다.

 git Repository안에 프로젝트를 생성한다

생성된 Project내에 Add column 버튼을 사용하여 Project내 등록된 이슈의 관리 방식(Status)을 정의한다. 일반적으로는 Todo, In Progress, Done의 3단계 형식으로 관리한다.

이 때 내가 Project에 등록한 Issue의 status를 Isuue 또는 Pull Request가 Open됐는지 Close 됐는지에 따라 자동으로 바꿀 수 있게 지정할 수 있다. 이 기능을 깃에서는 Manage automation이라 부른다. 

이제 다시 Issue 돌아와 새로 생성된 Project에 해당 Issue를 등록하도록 한다. 만약 Issue를 새로 생성할 단계라면 생성 화면에서 Project에 할당할 수 있다. 

만약 해당 이슈에 대한 개발을 바로 시작할 것이라면 Project의 Isuue Status Dropdown을 눌러 해당 이슈의 status를 IN PROGRESS로 바꿔주면 된다. 그렇지 않다면 TO DO에 넣으면 된다. 

3. Pull Request

특정 이슈의 Asignee가 개발을 끝낸 후 Repository에 해당 이슈에 대한 commit을 push 한후 Pull request가 발생했다.

깃에서는 Jira에서와 마찬가지로 이 Pull Request 또한 이슈와 연동할 수 있다.

Jira는 commit 메시지의 제목을 읽어 자동으로 연동해주는 반면 깃은 commit message의 제목을 읽지않고 subMessage를 읽어 해당 연동작업을 할 수 있다.

PullRequest와 Issue의 연동을 위한 Commit subMessage의 구성은 기본적으로 다음과같다.

● [keyword]: #[이슈번호]

[keyword]는 Pull request의 특정 액션에 따라 Issue를 처리할 방식을 결정할 메시지고,

[이슈번호]는 해당 Pull Request와 연동하고자하는 이슈번호다.

이렇게 commit message로 연동한 이슈는 연동된 Pull Request를 merge할 때 자동으로 close 된다.

해당 Pull Request가 어떤 성격을 지녔는가에 따라 다르게 keyword를 선택하면된다. (보통의 기능 추가라면 keyword 로 resolves를 사용하고 이미 만든 기능의 버그 수정이라면 fix를 사용하면된다.)

 keyword의 종류는 다음과 같다.

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

평소 git branch, checkout, add, commit, pull, push, reset, rebase, merge, stash 와 git IDE으로 부족함 없이 git을 사용하여 왔기 때문인지 git 명령어에 대한 공부가 게을러졌다.

저 위의 명령어들외에 그나마 빈번히 쓰였던 cherry-pick에 대해 알아보고 어떤 상황에서 사용하는지 어떻게 사용하는지 알아보자.

cherry-pick이란

cherry-pick이란 다른 브랜치 위에 있는 커밋을 선택적으로 내 브랜치에 적용시킬 때 사용하는 명령어이다.

좀더 쉽게 그림으로 설명하자면

다음과 같이 commit 상황을 가지는 Master 브랜치와 Feature 브랜치가 있다. 

 a - b - c - d   Master
         \
           e - f - g Feature

Master 브랜치에 Feature의 e와 g를 뺀 f 커밋만 merge 하고 싶다.

이 경우 cherry-pick을 사용하지 않고 f 커밋만 merge 할 수 있을까?

1. git checkout Feature; git rebase master; git checkout master; // 사전 rebase 처리

2. git merge Feature //master에 Feature branch 가져오기

a - b - c - d - e - f - g   Master
         \
           e - f - g Feature


3. git reset --hard f //master g commit 삭제

a - b - c - d - e - f   Master
         \
           e - f - g Feature


4. git reset --soft e //master f commit 해제 및 코드변화 가져오기

a - b - c - d - e   Master (staged: f code changes)
         \
           e - f - g Feature


5. git stash //master f 코드변화 따로 저장 및 보호

a - b - c - d - e   Master (git stash list: f code changes)
         \
           e - f - g Feature


6. git reset --hard d //master e commit 삭제

a - b - c - d   Master (git stash list: f code changes)
         \
           e - f - g Feature


7. git stash pop //master f 코드변화 불러오기

a - b - c - d   Master (staged: f code changes)
         \
           e - f - g Feature


8. git commit f 

a - b - c - d - f   Master (staged: f code changes)
         \
           e - f - g Feature

최소 총 8번씩이나 git 명령어를 입력해야 이를 해결 할 수 있다. 이를 cherr-pick 을 사용한다면 단 한번의 명령어로 원하는 커밋을 merge 할 수 잇다.

1. git checkout master

2. git cherry-pick 76ae30ef // 76ae30ef: Feature f commit의 id

다른 브랜치의 커밋을 그대로 가져온다는 점에서 rebase와 개념적으로 겹치는 부분이 있다. 그래서 rebase를 사용할 줄 안다면 더욱이 cherry-pick이 없는 불편함을 크게 느끼지는 못했을 수 있다.

하지만 프로젝트 규모가 크고 많은 사람들이 코드를 수정하여 변화가 빈번하다면 rebase만으로는 한계가 있을 수 있다. cherry-pick을 기억해두도록 하자.

cherry-pick 필요한 상황 및 사용 이유

그럼 cherry-pick을 어떤 경우에 사용하게 될까?

기본적으로 수정해야 할 commit이 다른 commit들 사이에 껴있는 경우와 같이 수정 시 많은 reset을 필요로 할 때 cherry-pick이 빛을 발한다.

1. 커밋을 다른 브랜치에 잘 못했을 때 이를 뒤늦게 찾은 경우
2. 요구사항이 바뀌어 필요없는 커밋이 생겼을 경우
   • 해당 커밋들을 빼고 cherry-pick
3. 수정사항이 생겨 두개의 브랜치에 동시 commit 해야할 경우
   • 어느 한 브랜치에 커밋 후 다른 브랜치에서 cherry-pick
4. 코드 의존성 때문에 다른 사람의 커밋 중 일부를 가져와야 할 경우