이번 포스팅에서는 실제 업무에서 master branch를 base로 hotfix branch를 끊어서 작업하면서 겪었던 문제에 대해서 작성해보려고 한다.

Hotfix branch에서의 작업

이번에 프로모션 페이지 컴포넌트 작업을 stage를 base branch로 두고 작업을 했었다. 이렇게 작업을 하게 되면, 개별 프로모션 페이지 컴포넌트 작업내용 뿐만 아니라 stage에서 여지까지 merge되었던 작업내용들까지 같이 master branch로 merge가 되기 때문에 master branch에서 개별 hotfix branch를 끊어서 작업을 해야했다.

그런데 local master branch에서 remote master branch를 pull해서 최신 상태로 업데이트를 한 뒤에 local master branch를 base로 새로운 hotfix branch를 끊어서 작업을 했는데, 여기서 문제가 발생했다.

local master branch와 remote master branch의 차이에 대한 이해

앞서 언급한 문제 상황에 대한 결론을 우선적으로 말하자면, local master branch는 현재 stage와 merged back된 상태이고, remote master branch는 stage에 merged back되지 않는 개별 branch 상태이다.
따라서 local master branch를 기반으로 hotfix branch를 끊게 되면, 작업 후에 remote master branch로 push를 하게 되면, merged back된 stage의 작업 내용들까지 같이 넘어가게 된다.

이러한 문제로 인해 hotfix branch는 반드시 origin/master branch를 base로 끊어서 작업을 해야한다.

origin/master를 base로 hotfix branch 작업

1
2

$ git checkout -b hotfix/promotion-page master (X)
$ git checkout -b hotfix/promotion-page origin/master (O)

Git Stash Practice

branch를 끊어서 작업을 하는데, 일부 작업한 내용을 잠시 stage에 올려서 다른 branch에서 작업을 하고자 할때 stash를 활용할 수 있다.

아직 파일의 수정이 끝나지 않아서 commit 하기가 곤란하고, revert로 인해 다른 branch로 checkout을 하기도 곤란한 상황을 처리할 때 git stash를 사용한다.

git stash 명령은 git add를 통해서 트래킹 중인 파일에 대해서만 사용이 가능하다.

새로운 stash 생성

1
2
3
4

# saved to `refs/stash`
$ git stash
    or
$ git stash save

생성된 stash 리스트 확인

1

$ git stash list

다양한 사람들과 협업을 할 때 중요한 것은 문서작성 능력과 커뮤니케이션 능력이다.

Github 프로젝트를 다른 사람들과 같이 진행을 할때, pull request나 commit 메시지를 작성하는데,

적절한 format과 convention을 따라 작성을 하는 것은 매우 중요하다. 실제로 업무를 할때에도 이 convention을 따라 적절한 format으로 작성을 하게 되면, 해당 pull request나 commit 메시지를 확인하는 사람에게 업무처리에 대한 깔끔한 인상과 명확하게 처리한 업무에 대한 내용 전달을 할 수 있다.

따라서 이번 포스팅에서는 Github project에서 어떻게 문서를 관리하는지와 PR Template을 어떻게 자동으로 generate하는지에 대해서 살펴보고, 잘 formatting된 Template의 sample을 살펴보며 어떻게 하면 좀 더 전달력있는 Pull Requst message를 작성할 수 있는지에 대해서 배워보도록 하겠다.

PR Template 생성하기

Github 프로젝트를 위한 PR Template를 만들어보도록 하겠다.

side project를 하면서 궁금해진 부분이 생겼다. 그래서 구글링을 하다가 나와 비슷한 고민을 가진 외국인 개발자분이 개발자 커뮤니티에 질문을 올려서 답변을 받은 내용이 있는데 어느정도 나의 궁금증을 해결하는데 도움이 되어 포스팅으로 글을 남겨 놓으려고 한다.

https://softwareengineering.stackexchange.com/questions/178402/

내가 문득 궁금해진 부분은 개인 프로젝트(Side project)를 하는데 내가 유일무이한 개발자라면 해당 Repository에서 작업을 할때 과연 Pull Request가 필요할까? 라는 점이었다.
여러 팀원끼리 일을 하고, PR과 DEV로 구성되어있다면, 수정사항을 main branch에 반영할때 pull request를 통해 PR에게 코드리뷰를 받고 적절한 코드수정을 통해 merge되어야 한다. 그런데 과연 나 혼자 작업하는 개인 프로젝트인데 Pull request가 필요할까?

우선 여기에 대한 대답은 YES이다.

오늘은 저번 수업시간(29(금))에 배운 Git branch 관리와 협업에 대한 내용을 최대한 활용해서 연습을 해 볼 것이다. 물론 강사님 말처럼 입사하게 되면 main(master) branch, release branch를 건드릴 필요 없이, develop, feature branch만 가지고 작업을 하겠지만 개인 프로젝트할 때 버전별로 업데이트 해서 release도 해 볼 것이기 때문에 이를 위해 제대로 연습을 해 보겠다.

Branching model : git flow

• Release branch 실습

  

• Hotfix branch 실습

  

• Commit Convention

  • commit제목은 50자 이내로 요약하여 작성한다.
  • 제목과 내용사이에는 한 칸 띄어준다.
  • prefix를 활용하여 commit의 용도를 한 눈에 알아볼 수 있도록 한다.

  1 2 3 4 5 6 7 8 9

  feat: features docs: documentations conf: configurations test: test fix: bug-fix refactor: refactoring ci: Continuous Integration build: Build perf: Performance

• branch에 대한 개념 및 관리

  • Branch란?

    • 분기점을 생성하고 독립적으로 코드를 변경할 수 있도록 도와주는 모델이다.

  • 기본적인 Branch 관리 관련 명령어

    • 사용가능한 Local Branch를 출력

    1	$ git branch

    • Remote Branch에 대한 정보를 출력

    1	$ git branch -r

Shell, Vim command or git

오늘 배운내용

• Shell command

  • 기본 Linux shell command 활용

    • cd : 쉘의 현재 위치 이동

    • mv : 디렉토리, 파일 이동

    • cp : 파일 복사

    • rm : 디렉토리, 파일 삭제

    • mkdir : 디렉토리 생성

    • pwd : 쉘의 현재 위치 확인

    • ls (-a, -l option) : 쉘의 현 위치에 있는 디렉토리, 파일을 출력 (옵션을 이용해서 세부사항 출력, 리스트로 출력가능)

    • touch : 새로운 파일을 생성

    • cat : 파일의 내용을 terminal 상에서 확인

    • head : 파일의 앞 부분의 내용을 terminal 상에서 확인

    • tail : 파일의 뒷 부분의 내용을 terminal 상에서 확인
      (option으로 -[N] N 번째 라인까지 확인할지 설정할 수 있다.)

    • chmod : 파일권한 설정

오늘은 기존에 관리하던 Github 계정에서 필요한 Repository만 선별해서 새롭게 만든 계정으로 이전하는 작업을 하려고 한다. 이제 정말 필요한 Repository를 생성하고, 모든 Repository는 README 파일을 꼼꼼하게 적는 습관을 갖을 것이다.

새롭게 만든 Github 계정에서는 좀 더 꼼꼼하고 잘 관리된 개발자로서의 모습을 보여 줄 수 있도록 노력해야 겠다.