<div id="readability-page-1" class="page"><time>2021. 7. 11. 19:44</time>
 
 
 <a href="#comment" onclick="Utils.smoothScroll(this);return false">
 
 </a>
 
 
 
 
 
 
 
 <div>
 처음 회사에 신입으로 입사하면 처음으로 마주하는 관문은 회사의 형상 관리 시스템, 쉽게 말해서 branch 운용 전략에 익숙해지는 것입니다. 대표적인 branch 운용 전략으로는 git flow, git-hub flow, git-lab flow 등 다양한 방법론이 존재합니다. 그러나 이러한 방법론을 실제로 사용해볼 경험은 신입으로서 드물었습니다.&nbsp;

입사 전의 저로서는 작게 꾸린 2~3명의 팀으로 프로젝트를 진행해본 것이 협업 경험의 전부였습니다. 기존 프로젝트를 팀원들이 fork한 후에 master branch에 곧바로 pull request를 요청하는 방법이었죠. 그러나 typed에 입사한 후에는 다른 방식을 사용하고 있어 적응하는데 시간이 필요했습니다.&nbsp;

이 글을 통해서 새로 입사하는 주니어 개발자들 혹은 git 운용 전략을 수립하려는 분들에게 도움이 되었으면 좋겠습니다.


<h4 data-ke-size="size20">typed는 어떻게 협업하는가?</h4>

1) 코드의 양이 적은 단일 작업의 경우 : master branch checkout =&gt; pull request

예를 들어 hotfix나 작은 디자인 수정의 경우 코드의 양이 적고, 팀원들이 다시 리뷰하기 비교적 쉬운 편이기 때문에 곧바로 master branch에서 checkout한 뒤 master branch에 pull request를 보냅니다.

직접 명령어를 작성해보자면 다음과 같은 흐름으로 전개됩니다.
<pre id="code_1626005591419" data-ke-language="javascript" data-ke-type="codeblock"><code>gco -b fix-resource-naming // 'fix-resource-naming' 브랜치를 만들고 fix-resource-naming로 전환합니다.
git add . // 작성한 코드를 staging 상태로 변경합니다.
git commit -m "msg" // 로컬 저장소에 커밋합니다.
git push origin fix-resource-naming // 원격 저장소에 fix-resource-naming 브랜치를 생성하고, 그 곳에 해당 코드를 push 합니다.</code></pre>

이 과정을 도식화해보자면 다음과 같습니다.
<figure data-origin-width="493" data-origin-height="223" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/bO4YYp/btq9mmz5hWL/n1wCo0qdTsTiyWkGPiKANK/img.png" data-origin-width="493" data-origin-height="223" data-ke-mobilestyle="widthOrigin"></figure>

이로써 로컬에 있는 코드가 원격 브랜치에 올라갔습니다. github에 가보면 compare &amp; pull request 버튼이 활성화된 것을 확인할 수 있습니다.
<figure data-origin-width="1025" data-origin-height="90" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/MWIIU/btq9nDuNhS4/8oOaCSQ3FMKE52EPQEvAmk/img.png" data-origin-width="1025" data-origin-height="90" data-ke-mobilestyle="widthOrigin"></figure>

fix-resource-naming branch에서 master로 병합을 요청하는 것 또한 확인할 수 있습니다.
<figure data-origin-width="630" data-origin-height="46" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/c4j2BG/btq9pD2m3c6/51vGF4mpWdrqARabKvuakK/img.png" data-origin-width="630" data-origin-height="46" data-ke-mobilestyle="widthOrigin"></figure>

2) 코드의 양이 많은 경우 =&gt; feat-base-* branch

대부분 기능 개발은 많은 양의 코드 변화를 가져옵니다. 코드양을

<ol data-ke-list-type="disc">
<li>master 에서 base branch 를 feat-base-* 이름 규칙으로 생성하여 push 합니다.</li>
<li>base branch 로부터 작업 브랜치를 생성하여 작업합니다.</li>
<li>작업 브랜치에서 개발이 완료되면 base branch를 base로 하여 PR을 open 합니다.</li>
<li>첫번째 작업 브랜치가 base branch 에 PR이 병합되면 feature branch의 PR을 Open 합니다.</li>
<li>→ base branch PR 본문에는 앞으로 작업해야 할 리스트를 TODO로 작성</li>
<li>3번 과정을 기능 작업이 완료될 때까지 반복합니다.</li>
<li>base branch 에 관련된 모든 PR이 반영되었다면 승인 후 master 로 병합합니다.</li>
<li>→ base branch PR에 대한 리뷰는 모두 작업 브랜치가 base branch 로 병합될 때 리뷰가 완료되었기에 기본적으로는 필요하지 않음</li>
</ol>


<h4 data-ke-size="size20">코드 리뷰</h4>

1) 코드 리뷰 받기

Pull Request를 요청한 후에는 팀원들 간의 리뷰를 통과해야 합니다.
이 과정에서 팀원들에게&nbsp;자신의 코드를 명확하게 설명할 수 있어야 하고 때로는 자신의 코드를 변호할 줄도 알아야 합니다.
만약 더 좋은 방법을 팀원이 제시하였거나, 명확하게 틀린 부분을 지적한 경우 수용하여 다시 리뷰 요청을 보내는 것이 좋습니다.

더 나은 퀄리티의 코드를 위한 것이라 감수하고 ego를 내려놓을 필요가 있습니다.
이게 다 좋은 제품을 만들기 위한 것이니까요!
<figure data-origin-width="300" data-origin-height="300" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/IhTfh/btq9mlgSCQX/gQwbIAzRLRab3waWJeGPOk/img.jpg" data-origin-width="300" data-origin-height="300" data-ke-mobilestyle="widthOrigin"></figure>

<figure data-origin-width="1027" data-origin-height="692" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/pRFYG/btq9hzm7GU2/vLIF2QSplOEDlStx1N1E8K/img.png" data-origin-width="1027" data-origin-height="692" data-ke-mobilestyle="widthOrigin"></figure>

팀원들이 리뷰를 마치고 해당 부분을 수정한 후에는 merge 되어도 좋다는 승인(approve)를 합니다.
typed에서는 2명 이상의 팀원이 승인한 경우 merge할 수 있도록 정해두었습니다.
<figure data-origin-width="1040" data-origin-height="221" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/cizKzL/btq9jGzfbOf/m5MEFj20Tt2ahMbYGgNnY1/img.png" data-origin-width="1040" data-origin-height="221" data-ke-mobilestyle="widthOrigin"></figure>

merge할 수 있는 권한을 획득하였다면&nbsp;master branch 혹은 feat-base-* branch에 Squash and merge합니다.
<figure data-origin-width="1009" data-origin-height="596" data-filename="image.png" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/bi52ja/btq9hyn9b8e/OBRx16y0vgZv8XbsScCOR0/img.png" data-origin-width="1009" data-origin-height="596" data-filename="image.png" data-ke-mobilestyle="widthOrigin"></figure>
Squash and merge란 branch의 commit 내역을 squah, 즉, 뭉뚱그려 하나의 commit으로 만들어 merge하는 것입니다.
Squash and merge된 내역들을 살펴보면 병합된&nbsp;branch의 commit의 양과 관계 없이 하나의 commit으로 정리된 것을 확인할 수 있습니다.
<figure data-origin-width="1352" data-origin-height="241" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/bh9R4U/btq9pCCoZJA/wbHRMCXt2DrWuXYLr47Q4K/img.png" data-origin-width="1352" data-origin-height="241" data-ke-mobilestyle="widthOrigin"></figure>

typed의 경우 master branch에 merge된 순간, github action를 통해 자동으로 staging 배포를 진행됩니다.
staging 단계에서는 QA가 진행됩니다.




2) 코드 리뷰 해주기

프로젝트에 참여하는 개발자는 reviewer이자 reviewee이기도 합니다.
product의 퀄리티와 상호 코드를 이해하기 위해 자신의 코드뿐만 아니라 다른 팀원의 코드를 리뷰할 필요가 있습니다.
코드 리뷰를 해주지 않으면 누구도 merge할 수 없으니까요.
자신의 일이 급한 만큼 다른 팀원의 일도 급하다는 것을 인정하고 성실하게 코드 리뷰를 해줄 필요가 있습니다.

<figure width="300" height="296" data-origin-width="507" data-origin-height="500" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/dA0y16/btq9jGF4jUS/lkn8lpKQ1L4cVOK81Pwfz1/img.jpg" width="300" height="296" data-origin-width="507" data-origin-height="500" data-ke-mobilestyle="widthOrigin"></figure>


아래와 같은 pull request 요청이 왔다고 가정하겠습니다.
<figure data-origin-width="888" data-origin-height="104" data-ke-mobilestyle="widthOrigin"><img src="https://blog.kakaocdn.net/dn/FKiBq/btq9ngl1k18/XyDNmQhmYXahuHLP7ke0yK/img.png" data-origin-width="888" data-origin-height="104" data-ke-mobilestyle="widthOrigin"></figure>

우리는 feat-bulk-resource-reorder-service branch에 올라온 코드를 확인하고 실행시킬 필요가 있습니다.
다른 branch로 스위칭하기 전 현재 작업한 사항을 commit해도 되지만, 완료하지 않은 작업을 commit 하기에는 찜찜함이 있습니다.&nbsp;
git stash를 통해서 현재 작업 사항을 임시 저장한 후 checkout하도록 합시다.

<pre id="code_1626005877053" data-ke-language="javascript" data-ke-type="codeblock"><code>git stash // 현재 작업을 임시 저장
git checkout origin feat-bulk-resource-reorder-service // 코드 리뷰를 위한 checkout
get checkout [작업하던 branch] // 본래 branch로 돌아갑니다.
git stash apply // 가장 최근의 stash를 불러오기</code></pre>


<h4 data-ke-size="size20">글을 마치며</h4>
위에 언급한 것 외에도 typed는 디자인 팀과의 원활한 작업을 위해서 preview를 위한 별도의 branch를 따로 두고 있는 등 더 다양한 방법으로 git을 운용하고 있습니다.&nbsp;

typed가 이러한 branch 운용 전략을 사용하게 된 것은 프로젝트의 성격과 구성원 규모 등이 고려된 결과입니다. 예를 들어 git flow를 엄격히 지키려면 사소한 변경 사항도 master에 반영되기까지 branch switching이 자주 일어나야 하는데, agile한 개발, 배포 환경을 추구하는 현재 typed와는 거리가 있었습니다. 따라서 typed의 개발 환경은 현 상황에 따라 결정된 환경이며, 개발 환경이 변한다면 언제든지 변경될 수 있습니다.


<h4 data-ke-size="size20">reference</h4>
<a href="https://jonsuh.com/blog/git-command-line-shortcuts/" target="_blank" rel="noopener">https://jonsuh.com/blog/git-command-line-shortcuts/</a>

 
 
					
 
 
 </div></div>

HotHandCoding

DarrenKwon

처음 회사에 신입으로 입사하면 처음으로 마주하는 관문은 회사의 형상 관리 시스템, 쉽게 말해서 branch 운용 전략에 익숙해지는 것입니다. 대표적인 branch 운용 전략으로는 git flow, git-hub flow, git-lab flow 등 다양한 방법론이 존재합니다. 그러나 이러한 방법론을 실제로 사용해볼 경험은 신입으로서 드물었습니다. 
 
입사 전의 저로서는 작게 꾸린 2~3명의 팀으로 프로젝트를 진행해본 것이 협업 경험의 전부였습니다. 기존 프로젝트를 팀원들이 fork한 후에 master branch에 곧바로 pull request를 요청하는 방법이었죠. 그러나 typed에 입사한 후에는 다른 방식을 사용하고 있어 적응하는데 시간이 필요했습니다. 
 
이 글을 통해서 새로 입사하는 주니어 개발자들 혹은 git 운용 전략을 수립하려는 분들에게 도움이 되었으면 좋겠습니다.
 
 
typed는 어떻게 협업하는가?
 
1) 코드의 양이 적은 단일 작업의 경우 : master branch checkout => pull request
 
예를 들어 hotfix나 작은 디자인 수정의 경우 코드의 양이 적고, 팀원들이 다시 리뷰하기 비교적 쉬운 편이기 때문에 곧바로 master branch에서 checkout한 뒤 master branch에 pull request를 보냅니다.
 
직접 명령어를 작성해보자면 다음과 같은 흐름으로 전개됩니다.
gco -b fix-resource-naming // 'fix-resource-naming' 브랜치를 만들고 fix-resource-naming로 전환합니다.
git add . // 작성한 코드를 staging 상태로 변경합니다.
git commit -m "msg" // 로컬 저장소에 커밋합니다.
git push origin fix-resource-naming // 원격 저장소에 fix-resource-naming 브랜치를 생성하고, 그 곳에 해당 코드를 push 합니다.
 
이 과정을 도식화해보자면 다음과 같습니다.
 
이로써 로컬에 있는 코드가 원격 브랜치에 올라갔습니다. github에 가보면 compare & pull request 버튼이 활성화된 것을 확인할 수 있습니다.
 
fix-resource-naming branch에서 master로 병합을 요청하는 것 또한 확인할 수 있습니다.
 
2) 코드의 양이 많은 경우 => feat-base-* branch
 
대부분 기능 개발은 많은 양의 코드 변화를 가져옵니다. 코드양을
 
master 에서 base branch 를 feat-base-* 이름 규칙으로 생성하여 push 합니다.
base branch 로부터 작업 브랜치를 생성하여 작업합니다.
작업 브랜치에서 개발이 완료되면 base branch를 base로 하여 PR을 open 합니다.
첫번째 작업 브랜치가 base branch 에 PR이 병합되면 feature branch의 PR을 Open 합니다.
→ base branch PR 본문에는 앞으로 작업해야 할 리스트를 TODO로 작성
3번 과정을 기능 작업이 완료될 때까지 반복합니다.
base branch 에 관련된 모든 PR이 반영되었다면 승인 후 master 로 병합합니다.
→ base branch PR에 대한 리뷰는 모두 작업 브랜치가 base branch 로 병합될 때 리뷰가 완료되었기에 기본적으로는 필요하지 않음
 
 
코드 리뷰
 
1) 코드 리뷰 받기
 
Pull Request를 요청한 후에는 팀원들 간의 리뷰를 통과해야 합니다.
이 과정에서 팀원들에게 자신의 코드를 명확하게 설명할 수 있어야 하고 때로는 자신의 코드를 변호할 줄도 알아야 합니다.
만약 더 좋은 방법을 팀원이 제시하였거나, 명확하게 틀린 부분을 지적한 경우 수용하여 다시 리뷰 요청을 보내는 것이 좋습니다.
 
더 나은 퀄리티의 코드를 위한 것이라 감수하고 ego를 내려놓을 필요가 있습니다.
이게 다 좋은 제품을 만들기 위한 것이니까요!
 
 
팀원들이 리뷰를 마치고 해당 부분을 수정한 후에는 merge 되어도 좋다는 승인(approve)를 합니다.
typed에서는 2명 이상의 팀원이 승인한 경우 merge할 수 있도록 정해두었습니다.
 
merge할 수 있는 권한을 획득하였다면 master branch 혹은 feat-base-* branch에 Squash and merge합니다.
Squash and merge란 branch의 commit 내역을 squah, 즉, 뭉뚱그려 하나의 commit으로 만들어 merge하는 것입니다.
Squash and merge된 내역들을 살펴보면 병합된 branch의 commit의 양과 관계 없이 하나의 commit으로 정리된 것을 확인할 수 있습니다.
 
typed의 경우 master branch에 merge된 순간, github action를 통해 자동으로 staging 배포를 진행됩니다.
staging 단계에서는 QA가 진행됩니다.
 
 
 
 
2) 코드 리뷰 해주기
 
프로젝트에 참여하는 개발자는 reviewer이자 reviewee이기도 합니다.
product의 퀄리티와 상호 코드를 이해하기 위해 자신의 코드뿐만 아니라 다른 팀원의 코드를 리뷰할 필요가 있습니다.
코드 리뷰를 해주지 않으면 누구도 merge할 수 없으니까요.
자신의 일이 급한 만큼 다른 팀원의 일도 급하다는 것을 인정하고 성실하게 코드 리뷰를 해줄 필요가 있습니다.
 
 
 
아래와 같은 pull request 요청이 왔다고 가정하겠습니다.
 
우리는 feat-bulk-resource-reorder-service branch에 올라온 코드를 확인하고 실행시킬 필요가 있습니다.
다른 branch로 스위칭하기 전 현재 작업한 사항을 commit해도 되지만, 완료하지 않은 작업을 commit 하기에는 찜찜함이 있습니다. 
git stash를 통해서 현재 작업 사항을 임시 저장한 후 checkout하도록 합시다.
 
git stash // 현재 작업을 임시 저장
git checkout origin feat-bulk-resource-reorder-service // 코드 리뷰를 위한 checkout
get checkout [작업하던 branch] // 본래 branch로 돌아갑니다.
git stash apply // 가장 최근의 stash를 불러오기
 
 
글을 마치며
위에 언급한 것 외에도 typed는 디자인 팀과의 원활한 작업을 위해서 preview를 위한 별도의 branch를 따로 두고 있는 등 더 다양한 방법으로 git을 운용하고 있습니다. 
 
typed가 이러한 branch 운용 전략을 사용하게 된 것은 프로젝트의 성격과 구성원 규모 등이 고려된 결과입니다. 예를 들어 git flow를 엄격히 지키려면 사소한 변경 사항도 master에 반영되기까지 branch switching이 자주 일어나야 하는데, agile한 개발, 배포 환경을 추구하는 현재 typed와는 거리가 있었습니다. 따라서 typed의 개발 환경은 현 상황에 따라 결정된 환경이며, 개발 환경이 변한다면 언제든지 변경될 수 있습니다.
 
 
reference
https://jonsuh.com/blog/git-command-line-shortcuts/

typed의 git 전략부터 코드 리뷰 문화까지 (가안)

댓글