Git자체가 파고 들면 어렵고, 개발 공부하기도 바쁜데 비전공자인 저희가 이해하기에는 시간이 걸릴 수 있습니다. 그래서 이번 프로젝트 협업에 필요한 내용만 추려서 적겠습니다. 이클립스 자체에서도 Git을 위한 도구가 있지만, 정리하는 내용은 모두 Github Desktop을 기준으로 정리하였습니다. 추가로 학습하고 싶으신 부분이 있거나 공유하고 싶으신 정보가 있다면 말씀해주세요. 정리해서 추가하도록 하겠습니다.
가장 먼저 저장소에 대한 개념이 필요합니다.
- Local repository(로컬 저장소):
- 본인이 사용하는 PC의 Git 저장소라고 생각하시면 됩니다.
- Remote repository(원격 저장소):
- Git 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소입니다. 저희는 편의상 Github라고 부르도록 하겠습니다.
- 이외에도 Git 저장소 서버의 종류는 Github, Gitlab, bitbuket등이 있습니다.(몰라도 됩니다.)
저장소를 만들기 전에 이클립스에서 Git Repository 뷰를 추가해주겠습니다. 이곳에서 이클립스에서 사용할 Git repository를 관리할 수 있습니다. 여기서도 commit 등등 git의 기능을 사용할 수 있으나, 저희는 Github Desktop으로 관리 할 것이기 때문에 생성된 프로젝트를 Git 저장소로 만들어주는 기능을 제외하고는 모두 Github Desktop에서 하도록 하겠습니다.
그럼 저장소를 만들어 보겠습니다. Github에 이미 생성한 저장소를 가져오는 방법과 이클립스에서 생성한 프로젝트를 Git저장소로 만들어서 Github에 업로드 하는 방식 두가지만 설명하겠습니다.
Git 저장소가 제대로 만들어 졌다면, 이제부터는 Git을 통해서 프로젝트의 코드를 관리할 수 있습니다. 이클립스 화면에서 다음처럼 프로젝트 옆에 저장소 명과 브랜치 명이 표시 된다면 해당 프로젝트는 Git 저장소로 관리되고 있다는 뜻입니다. '[Gigabox(저장소 명) develop(브랜치 명)]'입니다.
Git 저장소가 생성된 이후부터 Git 저장소 내의 파일들에 변화가 생기면(코드를 추가하거나 삭제하면) Git이 파일의 변화를 추적합니다. Github Desktop의 Changes에서 Git이 추적한 저장소 내의 변화를 확인 할 수 있습니다.
Git에서 지원하는 명령어는 많지만, 프로젝트 진행하면서 필요한 기본적인 명령어만 정리하겠습니다.
Git 공식 Document에서는 Branch에 대해서 다음과 같이 설명하고 있습니다.
모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다.
Git 공식문서 3.1 브랜치란 무엇인가?
이해를 돕기위해 동일 Branch에서 작업한다고 가정해보겠습니다. 팀원1과 팀원2가 프로젝트 클론 후에 각자의 로컬저장소에서 Master를 사용하고 있습니다.
작업을 하다 보면 각자 commit이 쌓이게 됩니다. 이를 원격 저장소에 저장하고자 push를 합니다. Branch가 하나이기 때문에 각자의 commit이 하나의 Branch에서 뒤섞이게 됩니다.
변경이력이 뒤섞이는 경우 곤란한 문제가 발생 할 수 있습니다. 가장먼저 같은 파일을 수정했다면 충돌이 발생할 수 있습니다. 본인이 아닌 다른 팀원의 코드와 충돌이 발생한 경우 맘대로 수정하면 안될 뿐더러 시간이 많이 걸릴 수 있습니다. 롤백 등의 문제도 발생합니다. 방금한 commit을 취소 하고 싶은데 그 뒤에 다른 팀원이 push를하여 commit이 잔뜩 올라와있다면 멋대로 취소할 수도 없습니다.
이번에는 각자 Branch를 만들어서 격리된 공간에서 commit을 하고, 이를 각자의 Branch에 push합니다.
이렇게 하면 각자의 Branch에서 롤백을 하거나 롤백했던 내용을 되돌리거나 하더라도 다른 Branch의 commit에 영향을 주지 않습니다. 또한 충돌이 발생하더라도 본인이 작성한 코드이기 때문에 본인의 코드만 수정하면 됩니다. 물론 나중에 master Branch로 병합할때 충돌이 발생할 수 있는 것은 사실이나, 각자의 작업에 영향을 주지 않는 것만으로 큰 이득이 있습니다.
Git 저장소를 처음 만들면 master branch가 기본적으로 생성되어 있습니다. 이 master 브랜치는 저희가 개발하면서 각자 개발한 내용을 통합할때 사용할 branch라고 생각하시면 됩니다.
프로젝트 진행에 대해서는 아래에서 이야기하고, Branch를 생성해 보도록 하겠습니다.
현재 'test_test'의 프로젝트는 'master' Branch에서 작업하고 있습니다. 'master' Branch에서 바로 작업하는 것은 협업할때는 매우 위험할 수 있습니다. Git을 사용할 때 항상 현재 Branch가 어디인지 확인하고 작업하는 습관을 들이는 것이 좋습니다. 앞서 생성한 'develop_ty' Branch에서 작업하기 위해 로컬 저장소의 Branch를 변경해주도록 하겠습니다.
'Github Desktop'에서 현재 Branch를 클릭하면 나오는 Branch 목록에서 이동하고자 하는 Branch를 선택할 수 있습니다.
브랜치를 변경할때, 변경이력이 남아있는 경우에 다음과 같은 알림창이 나올 수 있습니다. 'master' Branch에서 작업한 내역을 가지고 이동하기 위해 'Bring my changes to develop_ty'를 선택하고 Branch를 변경해 줍니다.
우선 프로젝트를 생성하고 기본 설정후에 Github에 원격저장소를 만들겠습니다. 사고를 방지하기 위해서, master branch의 merge
만들어진 저장소를 본인의 PC로 Clone해주시고, 각자 'develop_[본인의 이니셜](ex. develop_ty)'로 본인이 작업할 Branch를 생성합니다.
현재 저장소의 변경이력이 생기고 나면 . 'Github Desktop'에서 changes 탭의 하단에 commit message를 적는 입력창이 있습니다. commit message를 입력하면 commit버튼이 활성화 됩니다. commit message의 내용은 본인의 변경이력에 대한 설명이 들어갑니다.
로컬 저장소(내 PC)에 commit이 생기면 'Github Desktop'에서 push origin버튼이 활성화 됩니다. 클릭하면 commit된 변경이력들을 원격 저장소의 Branch로 보냅니다.
그날 작업이 마무리 되면 Pull Request를 해주세요.
'Master' Branch에서 코드 병합이 끝난 후에는 자신의 개발 Branch에 병합된 프로젝트를 가지고 와야합니다. 그런데 'Master' Branch의 병합이 끝나고 나서, 로컬에서 별도의 변경이력이 있다면, pull할때 충돌이 발행할 수도 있습니다. 되도록이면 'Master' Branch에서 병합이 끝났다는 메시지를 받으면 추가로 변경이력이 생기기 전에 pull을 하고 작업을 진행하시는 것을 권장합니다.
여기까지가 저희 팀이 프로젝트를 진행하는데 필요한 최소한의 Github Desktop 사용법입니다. 생략한 내용도 매우 많고 저도 이제 막 공부한 내용이라서 틀린 부분도 있을 수 있습니다. 혹시라도 공부하시다가 수정이 필요한 부분이 있다고 생각되시면 단톡방에 올려주시면 수정하겠습니다.