[원티드 프리온보딩] TIL - (5)

May 7, 2022

5월 7일

협업 시 git 및 github 관리 방법 복기

첫 협업 때부터 지금까지 수 많은 conflict와 실수를 통해 배운 git과 github 관리 방법에 대해 복기를 해보려 한다.

가장 기본적인 명령어

git branch

git branch feature_category

기본적으로 master 브랜치는 최신으로 유지하며, 코드를 수정하고 구현할 일이 생기면 브랜치를 따서 작업을 하면 된다.

git checkout

git checkout feature_category

브랜치 간에 이동할 때 사용하는 명령어다.

git checkout -b feature_category

를 사용하면 브랜치 생성과 이동이 동시에 이루어진다.

git add

git add .

수정된 코드들을 stage하는 단계이다. 코드들이 staged가 되면 commit을 할 준비가 된 것이다. add 뒤의 .은 모든 파일을 의미한다.

git commit

git commit -m "added: Category Component; bugfix: fixed a bug where app crashes when the user presses Add button"

Stage 된 코드들을 본격적으로 리모트 저장소에 올릴 준비를 하는 것이라고 생각하면 된다. 커밋을 할 때에는 커밋 메시지를 적어줘야 하는데, 이 메시지에는 어떠한 구현과 수정 사항이 있었는지 구체적으로 적어주면 좋다.

처럼 적을 수 있다.

git push

git push origin feature_category

커밋된 코드들을 리모트 브랜치에 올리는 명령어다. 반드시 로컬 브랜치와 이름을 똑같게 해줘야 push가 제대로 이루어진다.

git pull

git pull origin main

리모트 브랜치로부터 로컬 브랜치로 파일과 코드를 불러오는 명령어다. 두 개의 브랜치를 합쳐야 하는 상황이 아니라면 리모트 브랜치와 로컬 브랜치는 일치시켜줘야 한다.

Merge와 Conflict

작업을 완료했다면 그 작업을 master 브랜치에 합쳐야 하는 순간이 온다. 이럴 때는 Pull Request를 통해 현재 작업한 내용물이 올라가 있는 리모트 브랜치와 master 브랜치를 merge하도록 요청하면 된다.
하지만 이 과정에서 코드 간의 충돌인 conflict가 발생할 수 있다. 컨플릭트는 반드시 해결해야 하며 제대로 해결하지 못할 시 모든 작업물이 망가질 수 있어 조심해야 한다.

해결 방법

```
 git checkout feature_category
```
우선 merge하고자 하는 브랜치로 이동한다.
```
git pull origin master
```
master 브랜치에 있는 파일과 코드, 그리고 커밋 내용을 로컬 브랜치로 가져온다.
컨플릭트가 발생하는 파일들에 대해 incoming change와 current change를 잘 구분하여 삭제할 코드는 삭제하고 남길 코드는 남기는 등의 행동을 통해 컨플릭트를 해결한다.

git add .
git commit -m "conflict: conflict resolved"
git push origin feature_categroy

컨플릭트가 모두 해결된 파일들을 다시 리모트 브랜치에 push 한다.

Pull request를 통해 master 브랜치로 merge한다.

Jaeseok Moon