<div id="readability-page-1" class="page"><div><p>분산형 버전관리 시스템인 Git을 활용하면 제품 코드의 변경사항을 안정적이고 효율적으로 관리할 수 있습니다. 이 글은 누구나 쉽게 Git 초기 설정부터 브랜치를 활용한 기능 개발과 테스트, 머지까지 일련의 절차를 수행할 수 있도록 안내합니다. 아래의 절차는 <a href="https://docs.github.com/en/get-started/quickstart/github-flow">GitHub flow</a> 라는 브랜치 전략을 따르며 Ubuntu 22.04.2 버전과 Git 2.34.1 버전을 기반으로 작성되었습니다. 이 글에서 Git의 여러가지 개념들에 대해서는 다루지 않고 올바른 절차를 설명하는데 집중합니다.</p>
<h2 id="1-로컬-컴퓨터-설정">1. 로컬 컴퓨터 설정</h2>
<p>먼저 개발자 개인의 작업 컴퓨터에서 Git을 설치하고 기본적인 설정을 합니다.</p>
<h3 id="git-설치">Git 설치</h3>
<p>Git이 설치되어 있는지 확인합니다.</p>
<pre><code>$ git --version
git version 2.34.1</code></pre>
<p>만약 설치되어 있지 않다면 Git을 설치합니다. </p>
<pre><code>$ <span>sudo</span> <span>apt</span> update
$ <span>sudo</span> <span>apt</span> <span>install</span> <span>git</span></code></pre>
<p>이미 설치되어 있지만 2.23 버전 보다 낮은 경우 switch, restore 등 최신 명령 사용을 위해 버전 업그레이드를 합니다.</p>
<pre><code>$ sudo apt upgrade git</code></pre>
<h3 id="환경-설정">환경 설정</h3>
<p>사용자 이름, 이메일 정보, 인증 정보 저장 여부, 기본 에디터 등을 설정합다.</p>
<pre><code>$ <span>git</span> config --global user.name user
$ <span>git</span> config --global user.email user@gmail.com
$ <span>git</span> config --global credential.helper store
$ <span>git</span> config --global core.editor <span>vi</span></code></pre>
<p>GitHub과 같은 퍼블릭 호스팅 서버가 아닌 사내 내부망에 Gitlab 등으로 호스팅한 경우 SSL 인증을 생략하는 경우가 있습니다. 그런 경우 SSL 인증 오류가 발생할 수 있는데 다음과 같은 설정으로 SSL 인증을 생략할 수 있습니다. </p>
<pre><code>$ <span>git</span> config --global http.sslVerify <span>false</span></code></pre>
<h2 id="2-원격-저장소-클론">2. 원격 저장소 클론</h2>
<p>이제 원격 서버에 존재하는 저장소를 내 컴퓨터에 클론(Clone) 합니다. 이때 GitHub, Gitlab 등 호스팅 사이트 계정과 비밀번호 입력을 요구하는 창이 표시되면 입력합니다. </p>
<pre><code>$ <span>git</span> clone https://github.com/joosing/practice-in-git.git git-study</code></pre>
<h2 id="3-브랜치-생성">3. 브랜치 생성</h2>
<p>최초에 원격 저장소를 클론하면 원격 저장소의 master 브랜치만 가져오게 됩니다. 우리는 master 브랜치와는 독립적으로 개발 및 테스트가 가능한 피처(Feature) 브랜치를 생성하고 피처 브랜치 위에서 작업을 수행합니다. 이를 통해 master 브랜치는 언제나 릴리즈 가능한 상태를 유지합니다. </p>
<pre><code>$ <span>git</span> switch -c foo 
$ <span>git</span> branch
* foo
  master</code></pre>
<blockquote>
<p><strong>switch 명령</strong><br>
이 명령은 git 2.23 버전부터 새롭게 도입되었습니다. 기존에는 checkout 명령이 브랜치 전환과 현재 상태를 특정 커밋으로 복구하는 두 가지 기능 모두를 제공하고 있었는데 git 2.23 버전 부터는 switch, restore 라는 분리된 명령으로 두 기능을 제공하고 있습니다.</p>
</blockquote>
<h2 id="4-로컬-저장소에-커밋">4. 로컬 저장소에 커밋</h2>
<p>이제 운영 중인 master 브랜치와는 독립적으로 피처 브랜치에서 코드를 수정하고 테스트 가능합니다. 이제 코드를 수정하고, 특정 의미 단위로 로컬 저장소에 커밋(Commit)을 수행합니다. </p>
<pre><code>$ touch foo.py
$ git add foo.py
$ git commit -m "foo's first commit"</code></pre>
<blockquote>
<p><strong>Commit 의미</strong><br>
영어사전을 찾아보면 Commit이라는 단어는 다양한 뜻을 가지고 있습니다. 그 중에서 Git에서 사용하는 이 단어의 의미는 ‘Write Down’ 즉 ‘변경사항을 Git에 기록하다’ 정도로 이해할 수 있습니다. 뿐만아니라 ‘Hand Over’라는 뜻도 있는데 ‘Git에게 변경사항을 관리할 책임을 넘기다’ 정도로 해석할 수 있겠습니다. 이 의미가 개인적으로 더 와닿는 것 같습니다.</p>
</blockquote>
<h2 id="5-원격-저장소에-푸쉬">5. 원격 저장소에 푸쉬</h2>
<p>로컬 저장소에 커밋된 변경사항들은 팀이 공유하는 원격 저장소에 명시적으로 푸쉬해 주어야 팀원들과 코드를 공유하고 협업할 수 있습니다. </p>
<h3 id="원격-저장소의-업스트림-브랜치-설정하며-푸쉬">원격 저장소의 업스트림 브랜치 설정하며 푸쉬</h3>
<p>만약 지금 처럼 브랜치를 로컬 저장소에서 생성했다면 처음에 한 번 원격 저장소 업스트림 브랜치를 설정하는 과정이 필요합니다. 다음 명령어는 orgin 이라는 원격 저장소에 foo 라는 브랜치를 생성하고 로컬 브랜치의 변경사항을 푸쉬합니다. </p>
<pre><code>$ <span>git</span> push --set-upstream origin foo</code></pre>
<h3 id="업스트림-설정-이후의-일반적인-푸쉬">업스트림 설정 이후의 일반적인 푸쉬</h3>
<p>한 번 원격 저장소의 업스트림 브랜치를 지정해 주면 이후 부터는 단순히 변경 사항을 푸쉬해 줄 수 있습니다.</p>
<pre><code>$ <span>git</span> push</code></pre>
<h2 id="6-피처-브랜치로-테스트하기">6. 피처 브랜치로 테스트하기</h2>
<p>이제 테스트를 수행할 테스트 서버에서 피처 브랜치의 변경사항을 사용해 테스트를 진행할 수 있습니다. 테스트 서버에 이미 클론 받은 로컬 저장소가 있다면 원격 저장소 변경 사항 패치 후 브랜치를 전환합니다.</p>
<pre><code>$ git fetch
$ git switch -c foo origin/foo</code></pre>
<p>만약 처음이라면 새롭게 저장소를 클론하고 피처 브랜치로 전환합니다. </p>
<pre><code>$ <span>git</span> clone https://github.com/joosing/practice-in-git.git git-study
$ <span>git</span> switch -c foo origin/foo</code></pre>
<p>이제 피처 브랜치를 이용해 릴리즈 전 테스트를 진행할 수 있습니다. 테스트는 사실 한 번에 끝나지 않고 계속해서 수정을 반복하게 되는데 테스트 서버에 개발환경이 잘 구축되어 있지 않고 런타임 환경으로만 사용한다면 Git의 능력을 십분 활용하여 안정적으로 테스트를 진행할 수 있습니다. </p>
<h3 id="마스터-브랜치로-전환하기">마스터 브랜치로 전환하기</h3>
<p>테스트 도중 혹 운영중인 마스터 브랜치로 전환하여 테스트가 필요한 경우에도 단순히 브랜치를 전환해 주기만 하면 모든 소스코드의 변경사항들이 자동으로 전환되어 편리합니다. </p>
<pre><code>$ <span>git</span> switch master</code></pre>
<h2 id="7-머지-전-준비사항">7. 머지 전, 준비사항</h2>
<p>최종 테스트가 완료되었다면 피처 브랜치의 변경사항을 master 브랜치에 머지하여 릴리즈 할 수 있습니다. 그러나 머지 전에 소스코드의 변경이력을 효과적으로 관리하기 위해 다음 사항들을 권고합니다. </p>
<h3 id="리베이스">리베이스</h3>
<p>내가 피처 브랜치에서 개발하는 도중에 원격 저장소 master 브랜치에 다른 변경 사항들이 먼저 머지될  수 있습니다. 그러면 나의 피처 브랜치는 master 브랜치의 현재 HEAD 커밋이 아닌 이전 커밋으로부터 파생된 상태가 되는데 이때는 피처 브랜치가 master의 최신 HEAD 커밋으로 파생된 브랜치 처럼 바꾸어 주는 것이 좋습니다. 피처 브랜치에서 만든 일련의 커밋들을 마스터 브랜치의 맨 위로 올려준다고 표현 할 수도 있겠습니다. 이렇게 하는 이유는 브랜치들의 머지가 선형적으로 일어나 변경 이력이 한 눈에 보여 관리가 쉽기 때문입니다. 만약 그렇지 않다면 서로 다른 브랜치들의 머지 커밋들이 거미줄 처럼 꼬여서 이력 관리를 어렵게 만듭니다. 이제 원격 저장소의 변경사항들을 로컬로 가져오고(Fetch) 피처 브랜치를 원격 저장소 master 브랜치 HEAD 위치로 리베이스 해주는 과정이 필요합니다. 그리고 마지막으로 커밋 히스토리가 변경되었음으로 강제 푸쉬를 통해 피처 브랜치를 원격지 브랜치로 푸쉬해야 합니다.</p>
<pre><code>$ git fetch
$ git rebase origin/master foo
$ git push -f</code></pre>
<h3 id="충돌해결">충돌해결</h3>
<p>위 리베이스 과정에서 충돌이 발생할 수 있습니다. 충돌은 동일한 파일의 동일한 코드 라인을 두개 이상의 커밋에서 함께 변경할 때 발생합니다. 충돌을 해결하기 위해서는 충돌이 발생한 파일을 열고, 충돌이 발생한 두 변경 사항 중 어떤 것이 옳은지 선택하여 최종 파일 버전을 만들어 준 다음 리베이스를 완료시켜 주어야 합니다.</p>
<pre><code># 충돌이 발생한 foo.py
&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
hello
=======
hi
&gt;&gt;&gt;&gt;&gt;&gt;&gt; 56e275d (bar's second commit)</code></pre>
<pre><code># 충돌을 해결한 foo.py
hello</code></pre>
<pre><code>$ git add foo.py
$ git rebase --continue
$ git push -f</code></pre>
<h2 id="8-머지하기">8. 머지하기</h2>
<p>이제 사용하고 있는 Git 호스팅 웹페이지로 이동하여 푸쉬된 피처 브랜치를 master 브랜치로 머지하는 PR(Pull Request)을 생성하고, 상황에 따라 코드리뷰 후 PR을 머지할 수 있습니다. 만약 PR과 리뷰 과정을 생략하고 직접 머지를 수행한다면 로컬 저장소에서 다음과 같이 할 수 있습니다.</p>
<pre><code>$ git switch master
$ git merge --no-ff foo
$ git push</code></pre>
<h2 id="마치며">마치며</h2>
<p>Git을 사용해서 특정 기능 단위로 고립된 브랜치를 만들어 개발하고 머지하는 과정을 정리해 보았습니다. 항상 인텔리제이 GUI 기능을 사용해 왔는데 텍스트 명령을 사용하니 Git에 대해 조금 더 잘 이해하게 되는 것 같습니다. 혹시 잘못된 표현이나 절차가 있으면 댓글 남겨주시면 감사하겠습니다.</p></div></div>

Joo's Work

JooSing

분산형 버전관리 시스템인 Git을 활용하면 제품 코드의 변경사항을 안정적이고 효율적으로 관리할 수 있습니다. 이 글은 누구나 쉽게 Git 초기 설정부터 브랜치를 활용한 기능 개발과 테스트, 머지까지 일련의 절차를 수행할 수 있도록 안내합니다. 아래의 절차는 GitHub flow 라는 브랜치 전략을 따르며 Ubuntu 22.04.2 버전과 Git 2.34.1 버전을 기반으로 작성되었습니다. 이 글에서 Git의 여러가지 개념들에 대해서는 다루지 않고 올바른 절차를 설명하는데 집중합니다.
1. 로컬 컴퓨터 설정
먼저 개발자 개인의 작업 컴퓨터에서 Git을 설치하고 기본적인 설정을 합니다.
Git 설치
Git이 설치되어 있는지 확인합니다.
$ git --version
git version 2.34.1
만약 설치되어 있지 않다면 Git을 설치합니다. 
$ sudo apt update
$ sudo apt install git
이미 설치되어 있지만 2.23 버전 보다 낮은 경우 switch, restore 등 최신 명령 사용을 위해 버전 업그레이드를 합니다.
$ sudo apt upgrade git
환경 설정
사용자 이름, 이메일 정보, 인증 정보 저장 여부, 기본 에디터 등을 설정합다.
$ git config --global user.name user
$ git config --global user.email user@gmail.com
$ git config --global credential.helper store
$ git config --global core.editor vi
GitHub과 같은 퍼블릭 호스팅 서버가 아닌 사내 내부망에 Gitlab 등으로 호스팅한 경우 SSL 인증을 생략하는 경우가 있습니다. 그런 경우 SSL 인증 오류가 발생할 수 있는데 다음과 같은 설정으로 SSL 인증을 생략할 수 있습니다. 
$ git config --global http.sslVerify false
2. 원격 저장소 클론
이제 원격 서버에 존재하는 저장소를 내 컴퓨터에 클론(Clone) 합니다. 이때 GitHub, Gitlab 등 호스팅 사이트 계정과 비밀번호 입력을 요구하는 창이 표시되면 입력합니다. 
$ git clone https://github.com/joosing/practice-in-git.git git-study
3. 브랜치 생성
최초에 원격 저장소를 클론하면 원격 저장소의 master 브랜치만 가져오게 됩니다. 우리는 master 브랜치와는 독립적으로 개발 및 테스트가 가능한 피처(Feature) 브랜치를 생성하고 피처 브랜치 위에서 작업을 수행합니다. 이를 통해 master 브랜치는 언제나 릴리즈 가능한 상태를 유지합니다. 
$ git switch -c foo 
$ git branch
* foo
  master
switch 명령
이 명령은 git 2.23 버전부터 새롭게 도입되었습니다. 기존에는 checkout 명령이 브랜치 전환과 현재 상태를 특정 커밋으로 복구하는 두 가지 기능 모두를 제공하고 있었는데 git 2.23 버전 부터는 switch, restore 라는 분리된 명령으로 두 기능을 제공하고 있습니다.
4. 로컬 저장소에 커밋
이제 운영 중인 master 브랜치와는 독립적으로 피처 브랜치에서 코드를 수정하고 테스트 가능합니다. 이제 코드를 수정하고, 특정 의미 단위로 로컬 저장소에 커밋(Commit)을 수행합니다. 
$ touch foo.py
$ git add foo.py
$ git commit -m "foo's first commit"
Commit 의미
영어사전을 찾아보면 Commit이라는 단어는 다양한 뜻을 가지고 있습니다. 그 중에서 Git에서 사용하는 이 단어의 의미는 ‘Write Down’ 즉 ‘변경사항을 Git에 기록하다’ 정도로 이해할 수 있습니다. 뿐만아니라 ‘Hand Over’라는 뜻도 있는데 ‘Git에게 변경사항을 관리할 책임을 넘기다’ 정도로 해석할 수 있겠습니다. 이 의미가 개인적으로 더 와닿는 것 같습니다.
5. 원격 저장소에 푸쉬
로컬 저장소에 커밋된 변경사항들은 팀이 공유하는 원격 저장소에 명시적으로 푸쉬해 주어야 팀원들과 코드를 공유하고 협업할 수 있습니다. 
원격 저장소의 업스트림 브랜치 설정하며 푸쉬
만약 지금 처럼 브랜치를 로컬 저장소에서 생성했다면 처음에 한 번 원격 저장소 업스트림 브랜치를 설정하는 과정이 필요합니다. 다음 명령어는 orgin 이라는 원격 저장소에 foo 라는 브랜치를 생성하고 로컬 브랜치의 변경사항을 푸쉬합니다. 
$ git push --set-upstream origin foo
업스트림 설정 이후의 일반적인 푸쉬
한 번 원격 저장소의 업스트림 브랜치를 지정해 주면 이후 부터는 단순히 변경 사항을 푸쉬해 줄 수 있습니다.
$ git push
6. 피처 브랜치로 테스트하기
이제 테스트를 수행할 테스트 서버에서 피처 브랜치의 변경사항을 사용해 테스트를 진행할 수 있습니다. 테스트 서버에 이미 클론 받은 로컬 저장소가 있다면 원격 저장소 변경 사항 패치 후 브랜치를 전환합니다.
$ git fetch
$ git switch -c foo origin/foo
만약 처음이라면 새롭게 저장소를 클론하고 피처 브랜치로 전환합니다. 
$ git clone https://github.com/joosing/practice-in-git.git git-study
$ git switch -c foo origin/foo
이제 피처 브랜치를 이용해 릴리즈 전 테스트를 진행할 수 있습니다. 테스트는 사실 한 번에 끝나지 않고 계속해서 수정을 반복하게 되는데 테스트 서버에 개발환경이 잘 구축되어 있지 않고 런타임 환경으로만 사용한다면 Git의 능력을 십분 활용하여 안정적으로 테스트를 진행할 수 있습니다. 
마스터 브랜치로 전환하기
테스트 도중 혹 운영중인 마스터 브랜치로 전환하여 테스트가 필요한 경우에도 단순히 브랜치를 전환해 주기만 하면 모든 소스코드의 변경사항들이 자동으로 전환되어 편리합니다. 
$ git switch master
7. 머지 전, 준비사항
최종 테스트가 완료되었다면 피처 브랜치의 변경사항을 master 브랜치에 머지하여 릴리즈 할 수 있습니다. 그러나 머지 전에 소스코드의 변경이력을 효과적으로 관리하기 위해 다음 사항들을 권고합니다. 
리베이스
내가 피처 브랜치에서 개발하는 도중에 원격 저장소 master 브랜치에 다른 변경 사항들이 먼저 머지될  수 있습니다. 그러면 나의 피처 브랜치는 master 브랜치의 현재 HEAD 커밋이 아닌 이전 커밋으로부터 파생된 상태가 되는데 이때는 피처 브랜치가 master의 최신 HEAD 커밋으로 파생된 브랜치 처럼 바꾸어 주는 것이 좋습니다. 피처 브랜치에서 만든 일련의 커밋들을 마스터 브랜치의 맨 위로 올려준다고 표현 할 수도 있겠습니다. 이렇게 하는 이유는 브랜치들의 머지가 선형적으로 일어나 변경 이력이 한 눈에 보여 관리가 쉽기 때문입니다. 만약 그렇지 않다면 서로 다른 브랜치들의 머지 커밋들이 거미줄 처럼 꼬여서 이력 관리를 어렵게 만듭니다. 이제 원격 저장소의 변경사항들을 로컬로 가져오고(Fetch) 피처 브랜치를 원격 저장소 master 브랜치 HEAD 위치로 리베이스 해주는 과정이 필요합니다. 그리고 마지막으로 커밋 히스토리가 변경되었음으로 강제 푸쉬를 통해 피처 브랜치를 원격지 브랜치로 푸쉬해야 합니다.
$ git fetch
$ git rebase origin/master foo
$ git push -f
충돌해결
위 리베이스 과정에서 충돌이 발생할 수 있습니다. 충돌은 동일한 파일의 동일한 코드 라인을 두개 이상의 커밋에서 함께 변경할 때 발생합니다. 충돌을 해결하기 위해서는 충돌이 발생한 파일을 열고, 충돌이 발생한 두 변경 사항 중 어떤 것이 옳은지 선택하여 최종 파일 버전을 만들어 준 다음 리베이스를 완료시켜 주어야 합니다.
# 충돌이 발생한 foo.py
<<<<<<< HEAD
hello
=======
hi
>>>>>>> 56e275d (bar's second commit)
# 충돌을 해결한 foo.py
hello
$ git add foo.py
$ git rebase --continue
$ git push -f
8. 머지하기
이제 사용하고 있는 Git 호스팅 웹페이지로 이동하여 푸쉬된 피처 브랜치를 master 브랜치로 머지하는 PR(Pull Request)을 생성하고, 상황에 따라 코드리뷰 후 PR을 머지할 수 있습니다. 만약 PR과 리뷰 과정을 생략하고 직접 머지를 수행한다면 로컬 저장소에서 다음과 같이 할 수 있습니다.
$ git switch master
$ git merge --no-ff foo
$ git push
마치며
Git을 사용해서 특정 기능 단위로 고립된 브랜치를 만들어 개발하고 머지하는 과정을 정리해 보았습니다. 항상 인텔리제이 GUI 기능을 사용해 왔는데 텍스트 명령을 사용하니 Git에 대해 조금 더 잘 이해하게 되는 것 같습니다. 혹시 잘못된 표현이나 절차가 있으면 댓글 남겨주시면 감사하겠습니다.

Git | 브랜치에서 안전하게 작업하고 머지하기

댓글