(도서) 만들면서 배우는 Git GitHub입문 읽고 <1편>(2019/10/31)

-버전 관리 란

데이터의 과거와 현재 상태를 관리하는 것이다. 

 

RPG 게임을 하고 있다고 상상해보자. 게임 도중 어떤 불상사가 생길지 모른다. 몹이랑 싸우다가 죽을 수 도있고 전투에서 파티가 전멸하게 될 수도 있다. 하지만 게임을 저장하면서 진행한다면 죽더라도 저장 파일을 불러오면 되니깐 편안하게 게임을 진행할 수 있다.

 

또 다른 비유로는 대학 시절 리포트를 작성하던 걸 떠올려 봐도 좋다. 

누구나 한 번쯤 리포트를 작성하다 예기치 못한 컴퓨터 오류 때문에 작성했던 리포트를 몽땅 날린 경험이 있다.

그런 일을 방지하기 위해 무엇을 했는가를 떠올려라.

아마 모두가 비슷할 것이다.

한 문장 한 문장 적을 때마다 저장하는 것이다.

 

이러한 모든 것이 버전 관리를 하는 예이다.

 

-버전 관리 시스템이란

Version Control System(VCS)라는 용어로 많이 부른다.

버전 관리 시스템은 우리가 손으로 해야 했던 사본 생성, 보존, 복원을 한 번에 해줄 수 있는 도구이다.

 

-Git

분산 버전 관리 시스템 중 하나이다.

Git은 완벽한 분산 환경에서 빠르고 단순하게 수백수천 개의 동시 다발적인 브랜치 작업을 수행하는 것을 목표로 하는 버전 관리 시스템이다. Git의 큰 장점이라 한다면 다음 사항을 들 수 있다.

• 전 세계의 수많은 사용자가 사용 중

• Git을 사용한 저장소를 공유 사이트 Github웹 사이트의 존재
• 사용자 수에서 나오는 어마어마한 숫자의 튜토리얼과 프로젝트가 존재

 

-로컬 저장소 사용을 위한 Git 기본

1. 저장소 사용에 필요한 Git 기본 명령어

저장소 생성	git init
저장소에 파일 추가	git add <파일이름>
저장소에 수정 내용 제출	git commit
저장소 상태 확인	git status

 

2. 저장소 사용을 위한 branch 명령어

저장소에 브랜치 추가	git branch <브랜치 이름>
작업 중인 브랜치 변경	git checkout <브랜치 이름>
브랜치 병합	git merge <브랜치 이름>

branch명령어를 이용하면 현재 프로젝트를 통째로 복사하고 붙여 넣기 할 필요 없이 브랜치만 옮기는 것으로 완전히 다른 작업 흐름을 가져가도록 할 수 있다. 또한 다른 브랜치에서 작업하다가 다시 원래 브랜치로 돌아가면 모든 작업 내역은 그대로 복원된다.

 

branch merge에 자세한 정보

 

 

-Git 실습 하기

실습 순서는 아래와 같다.

1. 저장소 생성

2. 저장소에 hello world를 출력하는 프로그램 작성 및 추가

3. commit

4. hotfix 브랜치 생성 및 이동

5. 프로그램 수정

6. commit

7. master 브랜치에 병합

8. master 브랜치에 변경점 하나 추가

9. commit 

10. hotfix 브랜치에 변경점 하나 추가

11. commit 

12. master와 hotfix 브랜치 사이에 영향이 없음을 확인

13. 불필요한 프로젝트 파일을 관리 대상에서 제외하기

14. 출동 해결하기

15. 기록 보기

 

commit은 어떤 상황에서 해야 할까?

commit은 프로젝트에서 의미가 있는 최소 단위이다. 사람마다 commit 하는 시기에 대해서는 의견이 분분하지만 책에서 저자는 '의미'를 가질 수 있게 되는 시기라면 언제든 commit을 하는 것을 권장한다.

 

1. git init : 저장소 생성

git 저장소로 사용할 디렉터리 만들기

git init

명령어를 사용하여 저장소를 최기화 한다.

이후, master가 표시되는 걸 볼 수 있다. 현재 저장소에서 작업 중인 브랜치가 master 브랜치라는 표시다.

 

git init명령어 사용 후 디렉토리 상황

 

2. git add와 git commit : 첫 번째 커밋

파일 생성 후 git status 명령어 실행

git status

git_tutorial폴더에 helloworld.txt 파일을 만들고 git status명령어를 사용하여 git 상태를 확인한다.

메시지는 아직 git에서 추적하지 않는 helloworld파일이 저장소에 있다고 알려준다.(추적되지 않은 파일은 빨간색으로 표시) 

 

git add 명령어

git add

git add 명령어를 사용하여 git이 helloworld파일을 추적하게 한다.

이후, git status명령어를 사용하여 상태를 확인해보면 helloworld파일이 초록색으로 변하고 commit준비 단계로 변한다.

 

git commit 명령어

git commit -m "커밋 메시지 작성"

git commit명령어를 사용하여 첫 번째 git 버전 관리를 시작한다.

메시지는 해당 커밋을 설명할 수 있는 다른 메시지여도 괜찮다.

 

3. git branch와 git checkout : 새로운 브랜치 생성과 이동

기존 프로젝트에 영향이 가지 않는 새로운 실험적 기능을 추가해야 하거나, 기존 기능을 변경해야 하는 상황을 고려할 때가 있다. 버전 관리를 모르던 상황이면 복사와 붙여 넣기로 실험을 해야 했었을 것이다. 하지만 git은 그럴 필요가 없게 해 준다. 이때 사용하는 게 branch이다.

 

현재 branch 확인하기

git branch

현재 어떤 브랜치가 있는지 볼 수 있고 *master로 초록색 표시된 게 지금 접속된 브랜치이다.

 

git branch 생성하기

git branch <브랜치 이름>

git brnach <브랜치 이름> 명령을 실행하면 <브랜치 이름>의 브랜치가 만들어진다. 여기서는 hotfix라는 이름의 브랜치를 만들기 위해 다음 명령을 실행한다. 

이후, git branch 명령어를 실행해보면 hotfix 브랜치가 만들어진 게 보인다.

 

hotfix브랜치에서 작업 시작하기

git checkout <이동할 브랜치 이름>

위 명령어를 실행하여 hotfix 브랜치로 이동했으며 그에 따라 hotfix 브랜치로 변경했다는 메시지가 나타난다.

그리고 디렉터리 경로 맨 마지막에 (hotfix)라고 표시도 바뀐다.

참고로 git checkout -b <브랜치 이름> 명령어를 사용하면 브랜치를 만들면서 바로 체크아웃할 수 있다.

 

지금부터 하는 작업은 오직 hotfix 브랜치에만 영향을 끼치게 된다.

파일 수정하든, 삭제하든, 추가하든 마음껏 하고 싶은 대로 한 다음에, 커밋을 하고, 다시 master브랜치로 체크아웃하면 hotfix에서 작업했던 모든 것을 해당 브랜치의 최종 커밋 상태로 보존한 후, master 브랜치의 최종 커밋 상태로 파일들이 변경된다.

 

4. hotfix브랜치에서 commit 하기 (두 번째 commit)

hotfix브랜치에서 파일 생성 및 commit하기

master브랜치에서 commit 절차대로 hotfix브랜치에서 cathello파일을 만들고 commit 한다.

 

5. git merge : master 브랜치와 병합

master 브랜치로 이동

git checkout <이동할 브랜치 이름>

master 브랜치에서 merge 하기 위해 master브랜치로 이동한다.

 

git merge

git merge <브랜치 이름>

git merge hotfix를 통해 hotfix 브랜치를 가져와서 master브랜치와 병합한다.

hotfix브랜치에 있던 cathello파일이 master브랜치에도 추가되었다.

 

hotfix브랜치에 위치한 상황에서 git marge master라는 명령을 실행해도 병합된다.

단, hotfix브랜치에 위치한 파일 기준으로 모든 내용을 병합한다.

즉, master 브랜치는 변경되지 않고 hotifx브랜치에 master 브랜치 내용이 합치게 되죠.

의도하는 것은 master브랜치가 hotfix브랜치를 병합하는 것이다. 

때문에 기준이 되는 브랜치에서 병합하고 있는지 확인해야 한다.

 

6. 실제 프로젝트에서 발생하는 상황들

Git을 좀 더 geek 하게 이용하는 방법들이 있다.

크게 보면 1) 파일을 무시하는 법, 2) 병합할 때 발생하는 충돌을 해결하는 법, 3) 커밋한 내역을 살펴보는 법 이 있다.

 

6-1. .gitignore : 불필요한 파일 및 폴더 무시

프로젝트를 진행하다 보면 부수적으로 다양한 파일이 만들어진다. 

굳이 추적해야 할 필요가 없는 파일이다.

저장할 필요 없는 파일들을 적절하게 무시하기 위해 Git은. gitignore라는 파일을 이용한다.

 

ignore파일 만들기

touch. gitignore

touch명령어를 사용하여. gitignore파일을 만든다. 

이후, git_tutorial폴더를 보면 이름 없는 파일이 생성된다. 

이게. gitignore 파일이다.

위 명령어를 사용하는 이유는 윈도우에서는 운영체제에서 설정한 제약 때문에 ". "으로 시작하는 파일을 만들 수 없으니 touch 명령을 실행해 파일을 만든 후 파일 안에 내용을 복사한다.

 

ignore파일 내용 채우기

https://www.gitignore.io/

위 사이트에서 조건에 알맞은. gitignore파일을 생성해준다.

생성을 눌리면 위 사진처럼 텍스트가 나온다. 

복사해서 우리가 만든. gitignore파일에 붙여 넣기 하면 된다.

 

이후, 파일을 commit 하면 된다.

 

6-2. 충돌(conflict) 해결

두 개의 브랜치에서 동시에 같은 파일의 같은 곳을 수정하고, 그걸 병합하면서 생기는 충돌을 해결하는 것이다.

 

두 브랜치에서 같은 파일 수정 후 merge 충돌

master브랜치와 hotfix브랜치에서 동일한 파일에 서로 다르게 파일내용을 수정했다.

이후, master브랜치에서 hotfix브랜치를 merge 하려고 하면 충돌(conflict)이 발생한다.

 

그리고 경로를 표시하는 부분을 보면 마지막의 브랜치 표시 부분이 바뀐 것을 알 수 있다.

'(master|MERGING)'이라고 바뀌었다.

즉, 지금 이 브랜치는 병합하는 도중 충돌이 발생해 그것을 해결하는 도중이라는 명시적인 표시이다.

 

따라서 충돌 내용을 cathello 파일에서 확인해보겠다.

위 사진을 보면 

'<<<<<<< HEAD'로 표시하고, 충돌 난 부분의 끝을 '>>>>>>> hotfix'로 표시하고 있다.

중간에 '======='으로 어디까지가 어디에 속해 있는지 경계를 표시해준다.

 

Git은 해당 행이 어떤 의미를 지니고 있는지 알 수 없으므로 어떤 수정 사항을 선택할 것인지 사용자에게 일임한다.

이런 경우 충돌 난 두 브랜치 중 하나의 내용을 선택하거나, 두 수정 내역을 합치는 수동으로 충돌을 해결해야 한다.

즉, 충돌을 해결하기 위해서는 충돌 난 부분이 어떤 의미인지 이 애 하고 있어야 해결할 수 있다.

 

여기서는 두 수정 내역을 합해보겠다. 

서로 다른 내용을 합쳐서 merge하기

같은 파일에 서로 다른 내용을 합친 다음 다시 commit을 했다. 정상 commit이 된다.

commit 하고 나니 '(master|MERGING)'에서 '(master)'로 돌아왔다.

 

6-3. git log : 기록 보기

위와 같은 작업을 계속하다 보면 언제 어떤 작업 후에 커밋했는지가 헷갈리기 시작한다.

혹은 여러 사람이 저장소에 접근해서 커밋한다면 더 그럴 수 있다.

따라서 커밋 내역을 확인할 수 있는 기능이 필요하다.

바로 git log 명령어다. 

주로 사용하는 옵션은 다음과 같다.

git log -p	각 커밋에 적용된 실제 변경 내용을 보여준다.
git log --word--diff	diff 명령의 실행 결과를 단어 단위로 보여준다.
git log --stat	각 커밋에서 수정된 파일의 통계 정보를 보여준다.
git log --name-only	커밋 정보 중에서 수정된 파일의 목록만 보여준다.
git log --relative-date	정확한 시간을 보여주는 것이 아니라 1일 전, 1주 전처럼 상대적인 시간을 비교하는 형식으로 보여준다.
git log --graph	브랜치 분기와 병합 내역을 아스키 그래프로 보여준다.

(좌)git log --graph (우)git log --stat 

git log --graph 명령에서 왼쪽 녹색과 빨간색 세로 점선이 나누어진 것을 볼 수 있다.

이는 브랜지의 분기 내역을 보여주는 것이다.