gitlab 기본 사용법

 

Basic usage

1	코드획득	프로젝트 코드를 획득합니다.	git clone https://${ID}:${PAT}@repo.url.git
2	브랜치 생성	코드 작업을 수행할 브랜치를 생성합니다.	git checkout -b feature/feature1 branch 명은 보통 다음의 룰을 따라 작성합니다.  * feature의 경우 feature/feature_name * bugfix의 경우 bugfix/bug_fix_name
3	수정 사항 추가	작업 브랜치에서 코드 작업 후 수정 사항을 staging area에 추가합니다.	git add my_work.ccp
4	커밋 생성	staging area에 반영된 수정 사항으로 커밋을 생성합니다.	git commit  이후 나타나는 화면에서 commit comment를 작성합니다.  다음과 같이 comment를 작성합니다.  ex. ISSUE-01: title description
5	서버에 업로드	서버에 commit 사항들(하나 이상의 commit)을 push 합니다.	git push 서버별칭 브랜치명 ex. git push origin feature/applying_coding_rules
6	메인 스트림 브랜치에 머지		이제 gitlab의 프로젝트 화면으로 가서 화면 좌측의 'Merge requests'를 클릭하면  새로운 리퀘스트 생성 화면으로 진입합니다. 다음은 feature/applying_directory_structure branch를 main branch로 merge 하도록 설정한 화면 입니다. 설정 완료 후 하단의 'Compare branches and continue'를 클릭합니다.  아래 화면에서 Title 부분과 Description을 작성하고 하단의 'Create merge request' 버튼을 클릭합니다.  이후 리뷰어의 승인(Approval)이 되면 'Merge' 버튼이 활성화 되며, 이를 클릭 시 수정 사항이 target branch에 반영(merge) 됩니다.  (단, merge 전 필수 approver의 지정이 없으면 MR 생성 후 바로 'Merge' 버튼이 활성화 되어 있습니다)

 

Fork를 통한 코드 작업

보통 repo를 그대로 clone 해서 작업하지 않습니다. 안전을 위해 repo를 fork 하고 이를 clone 하여 작업합니다. 

본 섹션에서는 repo의 fork후 작업하는 방법에 대해 설명하겠습니다. 

 

upstream 등록

fork 된 repo를 clone  후 다음과 같이 upstream (merge 할 repo의 별칭)을 등록합니다. 

ex. 

git remote add upstream https://...

 

• https://...은 fork 대상이 된 원본 repo의 주소입니다. 

Upstream 내용 가져오기

upstream main barnch에 최신 수정 사항을 forked repo의 local로 가져오려면 다음과 같이 git을 사용합니다. 

~$ git pull upstream main

 

혹은 다음과 같이 fetch 후 merge를 통해 수정 사항을 가져올 수 있습니다.

~$ git fetch origin

fetch는 원격 저장소(origin)의 모든 branch(혹은 지정된 브랜치)의 변경 사항을 로컬 저장소에 다운로드합니다. 

원격 브랜치의 상태를 로컬에서 확인할 수 있도록 업데이트를 하며 자동으로 로컬 브랜치에 적용되지는 않습니다.

~$ git merge origin/main

원격 브랜치(origin/main)의 변경 사항을 현재 로컬 브랜치에 병합합니다.

 

pull과 fetch & merge의 차이점

기능git pull origin maingit fetch origin && git merge origin/main

동작	가져오기(fetch)와 병합(merge) 를 한번에 수행	가져오기(fetch)와 병합(merge) 를 개별 단계로 수행
자동 병합 여부	자동 병합	git merge 시 병합
장점	쉬운 사용	병합 전에 변경 사항 확인 및 충돌 해결 가능
단점	병합 전 변경 사항 확인 불가하여 충돌 시 즉시 해결 필요	두 단계로 나눠져 있어서 불편함
사용 경우	로컬에 변경 사항이 없을 시 원격의 수정 사항을 반영 혼자 작업하는 경우 충돌의 가능성이 낮은 경우	병합 전 원격 브랜치의 변경 사항 확인 필요 시 동시에 같은 브렌치를 수정하는 경우 충돌 발생 가능성이 높을 시 원격 브랜치의 변경 사항을 로컬의 다른 브랜치에 병합하고자 할 때

 

충돌 해결

add 후 merge

두 방식 모두 병합 과정에서 충돌이 발생할 수 있습니다. 충돌 발생 시 사용자는 직접 파일을 수정해서 충돌 부분을 없애야 합니다.

로컬 수정 사항과 서버 현황 중 필요한 부분을 택1하여  git (add, commit, push)등을 수행합니다.

...
<<<<<<< HEAD
로컬 브랜치의 코드
=======
원격 브랜치의 코드
>>>>>>> origin/main
...

이후 git add로 수정한 파일을 스테이징 후 git commit 사항들을 git merge를 통해 병합을 완료해할 수 있습니다. 

 

충돌 회피를 위한 최신 변경 사항 반영

충돌을 피하기 위해서 최신 변경 사항을 반영하는 방법에는 크게 fase-forward와 rebase가 있습니다. 

 

fase-forward

main branch의 pointer를 단순히 feature branch의 최신 commit으로 이동하는 방식입니다. 단, 이를 정상적으로 수행하려면 main branch에 병합을 시작한 이후의 추가 커밋이 없어야 합니다. 즉, feature branch에서 작업하는 동안 main branch에 새로운 커밋이 추가되지 않아야 합니다. 

동작의 예는 다음과 같습니다. 

A --- B --- C (main)
     \
      D --- E (feature)

git checkout main
git merge feature

결과:
A --- B --- C --- D --- E (main, feature)

rebase

add후 merge 방법말고 rebase를 이용할 수 있습니다. 

rebase는 현재 작업중인 branch(ex. feature)에 main branch의 최신 update commit을 반영하여 충돌없이 push를 가능하게 하는 말 그대로 기본 history를 다시 만드는(rebase) 작업을 수행합니다. 

 

다음은 rebase의 예시 입니다. 

A --- B --- C (main)
     \
      D --- E (feature)

git checkout feature
git rebase main

결과:
A --- B --- C --- D' --- E' (feature)
                 ^
                 (main)

 

git pull --rebase origin main은 git fetch origin 후 git rebase origin/main과 동일한 동작을 수행합니다. 

merge 대신 rebase를 사용하면 커밋 히스토리가 더 깔끔하게 유지되나 이미 푸시한 커밋을 리베이스 하는 것은(기존 커밋 이력을 삭제하므로) 위험할 수 있어서 주의해야 합니다. 

 

git merge upstream/main --allow-unrelated-histories  <- 공통 commit이 없어도(관련이 없어도) merge 허용