이번 시간에는 git이라는 것을 공부해 볼 것이다. IT쪽을 공부하다보면 한번쯤은 들어봤을 단어이다. 그만큼 많이 쓰이는 프로그램이지만 생각보다 다루기가 쉽지가 않다. 그렇기 때문에 한번 정리하면서 공부해보자.
Git이 누가 만들었는지, Git에 대한 별명은 무엇인가??
리눅스 운영체제는 누가 만들었는가? 리누스 토발즈라는 사람에 의해서 만들었졌다. 리눅스에서도 처음에는 Git으로 버전 관리를 하고 있지 않았다. 처음에는 SVN으로 관리했다. 하지만 SVN에서 여러가지 단점들을 보완하고자 Git을 만들었다고 한다.
Git을 다룬다는 것이 쉽지가 않다. 여러분만 어렵게 생각하는 것이 아니다. 심지어 리누스 토발즈가 git에 대해서 “The information manager from hell”라고 적을 정도이니 자책하지 말자.
Git을 사용하는 이유는 무엇인가?
이유는 단순하다. 버전 관리를 하기 위해서이다. 그렇다면 버전은 왜 관리를 해야 할까? 여러가지가 있지만 간단하게 소개 하자면,
1. Git으로 버전 관리를 사용하는 이유로는 실행 취소, 재사용과 같은 이유가 있다.
2. 버전 간의 소스코드를 비교하기가 너무 쉬워진다. 버전1, 버전2, 버전3 이런 버전을 비교하는게 매우 쉬워진다.
3. 그렇기 때문에 협업이 쉬워진다.
* 참고로 회사에서도 지원자가 최소한 알고 왔으면 하는 것으로 버전 관리가 뽑힌다고 한다. 그러니 미리 익숙해지자.
먼저 소스코드를 사용해서 커밋 이력을 탐색해보는 시간을 가져보자.
예시로 디자이너와 협력중에 이상이 생겨서 연락이 왔다. 수정하다가 코드를 잘못 건들여서 오류가 났는데 이를 해결하는 방법이 있을까?
이럴 때는 diff 라는 명령어를 사용하면 된다.
diff (파일 이름) (파일 이름)
* 이를 사용하지 않는 경우는 Webdifftool에 들어가서 코드를 넣으면 비교해준다. 하지만 지금은 git을 공부하는 만큼 diff를 사용하려고 노력하자.
우리가 평소에 버전을 관리할 때는 어떤식으로 관리했을까?
보통은 파일 이름을 수정하는 방식으로 사용했을 것이다. (파일이름.txt -> 파일이름(최종).txt)
하지만 git을 사용할 경우 파일 변경 이력을 쉽게 확인할 수 있다. 이런 것들의 장점으로는
1. 개발의 진전 상태를 확인할 수 있다
2. 버그가 발생하면 빠르게 수정 가능하다
3. 누가 언제 변경했는지 쉽게 파악이 가능하다.
소스 코드 버전은 언제 갱신을 해야할 까?
소스코드가 몇 줄일 때 갱신하는 경우도 있고
commit이란 무엇인가?
commit이라는 단어를 사전을 통해서 찾아보자. 그러면 저지르다, 범하다, 약속하다 등이 있다. 뜻을 보면 대충 어떤 뜻인지 알 수 있다. 정리해서 말하자면 내가 의도를 가지고 특정한 컨텐츠의 버전을 갱신하는 행위를 commit이라고 한다.
* it쪽은 서양에서 기능이 만들어지고 하는 거라 새로운 용어가 나왔을 때 사전을 찾아서 확인하면 빠르게 학습가능하다.
얼마나 자주 commit을 하는 것이 적절할 까?
Git의 특성상, 내가 원할 때 아무때나 commit을 만들 수 있게 해서 자유도가 높다. 그렇다면 버전관리가 잘되기 위해서는 얼마나 commit을 만들고 언제 commit을 만들어야 할까?
정답은 아니지만 해외 레퍼런스를 통해서 가져오면 일단 commit의 크기는 작을수록 좋다. 작게 만드는 것이 좋다. commit에서 어떤 이유 때문에 변경했는지 빠르게 확인할 수 있다. 1주일 동안 commit을 하지 않다가 하는 것과 매일 commit하는 경우를 생각해보자. 당연히 1주일이 수정사항이 어마어마하다. 그렇기 때문에 작은 규모로 commit을 하는 것이 좋다고 한다.
추가적으로 논리적인 변경(Logical change)이 있을 때 하는 것이 좋다. 여기에서 Logical change가 무엇인가??
논리적 변경은 프로젝트 상황, 나의 판단에 따라서 상시 다르다. 그렇기 때문에 이는 구글링을 해서 다양한 사례들을 보는 것이 좋을 것 같다.
내가 commit을 언제 할지 직접 결정할 때 장단점이 있을까? 자동 저장은 어떤 장단점이 있을까?
직접 저장할 때는 개발에 온전한 집중이 되지 않는다. 하지만 이와 같은 경우 훈련을 잘하면 일정 관리가 수월해지기 때문에 좋다.
하지만 자동 저장과 같은 경우 코드를 쓰는 중간에 자동 저장이 되는 경우가 있기 때문에 신택스 에러, 빌드 fail을 하게 되는 경우가 많다. 그래서 보통 자동 저장을 사용하지 않는다.
Repository란 무엇인가?
영어 사전을 살펴본 결과, 어떤 것을 대량으로 저장하는 저장소, 지식, 정보라는 뜻을 가지고 있다.
Repository는 프로젝트 하나에 하나만 존재할까? 그런 것은 아니다. 프로젝트의 규모에 따라서 다르다. 보통은 토이 프로젝트와 같이 작은 경우는 하나의 Repository를 사용한다. 이런 경우를 '모노 레포'라고 말한다. 요즘은 '모노 레포'로 프로젝트를 구성하는 것이 약간의 유행이라고 한다.
* 회사에 가면 한 개의 레포만 관리할 확률은 낮다. 서버 개발자 분들은 한 개만 관리할 수 있지만 클라이언트 개발자분들은 여러 개를 다룰 확률이 높다.
Repository clone 받기
clone은 복제라는 뜻을 가지고 있다. 말 그대로 Repository를 복사하는 것이다.
지금부터 Repository clone 받기 예제를 진행해보자.
위치하고 싶은 디렉토리를 만들어서 해당 디렉토리에 복사해보자.
git clone 주소
git clone https://github.com/udacity/asteroids.git
위와 같이 코드를 입력하면 해당 디렉토리에 Repository가 복제된다.
그렇다면 해당 Repository로 무엇을 할까? 나는 2가지를 확인하겠다.
1. 로그를 확인한다.
Log의 사전 뜻을 살펴보면 기록이라는 뜻이 있다.
git log
해당 명령어를 치면 다음과 같은 화면이 나온다.
commit : 노란색으로 commit이라고 되어 있는 부분은 commit했을 때의 ID라고 한다. commit을 하는 순간 commit에 대한 ID가 만들어진다.
Author : 해당 commit을 한 저자가 쓰여져 있다. 보통 이메일 주소가 써있다.
Date : commit을 한 날짜가 적혀있다.
그리고 밑에는 commit에 대한 코멘트가 적혀있다.
하지만 이와 같은 경우 커맨드 라인으로 구성되어있어서 보기가 힘들다. 이럴때는 해당 명령어를 쳐보자.
해당 Repository가 있는 폴더에 들어가서
gitk
이와 같이 GUI로 되어있어서 훨씬 직관적이다. 해당 GUI도 익숙해지도록 노력하자.
커밋 내역을 확인할 수 있는 도구 |
1. 내장 GUI 도구 - gitk |
2. sourcetree |
3. GitKraken - 유료이지만 이쁘다. 학생들은 무료로 사용 가능하다. |
4. Intellij IDEA |
5. visual studio code - git plugin |
위와 같이 여러가지 툴이 존재하니 본인이 어떤 작업환경인지에 따라서 골라서 쓰면 좋을 것 같다.
2. commit 간 변경 분 보기
누가 commit을 변경했는지 확인하는 것이다.
커밋 간의 변경이 어떤 것이 있는지 보려면 아래와 같은 명령어를 치면 된다.
git diff (로그 이름) (로그 이름)
* 명령어 옆에 옵션이 어떤 것은 -가 붙고 --가 붙은 것들이 있다. 무슨 차이점일까?
해당 사이트에서 확인해보자. www.44bits.io/ko/post/linux-and-mac-command-line-survival-guide-for-beginner
Checkout이란 무엇인가?
만약에 여러 작업 이후 버그를 유발한 commit이 있다고 가정하자. 어떻게 찾을 수 있을까?
가장 정확한 방법은 최신 commit부터 역순으로 하나씩 내려가면서 찾는 방법이 있다. git log 명령어를 치면 상단에 있는 것이 최신 commit이다.
checkout (커밋 아이디)
위와 같이 명령어를 치면 해당 commit을 만든 시점으로 돌아갈 수 있다. 이렇게 역순으로 하나씩 실행하다보면 버그가 사라지는 시점을 찾을 수 있다.
checkout한 commit에서 빠져 나오는 명령어는 아래와 같다.
git checkout master
정리하자면,
checkout으로 버그가 난 시점 찾아보기. |
1. checkout을 하면서 버그가 나는 시점을 찾는다. |
2. 시점을 찾으면 해당 commit에 아이디를 찾는다. |
3. 해당 commit 아이디와 오류가 나지 않는 commit아이디를 찾아서 diff 명령어를 사용하면 어떤코드 때문에 버그가 만들어졌는지 확인할 수 있다. |
이와 같이 git에 대해서 여러가지를 배워봤다. 진짜 배우면 배울수록 생각보다 복잡하지만 익숙해지면 또 별거 아닐 것으로 생각한다. 자주 사용하면서 익숙해지려고 노력하자!