어제의 최선

브랜치는 자주 분기하고 커밋 단위는 깔끔하게! 업무 컨텍스트가 바뀌면 브랜치를 분기하고, 작업 후 여러 커밋들을 `squash`해서 유의미한 커밋 메시지 단위를 유지하는 것이 좋다고 생각했다. 실제로 그렇게 했을 때 `revert`하기도 편하고 커밋히스토리도 비교적 깔끔하게 관리되기 때문이다. 하지만 최근에 브랜치 전략을 설명할 일이 생기면서, 다른 회사의 브랜치 전략들을 찾아봤는데 잘못 알고 있던 정보들이 많아 글로 정리한다. 커밋은 적어도 하루에 한 번 유의미한 커밋을 만들어 내는 것은 좋지만, 그것보다 내가 작업한 결과물을 동료들에게 빠르게 공유하는 것이 훨씬 중요하다. 왜냐하면 소스 통합 시 발생하는 충돌(conflict)때문이다. 개인적으로 충돌을 많이 경험하진 못했지만, 발생할 때마다 스트레스..

다른 깃 명령어들도 많지만, 기본적인 것을 제외한 내가 자주 쓰는 명령어 위주로 정리했다. stash git에 의해 추적되고 있는 파일들을 임시로 보관한다. 나같은 경우에는 작업 중에 우선순위가 높은 작업(오류)이 생겨서 급하게 처리해야할 때 자주 쓴다. $ git stash save 명시적인기록 $ git stash --keep-index $ git stash -u stash 스택 조회 $ git stash list stash 적용, 부분이 생략되면 스택 가장 윗부분이 적용됨 $ git stash apply stash 제거, 부분이 생략되면 스택 가장 윗부분이 제거됨 $ git stash drop stash 스택 적용 및 삭제, 부분이 생략되면 스택 가장 윗부분이 제거됨 $ git stash pop 브..

서론 최근에 학원에서 팀프로젝트를 하나 했는데, git branch에 익숙하지도 않고 시간에 쫓기다보니 그냥 master branch에 다 커밋했었다. 그러다보니 깃허브 커밋 이력이 엉망진창이다. 이번 기회에 글을 정리하며 깃허브 커밋 관리에 대해 좀 더 이해해보려 한다. Git Flow 예전에 branch를 공부하면서 얼핏 본 기억이 나는 그림이다. 배울 당시에도 좀 복잡했지만 실무에서는 이렇게 쓰겠구나하는 감이 와서 좋았었다. 위 그림만 봐도 어떻게 브랜치 형상관리가 이뤄지는지 알 수 있다. branch는 총 5개로 구분해서 관리한다. master : 제품으로 출시될 수 있는 브랜치 develop : 다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 release : 이번 출..