[GitHub] 이것만 알면 당신도 git 마스터

들어가기에 앞서

깃허브가 협업툴로 정말 좋지만, 처음 접하는 사람들에게는 어렵기 마련이다. 협업에서 사용하는 것들을 위주로 정리하기로 한다. 개발 뉴비 시절부터 반강제로 깃을 쓰게 만든 42 만만세

💡 main 대신 master를 써도 괜찮지만 여기서는 main을 사용하도록 하자. master가 흑인에게 인종차별적인 용어라는 문제가 제기되어 git에서도 git init을 했을 때 main으로 생성되기 시작한지 오래되었다.

목차

1. 기본 명령어
2. 브랜치 관리 전략
3. pull request를 올려보자
4. main과 develop 브랜치를 최신으로 유지해보자

1. 기본 명령어

이곳에서는 add, commit, push 말고도 많은 것들을 다뤄볼 것이다.

기본 3명령어, add, commit, push

add

git에게 변경점이 있는 파일을 알려주는 명령어이다. 습관적으로 git add .이라는 명령어를 쓰게 되는데 .에 있는 파일, 다시 말해 현재 폴더 내에 있느 모든 파일을 git에 추가해서 변경점을 확인해주세요라는 뜻이다. 특정 파일이나 폴더만 올리고 싶다면 git add <폴더 이름>으로 처리하면 된다.

commit

git에게 변경점이 있다고 알려주는 것으로 끝이 아니다. 이저 이를 특정 기록으로 남겨야한다. git commit으로 남길 수 있다. 이러면 default로 nano나 vim이 켜지면서 커밋메시지를 남기라고 할 것이다.

물론 이렇게 해도 괜찮지만, nano나 vim이 익숙하지 않은 사람들은 사용하기 어려울 것이다. 그러면 git commit -m "<커밋메시지>"형식으로 커밋을 남기자. -m옵션은 커밋 메시지를 commit 명령어와 함께 작성하겠다는 의미이다. vscode로 창이 켜지게 하는 방법도 있지만 여기서는 생략한다.

push

기록만 남기면 이것도 의미없지 않은가. 이제 이를 원격 레포지토리인 github에 올려야한다. git push origin <branch 명>으로 올릴 수 있다.

원격 저장소(레포)에 연결해보자

만약 원격 저장소를 따로 연결하지 않았다면 관련 오류가 날 것이다. 원격 레포에 연결했는지 확인해보자

$ git remote -v

origin으로 시작하는 이름 뒤에 레포 경로가 잘 나타난다면 문제 없이 원격 저장소에 잘 연결되어있는 것이다. 안되어있다면 다음 명령어를 실행해서 연결해주자.

$ git remote add origin <원격 레포 이름>

사실 origin이 아닌 다른 이름으로 해도 괜찮지만 origin은 내 원격 저장소라는 의미를 가진 오래된 규칙이다. 웬만하면 origin으로 원격 저장소를 저장해주자.

만약 원격 저장소의 주소가 변경되었거나 잘못되어있다면 삭제하고 다시 추가해주자

# git remote rm origin

Branch를 다뤄보자

branch는 정말 중요한 기능 중 하나이다. branch 명령어를 통해 기존의 작업에서 분기점을 만들고, 해당 브랜치에서 작업하는 부분은 원래의 브랜치에는 영향이 없게 처리할 수 있게된다.

만약 모든 사람이 main브랜치에서 코드를 작업하면 충돌이 엄청 많이 날 것이다. 이러면 깃허브를 사용하는 의마가 전혀 없어진다. 이를 위해 branch를 사람마다 각각 파서 작업하는 것이다.

우선 현재 브랜치 명을 확인하자.

$ git branch

강조되어 있는 부분이 현재 내 브랜치 명이다. q로 빠져나올 수 있다.

확인했다면 현재 브랜치에서 다른 브랜치로 이동해보자. 나는 develop으로 이동할 것이다.

$ git checkout <branch 이름>
$ git branch

잘 이동했음을 알 수 있다.

그러면 이제 새로운 브랜치를 만들어보자. 두 가지의 방법이 있는데, 안타깝게도 나는 한 가지 방법만 알고있으므로 다음의 방법을 알려주겠다.

$ git checkout -b <새로운 브랜치 이름>

checkout의 -b옵션은 새로운 브랜치를 만들며 해당 브랜치로 이동하게 해준다.

이제 브랜치를 삭제해주자.

$ git branch -D <지울 브랜치 이름>

이전 커밋으로 되돌아가기

개발을 하다보면 무언가 꼬이는 상황이 발생할 수 있다. 이때 커밋을 해놓은 것이 빛을 발한다.

우선 커밋 아이디를 알아야하므로 확인해보자.

$ git log

그러면 이제 기존에 만들어놓은 커밋 내역을 볼 수 있다. 우리가 관심있는 것은 커밋 아이디이므로 되돌아가고 싶은 커밋 아이디를 복사하고 꺼주자. q를 눌러 빠져나올 수 있다.

임시로 이전 커밋으로 되돌아가보자.

$ git checkout <commit id>

그러면 위와같이 해당 커밋 아이디로 checkout이 진행된다. 해당 커밋으로부터 새로운 분기점을 만드는 작업이므로 여기에서 이어하고 싶다면 git checkout -b <새로운 브랜치 이름>으로 새 브랜치를 파서 작업하도록 하자.

하지만 가장 최신 작업내역까지 되돌아가고 싶을 수도 있다. 그러면 작업하던 브랜치로 checkout해주면 된다.

만약 지금까지 작업하던 내역이 있긴 하지만, 해당 작업내역을 지워버리고 싶다면 어떻게 해야할까?

다음의 명령어를 사용하여 작업내역을 모두 특정 커밋으로 되돌려주면 된다.

$ git reset --hard HEAD

이렇게하면 가장 마지막으로 커밋한 내역으로 되돌아간다.

2. 브랜치 관리 전략

브랜치 관리 전략엔 3가지 방법이 있다. git-flow, github-flow, gitlab-flow 방식이다. 지금까지 해왔던 프로젝트들에서는 주로 git-flow의 방식을 사용했다.

git-flow

5개의 브랜치로 유지하는 방식이다. 대규모의 프로젝트에 용이하다.

• main : 실제로 서비스되는 production 코드가 올라가는 브랜치이다. 그만큼 중요한 브랜치이므로 코드가 망가지지 않도록 main 브랜치에 바로 커밋하지 않도록 한다.

• develop : main의 자손 브랜치다. 이후 개발된 기능들이 이곳에 합쳐지며 이곳에 최신 코드를 유지해야한다. develop도 마찬가자다. 이 브랜치에 바로 커밋하지 말자.

• feature : develop의 자손 브랜치이며 기능 개발이 이루어지는 브랜치다. 컨벤션에 따라 feat/*, feature-*등으로 시작하는 이름으로 브랜치를 만든다.

• release : main에 올리기 전에 마지막으로 테스트를 하는 브랜치이다. develop의 자손 브랜치이며, 이후 main으로 머지된다.

• hotfix : main에 급하게 수정되어야 하는 버그가 있을 때 만들어서 버그 수정 후 main으로 머지되는 브랜치이다. 만들일이 없는 게 낫다.

github-flow

위에서 너무 복잡하지 않았는가? 그래서 만들어진 flow다. truck-base 방식이라고도 부른다. 단 2가지의 브랜치를 사용한다.

• main : 실제로 서비스되는 production 코드가 올라가는 브랜치이다. 그만큼 중요한 브랜치이므로 코드가 망가지지 않도록 main 브랜치에 바로 커밋하지 않도록 한다.

• feature : 기능 개발이 이루어지는 브랜치다. 작업이 끝나면 main으로 머지된다.

gitlab-flow

위는 또 그렇다고 너무 적고 조심성 없는 느낌인 것 같다. 그래서gitlab에서 만든 플로우다.

• production : 위에서의 main 브랜치의 역할이다. 다시 말해 실제로 서비스되는 production 코드가 올라가는 브랜치이다. 그만큼 중요한 브랜치이므로 코드가 망가지지 않도록 production 브랜치에 바로 커밋하지 않도록 한다.
• pre-production : 위에서의 release 브랜치와 역할이 같다. production 브랜치에 올라기 전 테스트하는 브랜치이다.
• main : 위에서의 develop 브랜치와 역할이 같다.
• feature : 위에서의 feature 브랜치와 역할이 같다.

3. pull request를 올려보자

그렇다면 다른 브랜치로 머지하려면 어떻게 해야할까? 단순히 생각하면 그냥 merge 명령어로 합치면 될 것 같지만 아니다! GitHub플로우가 단순한 이유가 있다. 이는 pull request를 전제하고 만들어졌기 때문에 단순한 것이다.

pull request는 하위 브랜치에서 상위 브랜치로 커밋 내용을 합칠건데 한 번 확인해주세요하는 요청이다. 대부분 리뷰를 받아야 머지를 할 수 있게 규칙을 설정해두며, 승인이 안나면 다시 해와야한다.

pull request를 올리는 방법

우선 원격 레포에 내가 작업한 코드를 올려야한다.

$ git push origin <내 브랜치>

그리고 github에 있는 원격 레포로 가서 new pull request를 눌러준다.

그러면 위와같이 커밋 리스트와 함께 생성하기 버튼이 나오는데, 그걸 누르고 pull request 내용을 적어주면 된다.

최대한 자세히 적자.

그러면 끝!

4. main과 develop을 최신으로 유지해보자.

이게 핵심이다.

pull request가 승인되어 원격에 머지되면 로컬에도 이를 반영해주어야한다.

우선 현재 git status를 확인하여 어떤 상태인지 보자.

$ git status

작업내역이 있는데, 커밋을 하지 않았다면 이렇게 뜰 것이다.

On branch your-branch-name
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   modified_files

no changes added to commit (use "git add" and/or "git commit -a")

그러면 경고대로 커밋을 하거나(작업내용을 기록하고 싶을 경우), 위에서 말한 것 처럼 git reset --hard HEAD을 진행해주면 된다.(작업 내용을 최신 커밋으로 되돌리고 싶은 경우) (git restore <file>...방식도 있는데 자세한 게 궁금하다면 따로 공부해보도록 하자.)

다음과 같이 나타난다면 진행할 준비가 된 것이다.

On branch your-branch-name
nothing to commit, working tree clean

이제 최신화할 브랜치로 이동해주자. 여기서는 develop으로 이동해보겠다.

$ git checkout develop

그리고 원격 저장소에서 최신 내역을 받아온다.

$ git pull origin develop

마지막으로 다시 작업하던 곳으로 가서 merge 명령어를 사용하여 커밋 내역을 합쳐주자.

$ git checkout <작업중이던 브랜치>
$ git merge develop

그러면 끝이다!