Git&Github 개념 정리
SCM & VCS
- Source Code Management(SCM): 코드 관리 도구
- Version Control System(VCS): 버전 관리 시스템
즉 버전 관리를 한다는것은 코드의 특정 시점을 사진 찍듯이 스냅샷을 찍어 이 정보를 관리하는것
Git 의 역할 (4가지 측면)
1. 코드 관리 도구
git 은 코드를
폴더 단위로 관리하며 특정 시점의 폴더 상태를 커밋으로 저장하여 로그로 기록한다.
처음엔 저 말이 잘 이해가 가지 않았는데 효율 , 스냅샷 2가지 키워드를 통해 이해하게 되었다.
파일 하나만으로 간단하게 예를 생각해보자.
'homework.txt'
위의 파일을 만들고 수정에 수정을 거듭하며 최종 파일을 만드려한다. 파일 내용이 조금씩 수정될 때 단순히 덮어쓸 수도 있겠지만 수정한 내용이 틀렸거나 갑자기 다시 이전에 작성했던 내용 일부가 필요하거나 등의 이유로 보통 비슷한 이름의 새 파일을 만들것이다.
ex ) 'homework_fix.txt'
이런식으로 10번의 수정을 했다고 생각하자. 그럼 자연스레 내 폴더에는 내용도, 제목도 비스무리 한 파일들이 10개가 생기게된다. 이런 방식이 보통의 경우 크게 문제가 되지는 않지만 저렇게 10번의 수정을 거치게 되는 파일이 수백 , 수천 급으로 늘어난 경우를 생각해보자.
그럼 모든 파일들이 뒤죽박죽의 파일명으로 섞이고 용량도 10배 이상의 뻥튀기 결과를 피하기 힘들것이다.
깃은 저런 상황에서 파일을 다음과 같이 관리한다.
homework.txt 라는 파일의 내용 일부가 수정이 되었을 때, 그 수정된 부분만 따로 저장하며 어떤 부분에 대한 수정이였는지 사용자가 직접 작성한 메세지 와 함께 로그 파일로 저장한다. 결과적으로homework.txt 라는 파일은 1개만 존재한 상태로 변경사항 정보를 저장한 +α 만 추가적으로 생기는 것이다.
수정이 많아질수록 이러한 저장 방식은 메모리 측면에 있어 엄청난 효율 을 보여줄 수 있는 것이다.
또다른 키워드인 '스냅샷' 에 대한 설명은 다음과 같이 이해할 수 있다.
위와 비슷하게 10개의 파일들 1.txt~10.txt 이 있고 이들 모두가 10번씩 수정되어 여러 파생된 이름으로 각 파일이 10개의 버전을 가지게 된 상태를 생각해보자.
ex) 1_fix.txt , 1_final.txt , 1_part.txt , 1_final_final.txt
이 작업을 오로지 혼자 한 작업이였다면 각 버전들의 이름을 본인이 알아보기 수월하게 깔끔히 정리했을지 모르겠지만 대게의 경우 혼자 수정한 경우라 하더라도 각각의 파일들이 어느 부분이 변경된 파일들인지 , 어느 시점에 저장했고 그 저장 시점에 다른 파일들은 어떤 상태였는지에 대한 정보를 본인 기억력 말고는 알 수 있는 방법이 없다. 게다가 이를 여러명이 작업했다고 생각하면 훨씬 끔찍해진다.
1
2
3
4
me : OOO님 그 목요일에 수정 부탁드린거 올려주셨나요?
OOO : 네 방금 업로드 했어요!
me : 어... 그 파일이 여러개인데 혹시 어떤거인가요?
OOO : 어? 어.. final_real.py 였나? 아 아니다 real_real_final.py 였다
git 은 위에서 설명한 파일의 변경사항을 저장할 때 old 버전과 new 버전의 차이 정보를 동시에 저장하여 관리하고 이때 메세지도 함께 저장한다. 사용자는 특정 시점에 작업했던 파일의 내용을 원하면 그때 작성했던 메세지를 찾아가면 어느부분이 어떻게 수정되었는지 확인할 수 있고 그 상태로 되돌리는것도 가능하다.
ex)
- : 이전의 내용 , + : 저장된 수정 내용
2. 코드 저장 도구
1. 에서 확인하였던 관리 도구 로서 git의 역할 덕에 git은 코드를 저장함에 있어도 유용하다.
코드들이 git으로 관리된 상태가 아니라면 물리적으로 작업 환경이 바뀌면 (다른 PC , 노트북으로 작업을 해야하는경우) , 이전에 하던 작업을 이어서 하기 위한 방법은 N 드라이브 , Google 드라이브 와 같은 클라우드 서비스에 코드들을 업로드 / 다운로드를 하며 작업하는 것이다.
그렇게 되면 위에서도 언급했든 메모리 측면에서 비효율적이며 코드들의 변경 기록들을 알기 힘들다.
하지만 git 으로 관리되는 코드들은 변경사항 정보를 가지고 있는 커밋 들만 받으면 되기 때문에 상대적으로 가볍고 세부 변경 사항들을 지속적으로 확인하며 작업할 수 있다.
이러한 git 파일들을 github 이라는 저장 서비스에서 로컬 저장소와 같이 쉽게 업로드 / 다운로드 할 수 있다. 이를 로컬 저장소와 구분하기 위해 원격 저장소 라는 이름으로 부르는데 로컬 저장소 쪽에서 원격 저장소 쪽으로 업로드하는 작업을 push , 반대로 다운로드 하는 작업을 pull 이라고 한다.
3. 코드 협업 도구
1. , 2. 에서 확인한 장점 만으로도 git 은 충분히 코딩 환경에서 크게 이점으로 다가온다. 하지만 git의 가장 큰 장점은 이런 코드 관리와 저장의 작업을 여럿이, 남들과 함께하기에 정말 좋다는 것이다. 협업을 통한 개발을 크게 3가지 모델로 구분할 수 있는데
1. Push & Pull
하나의 테스크가 끝나기 전에 다른 테스크를 이어날 수 없는 ‘동기 작업’ 의 경우 주로 활용하는 모델로 하나의 분기를 통해 푸쉬와 풀 작업이 차례대로 번걸아가며 수행된다. ex) 끝말잇기
- 규모가 작거나 작업이 여러분류로 나뉘지 않는 경우 , 혹은 하나의 분기로 여러명이 작업하는 경우가 있다면 활용하는 모델이다. 많이 쓰이진 않는다.
2. Branch & Pull Request
가장 표준적인 협업 모델로, 항상 배포에 문제없는 master 분기 하위로 많은 분기를 통해 개발과 테스트를 거치고 pull request를 통해 상위 분기와 병합하여 작업을 진행하는 모델이다.
- 가장 많이 쓰이고 있는 모델로 아래의 그림은 우아한형제들 기술 블로그에서 가져온 이런 Branch & Pull Request 모델 활용 git - flow 그림이다.
3. Fork & Pull Request
오픈소스를 활용한 개발 및 운영을 할 때 활용하는 모델로
2번 모델과 비슷하지만 별도 권한이나 분기를 할당받지 않고Fork하여 본인의 저장소에서 자유롭게 개발을 진행한 뒤project owner에게 pull request 하는 방식으로 작업을 진행한다.
- 다양한 오픈소스를 활용해 권한 없이도 바로 본인의 저장소에서 개발을 진행할 수 있다는 장점이 있다.