멘토링 과제를 하면서 처음으로 Branch를 생성해서 PR을 올리는 과정을 진행해보았는데.. 브랜치 에러에다가 갑자기 폴더가 합쳐지고, 작성한 코드가 일부 사라지기도 하면서 커밋에 대한 두려움이 생겼다.
그 두려움을 없애고자 Github 커밋에 대해 정리한 블로그를 포스팅해보고자한다. 다른 에러 이슈가 등장할 경우, 그에 대한 이슈까지 업데이트할 예정이다.
Branch에 커밋하는 방법은 다양하게 있지만, 내 경우 다음과 같은 과정이 가장 간단했다. (feat. 에러도 나지않았다!)
Branch Naming은 멘토님이 추천해주신대로 feature/code-*
와 같은 형식으로 구성했다.
깃허브에서 main branch를 정하고, 하위 branch를 생성한다.
원격 저장소의 특정 branch만을 따로 clone한다.
a. 원격 저장소를 clone한 후에 그 폴더에서 작업하고, 커밋하자!
git branch
로 현재 branch를 확인한다.
git add .
git commit -m”commit msg”
git remote add origin “github repo url”
git push origin “branch name”
특정 Branch만 따로 clone
하고 싶은 경우는 -b
옵션을 이용하면 된다. 예를 들면 주소가 https://github.com/suri-pu-bi/suri-pu-bi.git 원격 저장소의 feature/code-1
이라는 이름의 Branch만 따로 clone
해오고 싶은 경우는 다음과 같이 사용할 수 있다.
git clone -b feature/code-1 https://github.com/suri-pu-bi/suri-pu-bi.git
git clone -b **[**Branch 이름] **[**저장소 URL]
git branch -a
: 모든 브랜치 목록확인
git branch -r
: 원격저장소 브랜치 목록확인
이걸 했을 때 아무것도 뜨지 않는다면, 작업폴더에 원격저장소를 업데이트시키는 작업 필요
→ git remote update
git checkout “branch name”
: 현재 Branch에서 다른 Branch로 이동
git push
를 했을 때, 가장 많이 뜨는 에러 Fetch First Error
→ git pull -—rebase origin main
: 동기화를 위해 pull
우테코 프리코스 10기에 지원만 해봤었는데 여기선 커뮤니티 활동이 굉장히 활발하게 이루어졌다. 나름 내 스스로 커밋을 언제 해야하는지 고민이 굉장히 많았는데, 커뮤니티에서 동일한 내용의 글이 올라왔다. 많은 사람들이 공감해주었고, 다양한 의견들이 제시되었다.
그 중에서 인상깊었던 댓글 두개를 가져와봤다.
1번을 선택하신 분들의 메인 의견은 협업의 관점에서 내 코드로 인해 작동이 제대로 되지않았을 때 팀원들이 불편을 겪을 수 있으므로 테스트를 충분히 하고, 커밋을 하자는 것이었다. 그러나 크민님은 1번에서 기능이 잘 동작하는지 완벽하게 확인한다는 건 불가능하다는 것을 언급하시면서 2번을 선택한 이유를 잘 말씀해주셨다.
스티브님 같은 경우 1번과 2번의 문제점들을 다 해결하는 좋은 방법인 것 같아서 가져왔다.
결국 나는 개인으로는 커밋 주기를 짧게가져가도록 하면서, 협업을 할 때는 공동으로 관리하는 브랜치를 하나 만들고, 팀원별로 각자 브랜치를 생성한 후에 최소 단위 커밋을 실행하는 것이 좋다고 판단하였다.
이 분의 커밋 로그가 인상깊었어서 참고하면 좋을 것 같다.
https://github.com/woowacourse-precourse/javascript-racingcar-6/pull/169
이 분은 Read.me를 정말 잘 해놓으셔서 나중에 참고하고 싶어서 가져왔다.
https://github.com/woowacourse-precourse/java-racingcar-6/pull/356
세상엔 능력자가 너무 많다. 배워야할 길이 산 넘어 산이지만..
인생은 기니까 너무 조급해하지말고, 몇년에 걸쳐서 결국 다 알게되자! 라는 마인드를 가지고 가야겠다.