기본적인 Git 사용법

2022년, 00시가 지나고 나서 내가 가장 먼저 한 일이 있는데 바로 내 깃헙 주소의 README.md 파일을 작성한 것이다. 

그리고 어제부터 이틀간 git에 대해서 공부했는데, 전반적인 git 사용법에 대해서 정리해 보고자 한다.

 

1. Git은 왜 사용할까

git은 버전 관리를 하기 위해서 리눅스 운영체제를 만든 사람인 Linus Torvalds가 2005년에 처음 소개했다고 한다. 이를 통해 수많은 소스코드를 효율적으로 관리할 수 있다. 

깃으로 크게 '버전관리', '백업', '협업'을 할 수 있다.

 

2. Git을 통한 버전 관리

 

(1) Working Tree와 Stage 그리고 Repository

 - Working Tree(작업 트리) : 파일 수정, 저장 등의 작업을 하는 디렉토리. working directory라고도 하며 간단히 말해서 우리 눈에 보이는 디렉토리가 바로 working tree이다.

 - Stage : 버전으로 만들 파일이 대기하는 곳이다. staging area라고도 하며, working tree에서 수정한 것들중 버전으로 만들 것을 stage로 넘겨주면 되는 것이다. (git add)

 - Repository : stage에서 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳이다. (git commit)

 

* stage와 repository는 눈에 보이지 않고 .git 디렉토리 안에 숨은 파일 형태로 존재하는 영역이다.

git add를 통해 버전을 만들 파일을 stage로 올리고, git commit을 통해서 버전을 repository에 넣는 것이다. 

 

(2) 작업 되돌리기

 - working tree에서 수정한 파일 되돌리기 : git checkout -- <filename>

 - staging을 취소하는 법 : git add 한것을 git reset HEAD <filename>

 - 최신 commit을 취소하는 법 : git reset HEAD^ (working tree로 다시 이동)

 - 특정 commit으로 돌리는 방법 : git reset --hard <돌아갈 commit ID>

 - commit 삭제하지 않고 되돌리는 방법 : git revert <한단계 전으로 돌릴 commit ID> 

 * reset은 어떤 특정 버전을 지우는 것. revert는 기존 커밋을 내버려 두고, 이 버전에서 버전을 취소한것. 

 

(3) 명령어

git init <directory>	initialize repository (.git directory를 만듦) <directory>를 적으면 해당 디렉토리를 만들고 거기 안에 .git폴더를 만든다.
git status	git 상태 확인
git add <file name>	staging할때 사용
git commit	repository에 commit함(버전을 새로 만듦) -m "message" : commit message 함께 작성 -am (-a-m) "message" : add 하지 않고 바로 commit. but 파일 수정은 가능하나 새로운 파일은 add로 staging 시켜줘야함. --amend : 가장 최근 커밋 메세지 수정.
git log	commit 기록 을 볼 수 있음. --stat : 어떤 파일이 어떤 변화가 있었는지 알 수 있음. --all --graph --oneline : 한줄로 모든 log를 그래프로 볼수있음.
git diff	스테이지에 있는 파일, 저장소에 있는 최신 커밋 비교.

 

---

3. 브랜치

(1) 브랜치는 왜 필요한가? 

버전을 만들때, 어느 시점부터 기존의 버전을 기반으로 서로 다른 버전을 만들어 나가고 싶다면 이렇게 branch를 활용할 수 있다.

브랜치는 기본적으로 master라는 브랜치가 버전 관리를 시작하면 만들어진다. 사용자가 commit을 할 때마다 master브랜치는 최신 커밋을 가리킨다. 브랜치는 커밋을 가리키는 포인터라고 생각하면 된다. 

새로운 브랜치를 만들면 기존에 저장한 파일을 master 브랜치에 그대로 유지하면서 기존 파일 내용을 수정하고 새로운 기능 구현을 할 수가 있는 것이다. 또한 branch하여 작업 한 파일을 원래 master 브랜치에 합칠 수도 있는데, 이를 merge(병합)이라고 한다.

 

 - 브랜치 관련 명령어

$git branch <생성할브랜치> :  브랜치를 만들거나 확인

$git checkout <이동할브랜치> :  브랜치 사이 이동하기.

 

(2) 브랜치 병합하기

예를들어 apple이라는 branch를 git branch apple을 통해 만들고 git checkout apple로 apple 브랜치로 이동해 작업하다가 apple과 기존의 master를 병합하고 싶다면,

1) 일단 master 브랜치로 이동 (git branch master)

2) git merge <merge할branch> 이용. (git merge <apple>

-> 그러면 자동으로 빔이 실행되면서 merge branch apple이라는 커밋 메세지가 나타난다. message 수정 후 enter로 커밋하면 된다.

 

(3) 충돌

git merge를 통해서 병합을 할때, 서로 다른 branch가 서로 다른 곳을 수정하여 버전을 만들었다면 서로 수정한 부분을 합쳐 merge를 시킨다. 하지만 서로 같은 곳을 수정하여 버전을 만들었다면 충돌이 발생하여 에러메세지가 발생하게 된다. 에러메세지에서 충돌이 발생한 파일에 가서 확인해 본다면 현재 브랜치에서 수정한 내용과 병합할 브랜치에서 수정한 내용이 무엇인지 각각 확인할 수 있고 수정한 파일을 staging 후 commit하면 merge가 된다.

 

 - merge가 끝나고 브랜치 삭제 할때에는 master 브랜치에서 git branch -d <삭제할 브랜치>를 입력하면된다. 하지만 삭제한 브랜치 이름으로 다시 브랜치를 만들면 이전에 작업했던 내용이 그대로 나타난다. 

브랜치를 삭제하는 것은 저장소에서 완전히 없애는 것이 아닌 흐름 속에서 감추는 것이다.

 

(4) branch의 원리와 checkout/reset의 차이

branch의 원리

위 그림과 같이 HEAD는 Repository를 만들면 생성되는데, .git파일 안에 보면 HEAD파일이 있다. 또한 기본적으로 Repository를 생성하면 master branch가 생성되어 HEAD가 기본적으로 master branch를 가리키게 되는데, commit을 하여 새로운 버전을만들때마다 master가 최신의 버전을 가리키는 것이다. 

또한 2번째 버전에서 google이라는 branch를 생성하면 master를 보고 google이라는 새로운 branch가 2번째 버전에서 시작하는 것을 git이 알게된다. 

checkout을 통해 google로 branch를 전환한다면 HEAD가 가리키고 있는것이 master에서 google로 바꾸는 것이다. 

Head가 branch가 아닌 버전을 직접적으로 가리킬수 있는데, HEAD checkout <버전commitID>라고 입력하면 해당하는 commitID에 해당하는 버전을 가리키게 되고, 이를 Detached 상태라고 한다.

따라서 현재 이 저장소의 버전이 무엇이냐를 판단하기 위해서는 HEAD -> master를 따라 가면 알 수 있다.

 

checkout master를 하게 되면 google branch에서 다시 master branch로 HEAD가 가리키는 곳이 전환되기 때문에 Change의 느낌이라면, reset master라고 한다면, google branch를 master가 가리키고 있는 버전으로 바꾸고, 그 이후의 버전은 사라지게 되기 때문에 삭제 느낌이 강하다. google로 checkout된 상태에서 reset <commitID>를 입력하면, 해당 commitID에 맞는 버전으로 이동하고, 생성하였던 2번 3번의 버전은 가리키는 곳이 없으므로 삭제된다.

---

4. 백업하기 

git을 사용함으로서 repository를 생성하여 버전관리를 진행하는 것을 알아보았다. 그렇게 생성한 repository를 내 local 저장소인 내 컴퓨터에서 remote 저장소인 깃헙에 올려 백업을 할 수 있으며, 각각의 지역저장소에서 원격 저장소인 깃헙을 두고 협업 프로젝트에도 사용할 수 있다.

 

 - 원격 저장소에 연결하기 : git remote add origin <github Repository 주소>

 - 원격 저장소 위치 확인하기 : git remote -v

 - 원격 저장소에 파일 올리기 : git push -u origin master (원격저장소의 origin, master브랜치로 푸쉬해라. 처음에만 하면 됨.  이후부터는 git push만 하면 됨.)

 - 원격 저장소 파일 내려 받기 :  git pull origin master

 

5. 협업하기

A와 B가 하나의 remote repository를 두고 local에서 pull과 push를 통해서 작업한다고 할 때, A와 B가 동시에 작업한 후 push하면 거절을 한다. git pull한 뒤 보면 충돌이 난 것을 확인할 수 있는데, 이때 branch에서 충돌이 난것과 마찬가지로 수동으로 처리하거나 mergetool을 사용할 수 있다. 수정한 후 add후 git commit을 입력하면 자동으로 merge commit message를 보여준다. 따라서 pull을 하는 습관이 매우 중요하다.

 

 - 원격 저장소 복제하기 : git clone <복제할주소> <붙혀넣을디렉토리>

 - 원격 브랜치 정보 가져오기 : git fetch -> FETCH_HEAD라는 브랜치로 원격 저장소 정보를 가지고 온다. FETCH_HEAD에서 git log를 보면 origin/master와 origin/HEAD가 있고, 이 커밋이 패치로 가져온 원격 브랜치의 최신 커밋이다. 따라서 이 내용을 살펴보고 원격 브랜치의 초신 커밋을 지역 저장소에 합칠지 말지를 결정하면 된다.  (합치는것 : git pull이나 git checkout master -> git merge FETCH_HEAD)

 

(1) 협업의 기본 

깃헙 public repository는 모두가 주소만 알면 소스를 받을 수 있다. 하지만 누구나 저장소에 커밋을 push할수는 없다. public이던 private이던 여러사람이 협업한다면 승인된 공동작업자에게만 커밋을 올릴수 있는 권한을 주어야한다. 그래야 무분별하게 소스가 수정되는것을 막을 수 있다. 그렇게 권한을 주는 사람을 collaborator라고 한다.

또한 협업을 하다 보면 팀원이 각자 다른 기능을 맡아 작업하는 경우가 많은데, 팀원 1과 팀원 2가 서로 다른 기능을 만들 때, 각자의 작업이 master 브랜치에 있는 문서들과 섞이지 않도록 새 브랜치를 만들어 버전을 관리한다. 

그리고 각 팀원은 만든 새 브랜치 역시 collaborator라면 push가능하다.

git pull -> git checkout -b <생성할 branch이름> (branch 생성과 동시에 체크아웃 한번에)

작업과 커밋이 끝난 후에는 git push origin <branch이름>을 입력하면 push한 브랜치를 github에서 확인할 수 있다.

 

** branch를 새로 생성하여 master branch에 영향을 주지 않으면서 업무가 가능하기 때문에 test 후에 팀 모두가 ok 하면 master로 merge시킨다. 따라서 기본은 master로 일하지 않고 항상 branch 하여 작업하는 것이다.

 

(2) 오픈소스 참여하기

collaborator가 아니라 push 권한이 없을때에는 clone과 pull을 통해 받은 프로젝트를 수정한 다음 collaborator로 넘겨 주어야하는데, 이때 patch를 사용하는 방법과 fork를 사용하는 두 방법이 있다. (근데 내가 보니 fork를 대부분 사용하는것 같다..)

 

1) patch

collaborator가 아닌 다른 사람이 작업을 수행한 후, git format-patch <작업하기직전commitID>를 입력하면 각각의 버전간의 차이점에 대한 내용이 있는 .patch파일이 생겨나는데, 이를 권한이 있는 collaborator에게 넘겨주면 된다. 그러면 받은 cllaborator가 git am -3 -i *.patch를 통해서 처리하면 된다 (-3은 3 way merge, -i는 interactive mode를 뜻함) 그러면 내용이 같아지지만 commit ID는 달라진다.

 

2) fork와 pull request 

깃헙의 참여하고자하는 opensource에 fork하면 내 계정으로 그 repository가 복제가 된다. 그럼 그것을 clone하여 내 마음대로 수정할 수 있고, 작업한 것을 깃헙의 compare에 들어가면 차이점을 볼 수 있다. pull request를 누르면 자기의 변경 사항을 가져가 달라고 요청하는 것이고, 이것을 확인한 collaborator가 merge를 하면 commit이 되는 것이다. 

 

Reference : 

- 지옥에서 온 문서관리자 깃&깃허브 입문 (이지스 퍼블리싱)

 - 생활코딩 GIT CLI (https://www.youtube.com/playlist?list=PLcDtUrBwapUOQzycPhaGUFnc-ogBOI6N_)