팀을 위한 Git

1

조엘 테스트 덕분에 CVS를 알게 되었다. 회사를 다니면서 SVN을 사용하다가 요즘엔 Git을 사용하고 있다. 요즘에는 Mercurial을 사용하는 회사도 간혹 보곤한다. 결론은 SVN이 되었든, Git이 되었든 CVS를 사용하는건 이제 유행이 아니라 필수가 되었다.

2

인류문화유산의 보고라고 할 수 있는 GitHub덕분에 Git 사용이 보편화 되었음에도 불구하고, 많은 사람들이 Git을 잘 사용하는 방법에 대한 고민은 끝이없다. 이 책은 Git을 잘 사용하고 싶은 ‘개인’이나 ‘팀’에게 무척이나 유용하다. 특히 ‘3장의 브랜치 전략’과 ‘4장의 효과적인 워크플로우’ Git을 처음 사용하는 개인과 팀에 많은 도움이 될것으로 생각된다.

3

대부분 다루고 있지 않는 GitLab을 다루고 있기 때문에 평소에 궁금했던 점을 해소할 수 있었지만, 결론적으로 GitHub내용이 좀 더 풍부했으면 좋겠단 생각을 하게 되었다.


  1. 실제 수강생의 상당수는 기술적 문제가 아니라 정치적 문제에 부딪혔다.

  2. “끝을 생각하며 시작하라”는 말을 들어본 적이 있는가? 소프트웨어 개발할 때면 항상 다른 누군가를 위해 개발했다. 아무리 생각해봐도, 내가 개발한 제품 중에 혼자 만지작거리자고 개발한 것은 없었다. 난 천성이 해커는 못 된다. 애초에 소프트웨어 개발에 매력을 느낀 것도 내가 개발한 소프트웨어가 다른 사람에게 도움이 되었기 때문이다.

  3. 개발 환경을 최대한 최종 제작 환경과 비슷하게 맞춰야 한다.

  4. 너의 모든 리베이스는 우리에게 속한다. 리베이스를 사용하는 방법에는 두 가지가 있고, […] 첫째, 병합 방법의 대안으로 새로운 작업을 관련 브랜치에 통합하는 방법이다. 둘째, 기존의 브랜치에 개별 커밋을 추가, 변경, 삭제하는 식으로 히스토리를 고쳐 해당 히스토리를 좀 더 간결하게 만드는 것이다.

  5. rebase 명령어를 사용하면 브랜치를 최신 상태로 업데이트하는 반면, merge 명령어는 완전히 새로운 작업을 적용한다.

  6. 싸울 곳은 스스로 골라라. 같이 일했던 팀들은 개발자들이 적어도 한두 개라도 자신의 티켓을 스스로 할당하길 권장했다. 분명히 특정한 사람만 알고 있는 지식이 필요한 티켓이 있을 수 있다.

  7. 리베이스는 흔히 “히스토리 재생하기”라고 부르지만 좀 더 정확히 정의하자면 시간을 거슬러가 다시 히스토리를 정립하려는 것이라 할 수 있다. […] 리베이스는 Git을 통해 히스토리를 다시 듣는 것이라고 할 수 있다. 원한다면 새로운 사실도 추가해서 말이다. 그러나 과거에 일어나 일을 수정할 수는 없다. 끝난 것은 끝난 것이고, 우리가 할 수 있는 일은 그 끝난 일을 어떻게 이야기할 것인가 밖에 없다. […] 결국 Git은 단순한 콘텐츠 추적기에 불과하다. 전문가가 직접 충돌을 해결하는 것이 항상 더 나은 결과를 낳는다. […] 공개 브랜치를 업데이트 하는 경우에 잘 일어난다. 이런 경우 타임라인에는 같은 코드를 참조하는 둘 이상의 서로 다른 ID를 가지는 커밋 객체가 생긴다.

Written on September 27, 2016