🎃 git으로 일하기
개발자에게 git과 github는 숙명같은 존재이다.
git으로 파일을 추적, 관리하고 github로 협업을 위한 환경을 조성할 수 있기 때문이다.
쉽게 말해 git이 프로젝트의 버전관리 시스템이라면, github은 이의 웹호스팅 시스템이라 볼 수 있다.
git의 간단한 기본 용어에 대해 알아보도록 하자.
깃 저장소(git repository) 란 파일이나 폴더를 저장해 두는 곳으로, 파일이 변경 이력별로 저장된다.
비슷한 파일이라도 일부 내용이 다르다면, 다른 파일로 인식하여 변경 사항별로 구분해 저장하는 것이다.
이 저장소는 원하는 경로에서 git init 명령어를 통해 만들 수 있으며 그 순간부터 git은 버전 관리를 시작한다.
그 외의 용어들이다.
- Staging Area : 저장소에 커밋전 커밋을 준비하는 위치 (Tracking 시작)
- Commit : 변경된 작업을 저장소에 저장하는 작업
- Branch : 분기점. 작업할 때 현재 상태를 복사하여 만든 하위 작업 공간
- Head : 현재 작업중인 브랜치
- Merge : 다른 Branch 내용을 현재 Branch로 가져와 합치는 작업
보통 git 명령어를 통해 버전 관리를 하는 로직은 다음과 같다.
1. git status => 수정, 변경, 삭제된 파일이 있는지 확인한다.
2. git add .(or 파일명) => 파일을 staging area로 이동 시킨다.
3. git commit -m "커밋 메세지 입력" => git을 이용해 로컬 저장소에 파일 저장
4. git push origin main (or 브랜치명) => 외부 저장소 (github)으로 푸쉬
4번같은 경우 git remote add (github 레포지토리 주소)를 통해 외부저장소와 연결했다는 과정아래 진행할 수 있다.
🎃 github으로 협업하기
협업은 어떤 방식으로 진행할 수 있을까?
- 작업할 브랜치 따기
- 작업한 부분 commit-push 후 PR 날리기
- 외부저장소에서 merge
- 내 로컬 main(or develop)으로 이동해 변경 사항 pull 받기
- 작업 브랜치로 이동 후 merge 하기
프로젝트 초기세팅 후, 맡을 티켓이 정해지고 나면 팀 컨벤션에 맞춰 내가 작업할 branch를 git checkout -b feature/브랜치명 이란 명령어를 통해 딴다.
작업을 완료하면 git 명령어로 위의 과정을 통해 github(외부저장소)에 호스팅한다.
이 때, 내가 작업하는 브랜치로 푸쉬하고 github 웹레포지토리로 이동해 PR (Pull Request)라는 것을 날린다.
PR이란 merger될 대상(보통 main이나 develop)에 합쳐지기 전, 다른 사람에게 검토해 달라고 날리는 요청이다.
PR이 승인되고 나면 외부저장소에서 merger가 이루어지게 되기 때문에 다시 내 로컬 저장소를 업데이트 해주는 과정이 필요해진다.
로컬 파일에서 main(or develop)으로 이동하여 pull 받기 git pull origin main => 기존에 작업하던 브랜치로 이동 => git merge main
혹시 다른 사람과 같은 부분을 수정했을 경우, 충돌이 날 수 있는데 침착하게 바로잡고 다시 커밋하면 된다.
이것이 바로 github같은 협업툴을 쓰는 이유이기 때문이다. 동시에 병렬적으로 작업함에도 결과물은 충돌없이 합쳐지도록 하기 위해서!
🎃 git flow로 똑똑하게 개발하기
git-flow란, git이 활성화되기 시작하는 10년전 쯤 사람의 블로그 글에 의해 널리 퍼져 현재는 Git으로 개발할 때 거의 표준과 같이 사용되는 방법론이자 개발 프로세스이다.
소스코드 관리와 배포의 유연함을 제공하는 장점을 갖는데, 각 브랜치는 무엇을 의미하는지 알아보자.
Master : 최종적으로 배포되는 서비스를 위한 브랜치
Develop : 배포를 위한 개발을 진행하는 브랜치
Feature Branches : 배포에 필요한 기능들을 추가하고 개발하는 브랜치로, 기능 구현 완료시 develop 브랜치로 merge
Release Branches : 배포를 위해 master로 보내기 전 QA를 하는 브랜치이자 출시 후 버그 픽스를 수행하는 브랜치
Hotfixes : 서비스 출시 후 빠르게 수정되어야 할 버그를 잡기 위한 브랜치
브랜치 생성으 master -> develop -> feature 순으로,
코드 통합은 역순이 feature -> develop -> release -> master 로 진행되게 된다.
Gitflow의 장점
- 독릭적인 개발 환경
gitflow 사용시 기능 단위로 브랜치를 만들기 때문에 다른 사람의 개발에 영향을 받지 않는 독립적인 개발환경을 만들어준다. - 배포 정책 및 CI/CD 연동
브랜치 별로 역할이 분리되어있기 때문에 각 브랜치의 update에 맞춰 배포와 테스트를 하기에 용이하다. - 더욱 효율적인 병렬 개발
gitflow는 완료된 작업에서 새 개발을 분리해 병렬 개발을 더 용이하게 만든다. 배달의 민족이 해당 브랜치 전략을 사용하는 이유라고 밝힌 부분이기도 하다.
🎃 git rebase & git squash?
git rebase란 말 그대로 base를 다시 설정한다는 의미의 명령어다.
예를 들어 초기 세팅만 한 버전 1의 develop에서 feature 브랜치를 땄을 경우, 해당 featrue 브랜치의 base는 버전 1이다.
누군가의 PR이 머지된 이후 버전 2가 된 develop로 base를 바꾸는게 바로 rebase인 것이다.
rebase를 하는 이유는 git history가 병렬적이 아닌 일렬로 남기 때문에 그 이력을 한 눈에 파악하기 쉬워지기 때문이다.
이것이 바로 git merge와 git rebase의 가장 큰 차이점이다.
명령어는 git rebase -i main (or develop)인데 여기서 i 옵션은 커밋 이력과 변경이 가능한 화면을 보여줌을 의미한다.
squash를 위한 화면이라고 말할 수 있는데, 그렇다면 git squash는 무엇일까?
squash는 "억지로 밀어 넣다"라는 의미로 여러 커밋 로그를 하나로 묶을 수 있는 명령어인 것이다.
최신 커밋 로그들을 가장 오래된 커밋(pick)에 squash(밀어 넣기)한다.
squash를 하는 이유는 여러개의 커밋을 가진 파일을 계속 rebase하고 머지할 경우, main(or develop) 브랜치의 history가 너무 길어져 되려 이력을 파악하기 어려워질 수 있기 때문이다.
그래서 필요한 것이 git squash인 것이다!
🔗 참고자료
git과 github란?
gitflow
우린 Git-flow를 사용하고 있어요
[GIT] Merge vs Rebase 차이
