깃허브는 프로그래밍 협업에서 정말 중요한 툴이다.
아직 협업 과정에서 깃을 제대로 사용해본 적이 없는 나로서 브랜치 라는 개념이 왜 필요한지 항상 궁금했었는데 이번에 파이널 프로젝트를 준비하며 개념 정리를 해보려고 한다.
Why?
브랜치를 사용하지 않고 main 하나로만 작업을 하면 두 가지 불편사항이 생긴다.
- 버전 관리
프로젝트의 규모가 커질수록 개인이 맡는 파트가 다양해지고 그러다보면 맞춰야 하는 버전이 각기 다를 것이다. 이런 상황에서 main 브랜치에서 매번 가상환경으로 바꿔가며 진행하기엔 상당히 불편하다.
- 코드 충돌
깃은 의외로 예민한 친구라 커밋 충돌이 빈번하다. 특히 사용자가 많아질 수록 서로의 커밋이 꼬일 상황이 많이 발생하고 심지어는 코드가 날아갈 때도 많다.(pull을 하지 않고 커밋을 진행한다든지...)
이 두가지 상황을 타파하기 위해 사용하는 개념이 바로 브랜치 다!
예를 들어, 게시판 기능은 A가 맡고 로그인 기능을 B가 맡아 수행한다면 각자가 브랜치에서 작업을 하고 main에 병합하며 프로젝트를 진행한다.
그렇다면 브랜치의 브랜치도 될까?
정답은 Yes!!
- master(main): 정식 배포판
- develop: 다음 버전 개발 용도
- feature: 기능 단위의 브랜치(예. 로그인, 게시판 등)
방법
브랜치 생성 및 이동
- 분기하고자 하는 브랜치에서
git branch {브랜치 이름} - 브랜치 이동시
git checkout {브랜치 이름}
test 브랜치에서 test.txt를 생성했다.
아래 이미지와 같이 main 브랜치에선 test.txt가 안 보이고 test 브랜치에서만 보인다.
브랜치 병합
이 상황에서 깃허브를 들어가보면 아래와 같이 병합을 할 것이냐 묻는 메시지가 나온다.
"Compare & pull request" 버튼을 누르고 원하는 코멘트를 작성후 "Create pull request"
Merge pull request
Confirm merge
그러면 main 브랜치에도 텍스트 파일이 생긴 것을 확인할 수 있다.
의문 사항
나는 "알쏭달쏭" 프로젝트의 브랜치를 위와 같이 만들었다.
그러면 다른 깃 사용자의 터미널에도 반영이 될까?
아마 지금 git branch 명령어를 쳐보면 안 보일 것이다.
왜냐하면 원격 리포지토리에는 생성이 되었지만 로컬에 반영이 안되었기 때문이다.
이를 확인하기 위해서는 git branch -a 명령어로 연결이 안 된 브랜치를 확인 후 연결하고 싶은 브랜치로 이동(git checkout {브랜치 이름}) 하면 된다.
주의 사항
깃허브는 최대 50메가 바이트 크기의 업로드만 지원해준다.
더 많은 용량의 파일을 업로드 하려면 git LFS(Large File System)를 사용해야 한다.
한번 잘못 업로드하면 커밋 내역을 다시 되돌려야 하는 귀찮은 일이 발생하니 웬만하면 코드 위주로만 업로드 할 것 ^^
레퍼런스
https://velog.io/@seung_min/Github-깃허브와-브랜치를-이용해-협업하기
https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html
