Git - 협업 시작하는 법

협업 시작 방법 Clone, Branch

# 회사 repository 내 레포지토리로 복사
git fork

# 내 레포지토리에서 git clone 하는 법 
git clone "가져올 원격 저장소 주소" 폴더명(폴더명 설정 안해주면 원격 저장소 이름으로 폴더가 생성됩니다.)
# 특정 브랜치 clone
# git clone -b <branch명> <remote_repo 주소>



(git repository 세팅에 팀원 깃헙아이디 등록해놔야 팀원들이 git push가 가능합니다.)

# 협업 시작! (git 브랜치 전략!)
# develop 브랜치 생성
git branch develop -> 브랜치 생성

# feature 브랜치(feature/login)를 'develop' 브랜치('master' 브랜치에서 따는 것이 아니다!)에서 분기
git checkout -b feature/login develop

# ~ 기능 작업 실행
# 'develop' 브랜치로 이동한다.
git checkout develop

# 'develop' 브랜치에 feature/login 브랜치 내용을 병합(merge)한다.
# --no-ff 옵션: 아래에 추가 설명
git merge --no-ff feature/login

# -d 옵션: feature/login에 해당하는 브랜치를 삭제한다.
git branch -d feature/login

// 'develop' 브랜치를 원격 중앙 저장소에 올린다.
git push origin develop


# branch로 푸쉬하기 ⭐️
git push origin 브랜치명

# 내 레포지토리에서 포크한 레포지토리로 pr하기 - (compare & pull request) 
# 내 깃허브 레포지토리 들어가서 버튼 클릭

# upstream? -> Fork의 대상이었던 원래의 저장소
git remote add upstream 포크한 레포지토리 주소
git pull upstream main

# branch 삭제하기, merge 했을때는 
git branch -d 브랜치명
# merge 안했을 때
git branch -D 브랜치명

# git merge
git merge 브랜치명 -> 브랜치명의 브랜치를 현재 브랜치로 병합

# git fetch
git fetch -> 깃 변경사항을 최신화

--no-ff 옵션

• 새로운 커밋 객체를 만들어 ‘develop’ 브랜치에 merge 한다. 이것은 ‘feature’ 브랜치에 존재하는 커밋 이력을 모두 합쳐서 하나의 새로운 커밋 객체를 만들어 ‘develop’ 브랜치로 병합(merge)하는 것이다. 

 

pull request

협업을 할 때 여러 branch들에서 push가 들어와 main branch와 merge할 때는 깃허브 사이트에 들어가서 pull request를 하면 됩니다.
⭐️ 팀원끼리 코드리뷰가 가능하고, main branch에 병합되는 것이므로 제일 중요한 작업입니다!

다른 branch에서 push를 하고 깃허브에가면 이렇게 나와요

pull request 클릭한 후 변경 코드를 보면서 댓글도 달고 팀원들끼리 리뷰를 할 수 있어요.

이런식으로 댓글을 달아 리뷰할 수 있어요.

코드가 괜찮다면 Merge pull request를 눌러줍니다, 그럼 main branch와 병합이 된답니다!

하지만 Merge pull request 오른쪽 화살표 버튼을 누르면 3가지를 선택할 수 있게 나오는데요

 

첫 번째 : Create a merge commit은 3-way merge라고 부르는 가장 일반적인 방법입니다.

main branch 조회시 합쳐진 branch의 commit 내역이 전부 나옵니다.

단점

• commit history에 모든 내역들이 다 나와 나중에 인원이 많아지고 commit을 많이하다보면 복잡하고 더러워 보일 수 있습니다.

3-way merge

 

두 번째 : Squash and merge는 강제적으로 commit 이력을 남기지 않게 해주는 방법입니다.

한 branch 안에 있는 모든 작업 내역을 하나의 commit으로 통합해주는 것입니다. main branch에 통합한 신규 commit을 생성해줍니다.
Squash and merge에서 발생하는 merge commit은 실질적인 merge로 인해서 생성된 merge commit이라기보다는 그냥 다른 하나의 branch의 변경 사항을 하나로 뭉쳐놓은 commit 입니다.
오타 수정이나 간단한 변경 commit을 commit history에  남기지 않고 합쳐진 하나의 commit으로 history를 유지할 수 있어서 깔끔해 보입니다.

단점

• 일반적인 merge commit는 해당 branch에서 누가 어떤 commit을 통해 어떤 라인을 수정 했는지까지 알려주지만 Squash and merge는 merge 대상 branch의 모든 commit을 하나로 통합해버리기 때문에 그 정도의 자세한 정보는 알 수가 없습니다.
  즉, Squash and merge을 사용하여 브랜치를 merge하게 되면 merge된 사실 자체는 알 수 있으나 어떤 상황에서 어떤 코드를 변경 했는지까지는 알 수가 없습니다.

Squash and merge

 

세 번째 : Rebase and merge를 하면 작업 종류가 유사한 branch끼리 한 줄로 표시되게 하는 방법입니다.

합쳐질 branch의 commit 내역을 마지막 commit으로 rebase하고나서 합칩니다.
squash and merge와는 다르게 모든 커밋이력들이 rebase 되어서 붙는 방법입니다. 
이 방법은 언제 merge가 되었는지를 알 수 없는 방법이긴하지만 모든 commit history를 가지고 합칠 수 있다는 장점이 있습니다.

단점

• rebase의 치명적인 단점 중 하나는 바로 충돌(Merge Conflict)이 발생했을 경우입니다.
• merge할 branch의 히스토리 자체를 그대로 복사해서 대상 branch의 히스토리에 넣어버리는 방법이기 때문에 충돌이 발생하게 되면 Merge commit이나 Squash and merge처럼 충돌이 한번 발생하는 것이 아니라 각각의 커밋에 하나씩 충돌이 발생합니다.
• 이게 merge할 branch의 commit이 몇 개 안되는 상황에서는 할 만할지 몰라도 commit이 몇 백개씩 되는 큰 기능의 branch를 rebase로 merge 했다가 충돌이 나면 너무 힘들기 때문에 개인적으로 추천하지 않는 방법입니다.

Rebase and merge

commit histroy는 commit들이 모여서 시간 순으로 정렬된 것입니다. git graph라는 vscode 확장프로그램을 설치한다면 그래프 형식으로 볼 수 있답니다.

# git history를 보다보면 HEAD을 볼 수 있습니다.
HEAD - 내가 현재 작업하고 있는 장소 (어떤 공간에 있는지 보여주는 것 입니다.) 
ex) 현재 main branch에서 작업하고 있다면 HEAD는 main branch에 있습니다.

 

[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog

참고 사이트