Git 처음 사용자의 이해를 돕기 위한 그림
devOps를 진행하면서 아직 SVN을 사용하고 있는 팀에게 Git의 개념과 핵심 명령어들을 알려주기 위하여 도식화한 그림들이다.
DevOps를 하는데 Git이어야 하는가? 그렇다고 강력히 생각한다. DevOps에서는 작은 변화를 자주 커밋(commit)하는 것이 필수적이다. 어떤 변경이 적용되었는지 추적하기 용이하도록 하기 위함이다. SVN을 사용하는 팀들은 자주 커밋하지 못할 뿐더러 수일에서 몇 주 동안 자신이 개발 중인 것을 저장소에 커밋하지 않는 경우도 종종 있다. 아직 개발 중인 코드를 저장소에 커밋하였다가 빌드가 안되거나 런타임에 문제를 발생시키지 않을까 염려해서 일 것이다. Git을 이용하면 내 로컬 저장소에 얼마든지 자주 커밋하면서도 원격 저장소에는 푸시하지 않을 수도 있기 때문에 자주 커밋하는 습관을 갖도록 유도하기 용이하다.
브랜치를 만들었다가 다시 머지할 때 충돌이 발생할까봐 두려워 브랜치를 잘 활용하지 않기도 한데, Git에서는 내 컴퓨터에서 얼마든지 브랜치를 생성해보고 머지해보는 연습을 해보며 익숙해질 수 있다. 브랜치 간의 스위칭이 매우 편리한 점도 있다.
Git 핵심 요소들과 가장 많이 사용하는 명령어들
로컬 저장소를 원격 저장소와 연결하는 명령어
브랜치와 관련된 명령어들
주의: 본 글의 그림에서는 한 저장소의 브랜치마다 아예 공간이 별도로 존재하여 동일한 객체가 브랜치마다 중복하여 존재하는 것처럼 나타냈으나 실제는 동일한 객체는 중복하여 존재하지 않는다. 이는 첫 사용자들의 이해를 돕기 위한 것일 뿐이다. 엄밀히 따지면 그림의 Stage 공간도 브랜치마다 따로 존재하지 않을 것이다.
브랜치 전략의 한 가지
DevOps에서는 베이스 코드와 자주 통합하고 빌드해야 한다. 수일 내지 수주 동안 통합하지 않은 코드는 나중에 아주 골치 아프기 때문에. (단, 중소기업의 작은 규모의 개발팀에서는 이렇게 해도 별문제가 없기도 하다 ^^;; ) 좌우지간, 자주 통합하는 습관을 갖도록 하기 위하여 부모 브랜치(그림에서 master)의 변경사항을 자주 당겨와서 자신이 작업 중인 브랜치에 머지하고 빌드하도록 한다.
저장소 가져오기
원격 저장소에서 처음 소스코드를 가져오는 clone, 그리고 원격의 브랜치를 로컬에도 생성하기 위한 명령어를 설명하기 위한 그림이다.
