GitLab에서 Merge Request 보내는 방법

◻️ 계기

계속 Github만 사용하다가 한이음 프로젝트를 통해 처음으로 GitLab을 써보게 되었다. 기존 프로젝트에서부터 사용해오던 Pull Request 방식을 이번에도 사용하게 되었고, gitLab에서는 Merge Request라고 불린다는 걸 알았다. 이 전략을 제대로 이해하고자 사용하고자 기록을 남기게 되었다.

◻️ 동작 순서

1. 원본 Repository에서 Fork 떠오기
2. Fork 떠온 Repository 내 로컬에 clone
3. 원본 Repository와 내 로컬 연결
4. 처음 가져올 때 master 브랜치만 있으므로, 나머지 브랜치들 pull 해오기
5. 소스코드 수정 후 커밋
6. 내 Repository에 소스 코드 Push
7. Merge Request (Pull Request)
8. 깃 최신화

◻️ 실습

🔴 원본 Repository에서 Fork 떠오기

가져오고 싶은 Repository를 열어 우측 상단에 있는 Fork 버튼을 눌러 fork 해오면 된다.
그러면 해당 깃에 있는 브랜치를 그대로 가져올 수 있다.

현재 브랜치는 master - develop - fix 가 있다고 가정해보자.

원하는 Project name을 적고 하단의 Fork project를 눌러 Fork를 완료한다.

현재 브랜치는 master - develop - fix 가 존재한다.

🟠 Fork 떠온 Repository 내 로컬에 clone

그러면 이렇게 내 GitLab에 깃이 Fork 되어 있는 걸 확인할 수 있다. 우측의 Clone 버튼을 눌러 url을 복사한다음 터미널을 이용해 내 로컬에 Clone 해온다.

현재 브랜치는 master 만 존재한다.

git clone {gitlab url}

🟡 원본 Repository와 내 로컬 연결

내 로컬에서 바로 원본 Repository에서 pull을 받을 수 있도록, MR을 보내기 위해 두 Repo를 연결하는 작업을 진행할 것이다.

git remote {저장소 이름} {원본 Repository url}

git remote upstream http://lab.hanium~~~

제대로 연결됐는지 확인할 수도 있다.

git remote -v

🟢 Repository와 내 로컬 버전 맞춰주기

git clone을 해오면 master branch만 클론을 받아온다. 그렇기 때문에 나머지 브랜치들은 수동으로 버전을 맞춰줘야 한다. 브랜치 순서에 유의하며 pull 받아온다.

git checkout -b develop    // develop 브랜치 생성
git pull origin develop    

git checkout -b fix    // fix 브랜치 생성
git pull origin fix    

🔵 소스코드 수정 후 커밋, Push

fix 브랜치에서 소스코드를 수정하고 커밋한다. 커밋을 꼭 해야하는 이유는 깃은 커밋 단위로 움직이기 때문이다. 만약 커밋을 하지 않고 다른 작업을 벌이면 에러가 날 가능성이 높다. push는 upstream이 아닌 origin에 하는데, 우리는 Merge Request 전략을 사용할 예정이기 때문이다!

git add .
git commit -m "메시지"
git push origin fix

🟣 Merge Request (Pull Request)

gitLab 좌측에 보면 Merge Request 버튼이 있다. 이걸 눌러주도록 하자! 나는 MR 보낼게 없어서 0으로 뜨지만, 커밋을 하고나면 0이 아닌 다른 숫자가 적혀있을 것이다!

Source branch : 출발지
Target branch : 도착지

🟤 Git 최신화

현재 우리의 상태는 아래 그림과 같다. 그럼 내 Repository의 버전이 원본과 다르므로 최신화 시켜줘야 한다.

git checkout develop
git fetch
git merge upstream develop

git checkout master
git fetch
git merge upstream master