1인 이상의 팀

프로젝트 저장소 로컬 사본에 이미 설정된 원격 설정이 있는지 살펴보자.

snippet.shell

git remote --verbose

모든 로컬 브랜치를 다른 이들과 공유하고 싶다면 다음 명령어를 사용한다.

snippet.shell

git push --all origin

작업 진행 상황을 중앙 서버에서 공개하고 있다면 작업을 리베이스할 때 주의해야 한다. 커밋이 리베이스되면 수정된 커밋 객체의 메타데이터에 새로운 확인자가 할당된다. 예컨데 브랜치를 최신 상태로 업데이트하면 로컬 커밋은 새 부모와 새 ID를 갖게 되는 것이다. 브랜치 히스토리를 정리하려고 두 개의 커밋을 하나로 합쳤다면 내용이 바뀌지 않았다 해도 합쳐진 커밋 객체에 새 ID가 할당된다. 이런 이중 타임라인이 생기면 Git이 착각해 충돌이 일어날 수 있다. 이와 같은 충돌을 피하려면 티켓 브랜치 같이 한시적인 브랜치에만 인터랙티브 리베이싱을 사용하는 것이 좋다.

훌륭한 커밋 객체는 다음과 같은 특성이 있다.

• 오직 관련된 코드만 포함한다. 스코프 크립도 없고 “여백 수정”도 없다.
• 코드 내 문서화를 포함해 프로젝트 코딩 표준을 따른다.
• 적당한 크기다. 보통 100줄 정도의 코드를 말한다. 또는 함수 이름이 바뀌고 영향을 받는 코드가 1,000줄 정도인 대규모 리팩토링도 여기에 포함된다.
• 작업을 설명하는 최적의 커밋 메시지를 포함한다.

내가 들어본 최상의 커밋 메시지 작성 규칙은 “미래의 내가 과거의 나에게 게을렀다고 화내지 못할 정도”로 작성하는 것이다. 커밋 메시지에는 다음과 같은 사항을 포함해야 한다.

• 쉬운 로그 검색을 위한 표준 형식을 갖춘 간략한 설명(60자 이내)
• 현재 코드의 문제점을 좀 더 자세히 설명하고 해당 수정사항이 중요한 이유을 적는다
• 고급 수준 언어로 문제를 어떻게 해결했는지 설명한다.
• 수정사항이 일으킬 수 있는 잠재적 부작용을 개략적으로 설명한다
• 수정사항에 대한 요약을 적어 코드 변경점만 확인하면 커밋 메시지를 확인할 수 있도록 한다. 단 변경사항/변경 이유를 어림짐작으로 코드 변경사항을 확인해서는 안 된다.
• 제안된 수정사항에 대한 논의 사항을 볼 수 있는 티켓 번호 또는 소스에 대한 다른 참조를 적는다.
• 수정사항에 영향을 받는 이들이 누군지 적는다(예: 개발자를 위한 최적화, 유저를 위한 속도 개선)
• 추가 문서 업데이트할 곳 목록을 적는다.