3. 작업 마무리
하나의 작업 단위가 끝나면 깃허브 프로젝트 저장소에 push한다.(모든 작업을 한 브랜치에서 한번에 작업하고 단 한번의 푸쉬를 하기 보다는 작업단위를 잘게 쪼개는 것이 좋다) 하지만 github를 처음 사용하고, 타인과 함께하는 프로젝트라면 첫 push나 pull한 번이 너무 어렵다. 실수해서 모든게 다 날아갈 것 같은 두려움이 들기 때문이다. 그래서 push하기 전 백업을 해두기도 했다. 다행히 이번 프로젝트에서 깃허브로 실수한 일은 없지만, 미래의 실수를 방지하기 위해, 편한 마음으로 git을 사용하기 위해 이 글을 쓴다.
깃 초심자가 가장 두려워 할 상황은 아무래도 push했을 때 conflict가 발생하거나 남의 파일을 다 날리는 두 가지 일 것이다. conflict가 발생하더라도 팀원들과 조율해 처리하면 그만인데, 처음에는 그 상황이 굉장히 당황스럽다. 나도 이번 프로젝트 도중 conflict가 발생한 적이 몇 번 있었는데, 확실히 글로 읽어서 이론으로만 알던 것보다 직접 해보니 별 것 아니구나 라는 생각이 들어 깃을 사용하는데 두려움이 많이 줄어들게 됐다.
1) push, pull
일단 commit을 하면 push를 할 차례다. 하지만 push하기 전 pull 하는 것이 좋다. 내가 작업 하던 중 다른 팀원이 작업을 해 이미 원격에서 merge 됐을 수도 있기 때문이다.
git checkout master # master브랜치로 이동
git pull origin master # 원격 상태랑 local도 동일하게 만들기
git push origin 작업한브랜치명 # 원격으로 push2) pull request, merge
git push까지 완료하고 프로젝트 repository에 접속하면 평소에는 없던 create pull request 라는 초록색 버튼이 우측 중간에 활성화 되어 있다. 풀 리퀘스트까지 완료해야 repository에 저장 될 준비가 완료되는 것이다. 버튼을 누르면 글을 쓸 수 있는 공간으로 이동하는데, 본인의 작업내용에 대해 제목에는 간단히, 본문에는 자세하게 작성하면 된다. 내가 한 프로젝트에는 정해진 pull request 양식이 있었지만, 기본값은 없다. pull request까지 날리면 팀원으로서 할 일은 끝났고, merge결정권자의 코드 리뷰를 기다리면 된다.
난 작업이 merge되면 해당 작업 브랜치는 더이상 용도가 없기 때문에 삭제했다.
git branch -d 삭제할 브랜치 명4. restart
사람마다 수행하는 프로젝트의 크기는 다르지만 일반적으로 프로젝트에서 작업은 한번으로 끝나지 않는다. 위에도 기술했듯 커밋은 작은 단위로 쪼개서 여러번 하는것이 좋다. 그렇다면 다시 작업을 시작할 때는 어떻게 해야할까? 역시 push할 때 처럼 master브랜치에서 pull 먼저 하고 시작해야 한다. 작업의 순서를 간단하게 정리하자면 [ pull -> 작업 -> add -> commit -> pull -> push ] 의 반복이다. 중간 중간 브랜치의 위치를 확인하고 작업하는 것을 잊지말자.
