Git과 Github

정은경·2019년 12월 15일
0

Git & Github에 관한 WeCode 은우님 세션 내용 필기

Git은 VCS (Version Control System)
version은 소스코드(sourcecode) 파일의 version을 뜻함
즉 소스코드(soruce code)의 변경사항 내역을 관리하는 시스템
참고로 소스코드란 코드 파일들을 말함

정리하자면 VCS의 기능은 다음과 같습니다:
• 코드 변경 사항 내역 기록 및 관리
• 필요시 이전 상태로 rollback
• 팀단위 개발시 체계적이고 효과적인 협업

Git
그렇다면 VCS를 구현할려면 어떻게 해야 할까요? 아마 가장 간단한 방법은 파일 이름을 사용하는 것일 겁니다. 아마 여러분들도 많이 사용하셨던 방법일겁니다. 파일 이름에 날짜나 버젼을 붙이는 거죠.

예를 들어, server.js 라는 파일이 있다면, server.v1.js, server.v2.js 등등을 만들어서 관리 하는 겁니다. 이렇게 하면 아주 간단한 버젼 관리를 할 수 있겠죠. 하지만 이러한 식의 버전 관리는 많은 제한이 있습니다. 먼저 버젼 수가 늘어날 수록 파일 수가 너무 많아 질것입니다. 하나의 파일에 만일 버젼이 100개가 있다면 100개의 파일을 보관및 관리 해야 합니다. 설상가상으로 날짜까지 붙이면 더 복잡해질것입니다. 어제 수정했던 사항들이 무엇인지 보려면 날짜가 중요하겠죠. 그럼으로 버전에 날짜까지 붙이면 디렉토리에 복잡한 이름의 코드들이 넘처날것입니다. 이러면 내역을 한눈에 보기도 힘들 뿐만이 아니라 개발 자체가 어려워 질것입니다. 게다가 실수로 최신 버전이 아닌 이전 버전의 파일을 최신 버전으로 착각해서 수정 하는 실수도 있을 수 있습니다.

이러한 문제를 해결하기 위해서는 어떻게 해야 할까요? 다음 글을 읽기전에 잠시 한번 생각해보세요. 여러분이라면 어떻게 해결 하셨을까요? 🤨🧐

이러한 문제를 해결 하기 위해서는 수정된 버전 파일들 전체를 디렉토리에 저장해 놓는게 아니라 다른 공간에 저장하는 것입니다. 수정 사항들과 함께 수정된 날짜 등등의 meta 정보를 같이 다른 공간에 저장하면 됩니다. 그러면 파일은 최신 파일만 저장하고, 수정 사항들은 수정 사항 정보들과 meta 정보들을 저장한 공간을 통해 에 저장, 검색, 열람하면 됩니다. 이렇게 변경정보들을 따로 저장한 공간을 version databas라고 불르겠습니다.

이제 모든 문제가 해결 된거겠지요? 아닙니다 아직 한가지 문제가 더 있습니다. 바로 다른 개발자와 협업이 안된다는 점입니다. 다른 개발자들과 수정사항 정보들을 공유하고 함께 관리해야 하는데 앞서 본 버전 관리 시스템으로는 그것이 불가능 합니다. 그러면 어떻게 해야 할까요? 🧐🧐🧐🧐🧐

네, 답은 아주 간단합니다. Version database를 서버에 올려놓고 공유하면 됩니다. 이러한 서버를 "Central VCS server" 라고 합니다. 즉 중앙 버전 관리 시스템 서버 인거죠. 수정사항 내역들과 meta 정보들은 전부 중앙 서버에서 관리하고 개발자는 각자 컴퓨터에 최신 버전의 코드들만 중앙 서버에서 다운로드 받아서 작업하는 방식 입니다.

자 이제 모든게 해결됬겠죠? 행복하게 코드를 구현하면 되겠죠? 아직 한가지 문제가 더 있습니다. 위의 central VCS server 방식의 문제점은 해당 중앙 서버가 다운이 되면 개발팀 전체가 개발 진행이 안된다는 점입니다. 심지어 만일 central VCS server가 삭제되거나 복구가 안될정도로 손상을 입으면 소스코드 전체가 날라가 버리는 대참사가 일어날 확률도 있습니다. 그래서 나온 해결책이 "Distributed Version Control System", 즉 분산 버전 관리 시스템 입니다. 중앙 서버 뿐만이 아니라 각 개발자의 컴퓨터에도 최신 버전의 코드 뿐만이 아니라 수정 사항 내역들과 meta 정보들을 전부 다 가지고 있는 방식입니다. 그럼으로 혹시나 중앙 서버에 문제가 있어도 언제든지 개발자의 컴퓨터를 통해 복구가 가능한 구조입니다.

자 이제 아주 멋진 VCS 시스템을 디자인 했으니 직접 사용해 볼까요? 먼저 중앙 서버가 필요하니 서버를 구축하고 거기에 version database 시스템을 구축하고 또한 개발자의 컴퓨터에서 접속 해야 하니 보안 시스템도 구축하고 또 각 개발자의 컴퓨터에서 버전 컨트롤을 할 수 있게 해주는 클라이언트 프로그램 개발하고 또.....

실제 개발보다 일이 더 커져버렸네요. 그럼으로 그냥 git 과 github를 사용하면 됩니다 😂😃

아, 참고로 git도 Linus Torvalds 가 만들었습니다. 네, linux를 만들 사람이 git도 만들었어요 😮

Git Basics
Git을 사용해서 파일 버전 관리를 할때 파일은 다음 3개의 상태중 하나의 상태에 있게 됩니다.
• Committed
○ 수정 사항들이 git에 저장이 된 상태를 "committed" 이라고 합니다. 이러한 행위를 "commit" 한다고 합니다.
• Modified
○ Modified file은 이름 그대로 수정된 file 입니다. 하지만 아직 "commited" 되지 않은 상태의 file을 이야기 합니다.
• Staged
○ Staged file은 modified file에서 한단계 더 나아가서 곧 commit 될거라고 mark 해놓은 상태입니다. 즉 modified 와 committed의 중간 상태라고 생각하시면 됩니다.
○ 이렇게 중간 상태가 존재 하는 이유는, commit 하기전에 중간 상태를 저장할 수 있도록 하기 위함입니다. Commit을 하면 commit history에 남기도 하고, 혹시 추가 수정 사항이 있거나 다시 되돌려야 할때 까다롭기 때문에 (commit 후에도 다시 되돌리는게 가능은 합니다) commit 전에 중간 상태에 저장할 수 있도록 하는 것입니다. 즉, commit은 해당 개발이 완전 완료 됬을때 하는 것이기 때문에, 아직 완료는 안되었지만 그래도 중간 상태를 저장할 필요가 있을때 staging을 사용하는 것입니다.

Git을 사용한 버전 관리의 flow는 다음과 같습니다.
1. 소스코드 전체를 다운로드 받습니다 (전문적인 언어로, "git repository를 checkout 한다" 고 합니다).
2. 소스코드 파일들을 수정 합니다. 즉 개발을 한다는 말입니다.
3. 수정한 파일들을 stage 합니다.
4. 그리고 계속 해서 소스코드 파일들을 수정해 나갑니다.
5. 해당 작업이 완료될때까지, 즉 commit 할 준비가 될때까지, 3,4번을 반복합니다.
6. 완료되면 commit 합니다.

Basic Git Commands
git init
프로젝트를 git repository로 만들기 위해서 사용하는 명령어 입니다. 여기서 프로젝트(project)라 함은 개밸하고자 하는 소스코드들이 있는 디렉토리를 말합니다. git init을 해서 git repo로 만들어야 git으로 버전 관리가 시작됩니다.

git add
수정 사항들, 즉 modified 파일들을 staged 상태로 옴기고자 할때 사용하는 명령어 입니다. 또한, git repo에 새로이 추가된 파일들을 staged 상태로 옴길때도 사용됩니다. 새로이 추가된 파일들은 "untracked" 파일 이라고 하는데, git에서는 이들도 수정 사항이라고 보는 것입니다.

git commit
staged 된 파일들을 commit 하고자 할때 사용하는 명령어 입니다.

git diff
어떤 수정 사항들이 적용됬는지 보고자 할때 사용하는 명령어 입니다. 참고로 staged 된 수정 사항들은 git diff로 볼 수 없습니다. Modified 된 파일들만 git diff로 볼 수 있습니다.

git status
현재 상태를 보여주는 명령어 입니다. 어떠한 파일들이 modified가 되었고 어떠한 파일들이 staged가 되었는지 등의 전체적인 상황을 보여줍니다.

git log
Commit 내역들을 보여줍니다. Commit history라고도 합니다. git log를 통해 이제까지 커밋 내역들을 전부 볼 수 있습니다. 다만 출력되는 포맷이 보기가 쉽지가 않아서 tig 같은 tool을 사용하면 훨씬 편리합니다.

git rm
원하는 파일을 git repo에서 삭제합니다.

git mv
원하는 파일을 git repo 상에서 이동 시킬때 사용합니다. 주로 rename 할때 사용 됩니다.

git branch
Branch를 생성할 때 사용됩니다. Branch에 관해서는 다음에 자세히 이야기 할 것입니다.

git checkout
어떤 branch를 checkout 할때 사용되는 명령어입니다. 이와 관련해서 다음에 더 자세히 이야기 할 것입니다.

Branch & Merging
Git 에서 branch는 굉장히 중요한 컨셉이며 꼭 이해하는 컨셉입니다. 왜냐하면 git을 사용할때는 branch 기반으로 개발하기 때문입니다. Git branch를 이해할려면 먼저 git이 어떻게 데이터 (수정사항들)을 저장하는지를 알아야 합니다.

Git은 데이터를 딘슨힌 변경사항(diff)으로 저장하지 않습니다.. Git은 파일으 스냅샷의 연속으로 저정합니다. Git은 새로 commit이 들어오거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여깁니다. 그래서 파일이 달라지지 않았으면 git은 빠른 성능을 위해서 파일을 새로 저장하지 않고 이전 상태의 파일에 대한 링크만 저장합니다. 즉, 수정 사항만을 저장하는게 아니라 파일의 스냅샷(snapshot)을 시간순으로 저장하는 것입니다.

그리고 변경사항을 볼때는 현재 스냅샷과 이전 스냅샷을 비교하여 변경사항을 볼 수 있는것입니다.

이렇게 스냅샷으로 저장되어 있기 때문에, 개발자가 central server에서 새로 repo를 checkout 받으면 해당 리포의 어느 특정한 시점의 (일반적으로 가장 최신) 스냅샷을 checkout 받는것입니다.

그러면 여기서 질문이 생길것입니다. 개발자들이 각자 snapshot을 checkout 받아서 개발을 하면 어떻게 서로의 변경사항들을 조율을 할수 있을까요? 즉 서로의 변경사항들을 합쳐서 새로운 최신 버전의 스냅샷을 만드는 과정이 필요한데, 문제는 어떤 스냅샷을 기준으로 변경사항들을 합치느냐 하는 문제가 생깁니다.

그래서 이러한 문제를 해결하기 위해 branch를 사용합니다. Branch는 나뭇가지 혹은 분점 을 뜻합니다. 즉 기본이 되는 큰 줄기가 있고 그 줄기로 부터 옆으로 가지가 나는걸 뜻하죠. Git의 branch 모델이 바로 이러한 구조입니다. 기준이 되는 스냅샷이 있습니다. 이 기준을 master branch라고 합니다. 그리고 각 개발자는 master branch를 checkout 먼저 하고, master branch로 부터 자신만의 branch를 만듭니다. 이걸 feature branch라고 합니다. 그리고 feature branch를 기반으로 개발을 한 후 개발이 완료가 되고 commit을 하면 자신의 feature branch를 다시 master branch로 합하게 됩니다. 이렇게 합하는 과정을 merge 한다고 합니다.

정리를 하자면:
1. Matser branch를 check out 한다.
2. 자신만의 feature branch를 만든다.
3. Feature branch에서 개발을 한다.
4. 완료되면 commit 한다.
5. Master branch에 feature branch를 merge 한다.

.gitignore File
Git repo에 있는 모든 파일을 전부 commit 해야 하는건 아닙니다. 파일들중 commit 하지 말아야 하는 파일들도 있습니다. 예를 들어, vim을 사용해서 개발을 하면 vim이 백업 파일을 자동을 만듭니다. 이러한 파일은 끝이 .un~ 로 끝납니다. Dot file 이기 때문에 ls에 나오지는 않지만 git status 에는 나오고 git add 에도 걸립니다. 그럼으로 이러한 파일들은 git이 자동으로 skip하도록 설정 하는것이 좋습니다. 이러한 설정은 .gitignore 파일을 만들어서 관리합니다. 앞서 말한 vim의 백업 파일을 git이 무시하도록 할려면 .gitignore 파일에 다음과 같은 라인을 추가하면 됩니다.

Github
위에서 VCS(version control system) 에서는 개발자간의 협업을 위해 중앙 서버가 있다고 배웠습니다. Github는 바로 이러한 중앙서버의 역활을 하는 서비스 입니다. 개발자가 직접 git 중앙서버를 구현하여 운영할 수 도 있지만 그러자면 여러가지 비용과 구현하는 시간이 걸립니다. 그래서 대신에 가성비 좋고 튼튼한 github를 사용하는 것입니다.

Github는 단순 중앙서버 역할 이외에도 여러가지 기능을 제공합니다. Code review, documentation(문서) 생성및 관리 등 개발 프로젝트 운영에 필요한 여러 기능을 제공하기 때문에 요즘에는 github를 사용하지 않는 개발자가 거의 없을정도로 개발에 꼭 필요한 서비스가 되었습니다.

profile
#의식의흐름 #순간순간 #생각의스냅샷

0개의 댓글