Medium - Six Rules for Good Git Hygiene
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 올바른 깃 건강을 위한 6가지 규칙; 어떻게 팀원들과 커밋하고 푸시하고 풀 할것인지
Photo by Yancy Min on Unsplash
깃은 모든 개발자를 위한 도구라고 할만큼 지배적인 소스 컨트롤 시스템입니다. 회사에서 팀의 협업을 관리하는데 쓰이거나 전 세계의 개발자들이 함께 작업할 수 있는 오픈 소스 프로젝트를 실행하는데 쓰입니다. 팀으로 작업하는 것에 익숙해지는 것은 새로운 개발자가 꼭 배워야 하는 것입니다. 공유되는 코드를 기반으로 작업하는 것 이상의 것이죠. 결과적으로 깃은 새로운 개발자의 도구 리스트에 필수적인 것입니다. 팀원부터 팀장까지 로컬과 원격 저장소를 적절하게 관리하는 법을 아는 것은 매우 중요한 스킬입니다. 다음 6가지 팁들은 여러분이 올바른 깃의 시민으로서 여러분의 팀 코드 저장소를 깔끔하고 충돌없이 유지할 수 있도록 하는데 도움이 될 겁니다.
Always Pull Before a Push
이것이 가장 기본적인 룰입니다. 저장소 밖에서 코드를 푸시하기 전에 여러분은 항상 원격 저장소의 변경사항을 pull해서 여러분의 로컬에 반영시켜야 합니다. 이렇게 하는 것은 여러분의 로컬 복사본이 원격 저장소와 동기화 된 것을 의미합니다. 기억하세요, 다른 사람들이 푸시를 해온 원격저장소에 여러분이 싱크를 맞추지 않고 푸시를 하면 여러개의 헤드를 발생시키거나 머지 충돌을 발생시킬 것입니다. 기본적으로 깃은 원격 커밋이 있는 곳에 푸시를 하지 못하도록 막아놨습니다. 이 피쳐를 끌수도 있지만 그다지 추천하지는 않습니다.
Pull frequently
큰 규모의 팀에서는 중앙의 저장소가 끊임없이 바뀝니다. 여러분은 항상 로컬 머신을 원격 저장소와 가능한 최대로 동기화 시켜야 합니다. 이렇게 하는 방법은 원격 서버의 변경사항을 여러분의 로컬로 pull 하는 것입니다. 여러분이 내키는 대로 하셔도 되지만 최소한 하루에 한번은 하셔야 합니다.
push infrequently
여러분이 푸시를 하면 여러분의 변경사항이 다른 곳에 영향을 미치게 됩니다. 푸시 작업은 빌드를 박살내지 않는 다는 것을 알고 있을 때 해야하며 신중하게 여러분이 푸시하는 것을 리뷰해야 합니다. 기억하세요 푸시를 할 때 모든 사람은 여러분이 완료한 것으로 생각합니다. 확실하게 하세요.
Commit frequently
많은 개발자들은 커밋을 충분하게 하지 않습니다. 항상 많은 변경을 만든 다음에 결과적으로 적절하지 않게 모든 변경사항들을 기술합니다. 이것은 리뷰를 크게 만들며 이러한 커밋은 비생산적입니다. 대신에 커밋을 자주 작게, 하나의 변경사항으로 커밋 메시지를 만들어서 수행하세요. 이해하기 쉬운 많은 커밋들이 문제가 되는 경우는 없습니다. 모든 커밋들은 논리적이어야 하며 여러분의 코드 변경사항과 구분되어야 합니다. 커밋 메시지에 and가 필요하다면 여러분은 커밋을 충분히 하지 않은 것입니다. 작은 커밋은 나중에 필요할 경우 되돌리기도 쉽습니다
Merge “forward” frequently
여러분이 일반적인 깃 워크플로우를 가지고 있을 때 많은 시간의 대부분을 디벨롭 브랜치에서 따온 피처 브랜치에서 작업할 것입니다. 여러분의 브랜치가 어디서 파생되었든 여러분은 자주 원본 브랜치를 여러분의 것으로 머지해야 합니다. 이렇게 함으로써 여러분의 브런치가 원본 브랜치로부터 너무 멀리떨어지지 않도록 보장할 수 있습니다. 기억하세요, 다른 사람들이 원본 브랜치를 변경할 것입니다. 제한된 머지 충돌은 여러분의 삶을 더욱 편하게 만들 것입니다.
Create Pull Requests Infrequently
여러분이 foward 머지를 여러분이 원하는 만큼 하는 동안 여러분은 PR을 하고 여러분의 코드를 부모 브랜치에 머지를 할 때 더욱 주의해야 합니다. 여러분의 조직은 아마 PR에 대한 규칙이 있을 것이고 여러분은 그것을 따라야 합니다. PR은 사람들에게 여러분의 코드를 봐달라고 부탁하는 것이기 때문입니다. 여러분은 PR을 코드가 안정적이고 결과적으로 깔끔하고 완벽하게 되었을 때 날려야 합니다. 다시한번 말하지만 여러분이 PR을 묘사하는데 and가 필요하다면 너무 큰 것입니다.
PR은 주의를 기울여서 너무 빈번하지 않게 보내야 합니다
Summary
- 건강한 깃 시스템을 만드는 매너
- 항상 push를 하기 전에 pull을 할 것
- 작은 단위로 커밋을 할 것
- 원본 브랜치로 피처 브랜치를 따왔다면 원본 브랜치 pull을 많이 할 것; 부모 브랜치의 변경사항을 최대한 피처 브랜치에 동기화;
- PR은 코드가 깔끔하게 정리되고 모든게 완벽할 때마다 가끔씩 날릴 것;
- 커밋이나 PR 메시지에 and가 들어간다면 너무 큰 규모로 만든 것이다; 더욱 작게 만들자
