Git과 Github로 협업은 어떻게 할까?

✨ 오늘 공부한 것

- 알고리즘 뒤에 있는 큰 수 찾기 문제 풀이
- 알고리즘 롤케이크 자르기 문제 풀이
- 스탠다드반 개인 과제

브랜치를 이용하자

브랜치, 말 그대로 가지라는 뜻이다. 기본이 되는 브랜치에서 여러 가지로 뻗어나가 다양한 형태의 코드를 작성할 수 있다. 파일 작업의 관점에서 봤을 땐 "원래 파일은 그대로 두고, 수정을 하고 싶을 때" 사용할 수 있다.

그러나 우리는 이 브랜치를 가지고 협업을 해야한다. 어떻게? 각각의 브랜치에서 각자도생으로 작업을 하고 메인이 되는 브랜치에 합치는 것이다! 이렇게 하면 서로의 작업에 영향을 주지 않고 효과적으로 협업을 할 수 있게 된다.

추가로 알아두면 좋..나? 아무튼 협업을 효율적으로 하기 위한 다양한 브랜치 전략이 있다.

브랜치 전략

보통 다른 사람들과 같이 개발을 할 때, 기능 단위로 업무 분담을 하게될 것이다. A는 게시글 작성 부분을 맡고, B는 게시글 조회 부분을 맡고, C는 로그인 및 로그아웃을 맡고, 등등..

이 모든 작업을 브랜치 하나에서 마구잡이로 하다가는 수정한 파일이 겹치거나 동일한 라이브러리인데 버전이 다른 파일을 설치한다거나 해서 정신이 나가버릴 것이다. 그래서 브랜치를 기능 단위로 나누는 것이 필요하다.

그럼 그냥 나누면 될 것이지 브랜치 전략은 왜 있는 것일까?

지금이야 개인적으로 공부하려고 개발을 하겠지만 만약 나중에 실제 사용자에게 서비스해야 하는 프로그램을 개발한다면, 주기적으로 빠르게 업데이트 되는 서비스가 되어야 이 넓은 시장에서 살아남을 수 있을 것이다. 그런데 빠르게 업데이트만 되고 나사 하나 빠진 기능을 서비스하는 일은 또 없어야 한다.

그래서 실제 사용자에게 서비스 되는 베이스 브랜치를 두고, 그 브랜치를 기준으로 기능 개발 브랜치를 만들어 작업을 하게 된다. 이 방식이 엄청난 고수거나 프로젝트 규모가 콩알만 하다면 안그럴 수도 있겠지만 (나 같은) 응애 개발자한테는 손 떨리는 일이다. 자칫 잘못하다가 기껏 개발한 앱을 다 망쳐버릴 수도 있기 때문이다. 따라서 베이스 브랜치와 기능 브랜치 사이에 dev 혹은 develop 브랜치를 두어 내가 만든 기능이 잘 동작하는지 테스트를 해볼 수 있게 전략을 세울 수 있겠다. 이걸 Git Flow 전략이라고 한다.

다른 전략들도 많지만, 회사마다 팀마다 사람마다 선호하는 방식이 다르기 때문에 그때그때 알아가며 적응해보기로.. 했다.

브랜치 활용

브랜치가 협업에서 얼마나 중요한 녀석인지는 알겠고, 어떻게 사용을 하는 건지 알아보자!

브랜치 생성

# 브랜치 생성
git branch 브랜치이름

git branch로 브랜치를 생성하면, 로컬에 생성만 되고 이동은 되지 않으니 주의하도록 하자.

브랜치 목록 확인

# 초록색이 현재 브랜치
# 화면은 키보드 q로 나갈 수 있다.
git branch

git branch를 하게 되면 브랜치 목록을 확인할 수 있다. 다음과 같이 뜨는데, 누가봐도 초록색에 별 표까지 붙은 feature/login 브랜치가 현재 브랜치임을 알려주고 있다.

브랜치 이동

git switch 브랜치이름
git checkout 브랜치이름

git branch로 브랜치를 생성했다면, switch 또는 checkout을 통해 생성한 브랜치로 이동할 수 있다. 둘 다 같은 역할을 하는데, checkout 명령어가 너무 많은 기능을 갖고 있는데다가, 이름도 두루뭉술해서 최근에 switch라는 명령어가 새로 나왔다고 한다. 많고 많던 checkout의 기능을 switch랑 restore가 나눠가졌다고 한다.

브랜치 생성 및 이동

git switch -c 브랜치이름
git checkout -b 브랜치이름

브랜치 생성과 이동을 한 큐에 할 수 있는 옵션이 있다. switch는 create의 약자 c로, checkout은 branch의 약자 b로 브랜치 생성과 이동을 한 번에 할 수 있다.

브랜치 합치기

# 최종 브랜치에서 다음 명령어 입력
git merge 합칠브랜치이름

이 명령어는 사실 많이 쓰이진 않고, 깃허브의 pull request를 이용해 머지하는 경우가 더 많다고 한다.

Pull Request

• pull: 당겨서 합치는 것 (merge)
• request: 요청하다

내가 이런 작업을 해서 머지하려고 하는데 제 코드 좀 확인해주세요라는 느낌의 녀석이다. 코드 리뷰나 머지 전 충돌 문제를 확인해볼 수 있어 협업을 할 때 정말 중요하다고 한다.

마치며

혼자서 모든 개발을 담당할 땐 잘못하건 말건 아무 상관이 없었지만, 이제는 신경써야되니 좀 무섭다. 그래도 깨부하면서 성장해나가는 거겠지 암암. 화이팅이다.