[TIL] Git & Github에 대해서

git logo

1. Git 이란

◎ Git은 linux 개발한 Linus Torvalds가 만든 VCS(Version Control System)입니다. 여기서 version은 소스코드 파일의 version을 뜻한다.

즉 소스코드의 변경사항 내역을 관리하는 시스템입니다. 참고로 소스코드란 코드 파일들을 말한다.

VCS는 팀 단위로 개발을 할 때 더더욱 필요하다. 여러 명이 동시에 한 시스템을 개발할 때는 누가 어떠한 코드를 언제 수정했는지 등의 내역들을 확인할 수 있고 관리할 수 있는 것이 굉장히 중요하다. 또한 종종 동일한 파일에 여러 개발자가 코드를 수정하는 경우가 있으므로 각 수정 사항들을 체계적으로 관리할 수 있어야 한다.

 

정리하자면 VCS의 기능은 다음과 같다.

 

• 코드 변경 사항 내역 기록 및 관리

• 필요시 이전 상태로 rollback

• 팀 단위 개발시 체계적이고 효과적인 협업

2. Git 사용 이유

◎ 협업을 하다가 실수로 최신 버전이 아닌 이전 버전의 파일을 최신 버전으로 착각해서 수정하는 실수도 있을 수 있다.

이러한 문제를 해결하기 위해서는 수정된 버전 파일들 전체를 디렉터리에 저장해 놓는 게 아니라 다른 공간에 저장하는 것입니다.

수정사항들과 함께 수정된 날짜, 수정된 내용 등의 meta 정보를 같이 다른 공간에 저장하면 된다.

그러면 파일은 최신 파일만 저장하고, 수정 사항들은 수정사항 정보들과 meta 정보들을 저장한 공간을 통해 저장, 검색, 열람하면 된다.

이렇게 변경정보들을 따로 저장한 공간을 Version Datase라고 부르겠다.

 

하지만 여기서 아직 한 가지 문제가 더 있다. 바로 다른 개발자와 협업이 안된다는 점이다.

다른 개발자들과 수정사항 정보들을 공유하고 함께 관리해야 하는데 앞서 본 버전 관리 시스템으로는 불가능합니다.

그 해결방안은 Version database를 서버에 올려놓고 공유하면 됩니다.

이러한 서버를 "Central VCS server"라고 합니다. 즉 중앙 버전 관리 시스템 서버이다.

수정사항 내역들과 meta 정보들은 전부 중앙 서버에서 관리하고 개발자는 각자 컴퓨터에 최신 버전의 코드들만 중앙 서버에서 다운로드하여서 작업하는 방식입니다.

 

하지만 한 가지 문제가 더 있습니다. 위의 Central VCS Server 방식의 문제점은 해당 중앙 서버가 다운되면 개발팀 전체가 개발 진행이 안됩니다. 만약 Central VCS Server가 삭제되거나 복구가 안될 정도로 손상을 입으면 소스코드 전체가 날아가 버리는 대참사가 일어날 확률도 있다.

그래서 나온 해결책이 "Distributed Version Control System", 즉 분산 버전 관리 시스템이다.

중앙 서버뿐만이 아니라 각 개발자의 컴퓨터에도 최신 버전의 코드뿐만이 아니라 수정사항 내역들과 meta 정보들을 전부 다 가지고 있는 방식입니다. 중앙 서버에 문제가 있어도 언제든지 개발자의 컴퓨터를 통해 복구가 가능한 구조이다.

 

중앙 서버가 필요하니 서버를 구축하고 거게에 version database 시스템을 구축하고 또한 개발자의 컴퓨터에서 접속해야 하니 보안 시스템도 구축하고.... 실제 개발보다 일이 복잡해진다.

그래서 git과 github를 사용하면 됩니다.

3. Git의 기초

◎ Git을 사용해서 파일 버전 관리를 할 때 파일은 다음 3개의 상태중 하나의 상태에 있게 된다.

 

• Committed - 수정 사항들이 git에 저장된 상태를 "committed"라고 한다. 이러한 행위를 "commit" 한다고 한다.

• Modified - 이름 그대로 수정된 file을 말한다. 하지만 아직 "commit" 되지 않은 상태의 file을 이야기한다.

• Staged - modified에서 한 단계 더 나아가서 곧 commit 될 거라고 mark 해놓은 상태이다. 즉 modified와 committed의 중간 상태라고 생가하면 된다. 이렇게 중간 상태가 존재하는 이유는, commit 하기 전에 중간 상태를 저장할 수 있도록 하기 위함이다. 

4. Git의 흐름

◎ Git을 사용한 버전 관리의 flow는 다음과 같다.

 

• 소스코드 전체를 다운로드한다.(git repository를 checkout 한다.)

• 소스코드 파일들을 수정한다. 즉 개발을 한다는 말이다.

• 수정한 파일들을 stage 합니다.

• 그리고 계속해서 소스코드 파일들을 수정한다.

• 완료되면 commit을 한다.

 

5. Git의 명령어

◎ git을 사용하려면 명령어를 알아야 하는데 각 명령어가 어떠한 역할을 하는지 알아보자.

 

git init

- 프로젝트를 git repository로 만들기 위해서 사용하는 명령어입니다.

   git init을 해서 git repo로 만들어야 git으로 버전 관리가 시작된다.

 

git add

- 수정 사항들, 즉 modified 파일들을 staged 상태로 옮기고자 할 때 사용하는 명령어입니다.

   새로 추가된 파일들은 "untracked"파일이라고 하는데, git에서는 이들도 수정 사항이라고 보는 것입니다.

 

git commit

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

 

git diff

- 어떤 수정 사항들이 적용됐는지 볼 때 사용하는 명령어입니다. 참고로 staged 된 수정 사항들은 git diff로 볼 수 없다.

   modified 된 파일들만 볼 수 있다.

 

git status

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

   적인 상황을 보여준다.

 

git log

- commit 내역들을 보여주는 명령어 입니다. git logo를 통해 이제까지 커밋 내역들을 전부 볼 수 있다.

 

git rm

- 원하는 파일을 git repo에서 삭제하는 명령어 입니다.

 

git mv

- 원하는 파일을 git repo상에서 이동시킬 때 사용하는 명령어입니다. 주로 rename할 때 사용한다.

 

git branch

- Branch를 생성할 때 사용하는 명령어 입니다.

 

git checkout

- 어떤 branch를 checkout 할 때 사용되는 명령어입니다.

6. Git Branch & Merge

◎ Git에서 branch는 굉장히 중요한 기능이다.

왜냐하면 git을 사용할 때는 branch 기반으로 개발하기 때문이다.

Branch는 나뭇가지 혹은 분점을 뜻한다. 즉 기본이 되는 큰 줄기가 있고 그 줄기로부터 옆으로 가지가 나는 걸 말한다.

git의 branch모델이 바로 이러한 구조이다. 

순서를 설명하자면 기준을 master branch라고 한다. 그리고 각 개발자는 master branch를 checkout 먼저 하고, master branch로부터

자신만의 branch를 만든다. 이걸 feature branch라고 한다. 그리고 feature branch를 기반으로 개발을 한 후 개발이 완료되고

commit을 하면 자신의 feature branch를 다시 master로 합하게 된다. 이렇게 합하는 과정을 merge 한다고 한다.

위의 내용을 정리하자면,

 

• Master branch를 check out 한다.

• 자신만의 feature branch를 만든다.

• feature branch에서 개발을 한다.

• 완료되면 commit을 한다.

• master branch에 feature branch를 merge 한다.

6-1. Branch 명령어

• git branch feature/이름 (보통 기능별로 brnach를 나누고 기능 이름을 적는다.)

• git branch (branch의 목록을 확인한다.)

• git checkout feature/이름 (자기가 만든 branch로 이동한다.) - master가 아니라 자기가 만든 브랜치로 이동하여 개발하는 것이다.

• git checkout master

• git pull origin master (원격에 있는 변경내용을 자신의 로컬로 가져온다.)

7. 충돌 해결방법

◎ 개발하다 보면 자신이 작업하는 파일을 다른 사람도 작업을 해서 commit을 하면 코드 충돌이 일어난다.

 실제로 프로젝트를 시작하면 많이 발생되는 일이므로 알아두면 좋겠다.

 

• 현재 branch 상태에서 최신 master를 당긴다. (git pull origin master)

• vi 파일명. 파일 형태(ex: README.md)로 들어간다.

• 들어가면 충돌이 난 시점에서 어느 부분이 충돌됐는지 알려준다.

• 충돌 난 부분을 수정하고 vi에디터에서 나와서 git add . 을한다.

• git commit -m "충돌 해결"

• git push origin branch명

• github에 들어가면 충돌이 해제된 걸 확인할 수 있다.

8. Github

◎ VCS(Version Control System)에서는 개발자 간의 협업을 위해 중앙 서버가 있다고 배웠다.

Github는 바로 이러한 중앙 서버의 역할을 하는 서비스이다. 개발자가 직접 git 중앙 서버를 구 한하여 운영할 수 도 있지만,

그러자면 여러 가지 비용과 구현하는 시간이 오래 걸린다. 그래서 가성비 좋고 편리한 github를 사용하는 것이다.