버전관리
하나의 작업을 이어서 하거나, 다른 작업 환경에서 작업해야하는 상황이 발생하는 경우 지금까지 작성했던 코드들을 관리할 필요가 있다. 혹은 실수할 때를 대비하여 과거 버전으로 롤백해야하는 상황에 놓일 수도 있기 때문에, 버전관리는 선택 아닌 필수이다.
학습 목표
- 버전 관리의 필요성 이해
- Git의 이해
- Git 사용 실전
Git
파일 관리를 할 수 있는 도구로 Git이 존재한다. 기존 작성된 내용에서부터 생긴 변동사항을 추적하고, 변동 사항을 마치 버전처럼 관리할 수 있는 기능을 제공한다. 만약 진행사항에 문제가 생기는 경우 되돌리는 기능을 제공하고, 더 나아가 과거 특정 버전의 파일로 되돌아가는 기능까지 제공한다. 깃은 웹상의 연결 저장소에 저장이 되어 다른 기기에서 업데이트 된 최신 작업본을 내려 받을 수 있다.
이러한 특징으로 깃은 협업에도 유용하여 유니티 과정에서 유용하게 쓰일 것이고, 1인 개발에서도 개발 과정을 한 눈에 보여주기에 하나의 명함으로써 좋은 역할을 할 것이다.
GitHub
초기에는 콘솔 화면의 명령어를 통해 조작을 했지만, 입문 장벽이 높아 다른 프로그램을 사용하기도 한다. 따라서 프로그램 사용하여 먼저 Git에 친근해지도록 하자.
GitHub는 실시간 변동 사항을 추적하고, 이를 커밋 함으로써 작업 내역들을 누적해나갈 수 있다. 시간 또는 작업 단위 별로 진행하고 커밋하여 큰 작업을 세분화시킬 수 있다.
GitHub Desktop 어플의 History에 나의 작업 내역이 추적되며, Comment와 함께 커밋하여 저장한다. 이를 GitHub 웹 서버에 업로드 하면 다른 기기에서 다운로드하여 이어서 작업을 할 수 있다.
협업을 하는 경우 다른 사람이 업로드한 것을 다운받을 때는 pull을 눌러 해당 커밋을 받을 수 있다. 이 경우 커밋이 새로 추가되며, 다른 사람이 작업한 변동 사항과 코멘트를 내 기기에서 확인하는 것이 가능하다.
Git의 과정
컴퓨터에 있는 저장소는 로컬 저장소, 깃허브 홈페이지에서 확인 가능한 저장소를 원격 저장소라고 부른다.
working directory는 내가 작업하는 폴더를 말하며, 이곳에 저장된 파일의 변동 사항은 Git 어플이 모두 추적하여 보여준다.
변동 내용들은 Git Add를 통해 staging area에 모이는데, 원하는 버전에 반영하고자 하는 것들을 쌓는다고 생각하면 된다.
staging area에 모인 변동 사항들은 commit을 통해 하나의 버전으로써 만들어지고, 이러한 버전들은 local repository = History에 쌓인다.
로컬 저장소에 쌓인 버전들 중 원하는 버전들만 선택하여 원격 저장소에 업로드를 할 수 있다. 다른 컴퓨터로 해당 원격 저장소를 보면 버전에 따른 변동사항과 최신 코드를 볼 수 있는 것이다.
타인과 협업을 하게 될 경우 fetch 기능으로 원격 저장소의 변동사항을 확인할 수 있고 이를 pull 기능으로 가져와 나의 코드에 합치는 것이 가능하다. 이를 Merge라고 한다.
다만 내가 작성 중인 코드가 Pull로 인해 변동이 될수도 있는데 이를 Merge conflict라고 한다.
-
Add
비쥬얼 스튜디오에서 파일을 생성하여 동기화하고자 하는 repository에 저장할 경우 위와 같이 생성 파일을 추적하여 커밋할 수 있게 된다.
-
Commit
커밋은 History에서 파일 별로 내부 변동 내용을 추적하여 버전 처럼 확인이 가능하다.
참고. Checkout을 통해 해당 커밋으로 잠시 이동하여 그때의 상황을 볼 수 있다.
Push
상단의 push origin을 통해 GitHub 웹서버에 업로드를 할 수 있다. 이 경우 reset을 통해 취소할 수 없다. 이미 코드 작성을 마치고 공유까지 끝냈기 때문에 추가 수정은 가능해도 취소하는 것은 불가능하다. 수정을 하는 경우는 fix를 붙여 올린다.
협업, 개발시 주의사항
-
commit 할 때 시간 작성하지 말 것
커밋 과정시 제목을 봤을 때 변동 사항이 어떻게 되는지 대략적으로 알 수 있게 하는 것이 좋다. 시간은 어짜피 나와있는 내용이니 무엇을 했는지에 대해 간단히 언급하자.
-
커밋 메세지 작성법 숙지할 것
커밋의 제목과 내용을 커밋메세지라고 하며, 보통 회사는 회사지침이 있고, 팀장의 지시에 따라 통일된 방식으로 작성한다. 또는 외부 프로젝트의 경우 커밋 메세지에 대한 좋은 방법이 있으니 이를 숙지하도록 하자. 팀플은 통일성이 중요하다.
-
소스코드 백업은 상시로 할 것
관리자에게 백업은 가장 중요하다. 로컬 저장소에는 예기치 못한 상황들이 발생할 수 있으므로 백업을 버전 별로 잘 해두는 습관이 중요하다. 제발 반드시 습관을 들여보자.
clone
GitHub에 올라온 커밋을 로컬 저장소에 내려받기 위해서는 clone repository를 사용한다. 이때 로컬 저장소가 겹치면 안되기에, 경로 및 저장 폴더를 새롭게 지정한다.
나의 로컬 저장소에 저장된 경우 다음과 같이 불러올 수 있다.
repositoty URL 입력을 통해 다른 사람이 올린 Public 코드를 가져오는 것 또한 가능하다.
만약 해당 clone이 필요없게 된 경우 폴더를 삭제하거나 어플의 Remove 기능을 활용한다.
fetch / merge / pull
커밋 후 Push를 통해 원격 저장소에 업로드가 가능하다면, 마찬가지로 원격 저장소에서 pull 기능을 통해 가져온 repository의 변동 사항을 추적하여 신규 커밋을 업데이트하는 것을 fetch라고 하며 이를 나의 작업물과 합치는 것을 merge라고 한다.
merge conflict
위에서 소개한 일련의 Git 과정은 매우 이상적인 협업 시스템으로 보이나, 작업자 2명 이상이 동시에 push하는 과정에서 원격 저장소에 저장된 파일에 충돌이 발생할 수 있다. 이를 merge conflict라고 하며 나의 작업 영역과 협업자의 작업 영역이 겹쳐 발생하게 된다.
이때 충돌한 커밋을 pull하여 가져오면 파일 내부에 2개의 선택지가 모두 표현되어 이를 선택 할 수 있다. 다만 깃이 터지게 되면 모든 작업 내용이 날아갈 위험이 있기 때문에 애초에 충돌이 일어나지 않도록 유의해서 작업을 나누고, 신중하게 push를 해야할 것이다. 또한 작업을 할 때 fetch, pull부터 진행하고 시작하는 습관을 들이는 것이 좋다.
