[git] 협업에서 git 사용하기

Juno·2021년 2월 12일

✏️ 들어가기

안녕하세요 😄
오늘은 처음으로 해커톤을 경험하고 git을 통한 소스코드 관리를 했던 경험을 바탕으로
주로 사용되는 명령어들을 모아 정리하고자 포스팅을 하게 되었습니다.

1. git branch 확인하기

git branch
git branch -a // 로컬 브랜치 목록 조회하기 
git branch -r // 원격 브랜치 목록 조회하기

branch는 origin branch(원격 브랜치)와 local branch로 나뉘는데요,
저희가 작업하는 공간은 local branch 가 될 것이고 작업한 내용을 팀원들에게 공유하기 위해 origin branch로 push 하게 됩니다.

2. branch 생성 및 이동하기

git branch <branchName> // <branchName> 브랜치 생성
git checkout <branchName> // <branchName> 브랜치로 이동
git checkout -b <branchName> // <branchName> 브랜치 생성과 동시에 이동

|-main
|-dev - | - feat/main
	| - feat/detail
    	| - feat/view

보통 다음과 같은 구조로 작업을 하게 되는데요, 필요에 따라 branch 를 만들고 branch 를 옮겨 다니야 할 때 위와 같은 명령어로 이동하고 생성할 수 있습니다❗️

추가적으로, 위의 구조처럼 main에서 dev로 분기하고, dev에서 feat/main 으로 분기하는 등의 계층적 구조를 갖도록 하기 위해서는

// main branch에 checkout 된 상태에서
git branch dev/feat/main

과 같이 입력하면 한번에 계층적인 구조로 branch를 만들 수 있습니다 〰️

또한, local에서 만든 브랜치에 대한 origin 브랜치를 원격 레포지토리에도 만들고 싶은 경우에는

git branch <branchName>
git push origin <branchName>

명령어를 통해 원격 레포지토리(orgin repository)에도 생성할 수 있습니다.

3. 작성한 코드 push 하기

가장 기본이 되면서도 핵심적인 내용입니다!
working directory는 말 그대로 우리가 작업하는 공간입니다.
원래의 코드가 A 였고, a 라는 코드가 추가되어서 A' 라는 코드가 되었다고 생각해 봅시다.
이때 a 라는 코드 즉, 변경 사항들 (modified)을 staging area에 올리게 됩니다.

git add <staging area에 올리고 싶은 경로>
git add .

git add 를 통해 올리게 되는데, 이때 local repository에 올리고 싶은 내용들만 골라서 변경된 사항들만 올릴 수 있습니다.

staging area 에 올라간 내용들(레포지토리에 올리고 싶은 변경 사항들)을 git commit 명령어를 통해서 local repository에 올릴 수 있습니다. 보통은 다음과 같이 사용합니다.

git commit -m "커밋 메시지"

커밋 메시지를 작성하는 팁은, 해당 링크 를 참고하시면 도움이 될 것 같습니다! (궁금하신 점은 문의주시면 알려드릴게요😄)

이제 마지막 단계 입니다.
local repository에 commit 메시지와 함께 올려놨으니, local에서 뿐만 아니라 모두가 볼 수 있는 origin branch에 올리기 위해서 git push origin 명령어를 통해 실제로 push 할 수 있습니다.

git push origin <branchName>

여기서 branchName 은 로컬 브랜치의 이름과 똑같은 것을 입력하면, 해당 이름을 가진 origin branch에 push가 됩니다.

4. git pull 그리고 git rebase 와 git merge

협업에선 사실, pull 보단 rebase나 merge를 더 많이 사용하게 됩니다.
기본적으로 pull은 origin branch와 local branch의 상태를 맞춰주기 위해 사용합니다.

가령, feature 브랜치에서 기능을 구현하던 도중에 반드시 반영해야 하는 master 브랜치의 변경사항이 생겼다고 하겠습니다.

먼저 origin master 와 local master 상태를 일치시켜줘야 합니다.

git checkout master // local master 가 되겠죠?
git pull origin master // 다른 사람이 수정하여 새로 업데이트 된 master 내용을 내 local master 에도 받아옵니다.

여기서 명심해야 할 점은,git pull 명령어는 같은 이름의 원격(origin) 브랜치의 변경사항을 로컬 브랜치에 가져오는 것 입니다. 꼭 같은 이름이어야 합니다❗️

새롭게 받아온 master의 내용을 feature 브랜치에 합치기 위해 merge 또는 rebase를 사용합니다.

git checkout feature
git rebase master

위의 그림에서 볼 수 있듯, 반영사항이 변경되기 이전인 b 에서 뻗어나온 f1과 f2 이지만 , 내가 개발한 f1과 f2를 변경사항이 반영된m2 뒤에 이어붙여서 합치고 싶을 때 rebase를 사용합니다.

다음과 같은 형태로 m2 뒤에 f1과 f2를 이어 붙이는 것이죠.
즉, feature의 base를 b가 아니라 m2로 재설정(Rebase)하는 것입니다.

f1이 되면서 생긴 변경사항들을 m2와 비교하여 f1'를 m2에 이어 붙이고, 이어붙인 f1'과 f2가 되면서 생긴 변경사항들을 f1'와 비교하여 이어 붙입니다.

이 과정에서 conflict를 해결 해 주고, 원래 하나의 가지였던 것 처럼 이력을 남기지 않고 그대로 커밋을 가져가게 되는게 rebase의 큰 특징입니다.

merge 역시 같은 역할을 하지만,

합친 내용을 비롯하여 모든 커밋 히스토리를 그대로 남기게 됩니다.
그에 반해 rebase는 커밋 기록을 rebase 하면서 원래 하나의 가지에서 나온 것 처럼 커밋을 합칩니다.

5. pr (pull request) 보내기

pull request 는 협업에서 내 코드를 합쳐달라는 요청을 보내기 위해 사용합니다.

rebase를 통해 master 브랜치의 내용을 feature로 받아왔고, 거기에 추가로 feature 브랜치에서 기능 구현이 완료되면 그 내용을 실제로 반영하기 위해 origin feature에 push 한 뒤 master branch로 pull request를 보내게 됩니다.(실제로는 보통 개발 브랜치인 develop 브랜치로 보내게 되겠죠.)

구현 완료 후 origin branch에 푸시하고 github에 방문하게 되면, pull request를 생성할 수 있는 버튼이 활성화 됩니다.

다음은 feature/letter 브랜치에서 작업한 내용을 develop 브랜치에 반영해 달라고 pull request를 보낸 모습이며, 리뷰어가 코드를 확인 한 뒤 더 좋은 코드로 바꿔나가며 최종적으로 합쳐도 된다고 판단이 들었을 때 리뷰어가 merge를 하는 것이 일반적 입니다.