오픈소스 3주차 보고서 - Git

이번주에는 ‘Git을 이용한 소스코드 관리‘라는 내용에 대해 배웠다. 강의자료가 90장 이상이어서 살짝 겁먹었는데, 막상 강의를 들으니, 생활코딩 라이브 git강의에서나 전에 공부하면서 배웠던 내용도 복습할 수 있었고, 원래 관심있던 쪽이라 그런지 쭉쭉 잘 이해되어서 재미있게 들었다. (아무래도 Git은 프로젝트를 할때나 협업할때나 필수니까..!)

1. Git의 등장배경
먼저 Git의 등장배경을 알아보기 위해, 기존 버전 관리 시스템들은 어땠는지 간단히 살펴보았다. 버전 관리는 백업과 복구를 위해 반드시 필요한데, 기존 버전 관리 시스템들은 로컬에서 버전을 관리하거나 중앙 집중식으로 버전을 관리했는데, 이때 전자는 협업이 어렵고, 최신 버전을 관리하기가 번거롭다는 단점이 있었고, 후자는 중앙 서버가 닫혀버리면 그동안의 모든 작업 히스토리가 날아가버린다는(SPOF; Single Point of Failure) 치명적인 단점이 있었다. 이러한 단점을 보완하기 위해 등장한 것이 바로 ‘분산 버전 관리’ 시스템인 Git이다.

2. 그래서 Git이 뭔디
리눅스 토발즈가 만든 Git은 앞서 말한 단점들을 모두 해결할 수 있는, 소스 코드 관리를 위한, 분산 버전 관리 시스템이다.
Git의 가장 중요한 특성에는 몇가지가 있는데,
먼저 각 파일들의 버전의 차이를 저장하는 것이 아니라, 새로운 버전들을 아예 스냅샷으로 통째로 저장한다는 것이다. 만약 달라진 것이 없다면, 링크만 저장하여 효율적으로 저장한다. 그래서 파일의 각 버전들에 대한 백업과 복구가 용이하다! 와우~
그리고 프로젝트의 히스토리가 로컬에 있기 때문에 거의 모든 명령을 로컬에서 실행할 수 있고, 심지어 오프라인 작업도 가능하다! 거기다 무결성 검사와, 데이터베이스로 데이터를 관리한다.

이러한 특징을 가진 Git은 파일을 관리할때 세가지 상태들이 이어지는데, Modified -> Staged -> Committed 이다. 간단히 흐름을 말하자면, (먼저 git init으로 로컬에서 작업하는 디렉토리를 Git 저장소로 만든 뒤) 로컬(Working Directory)에서 파일을 수정한다면, 그 파일에 대한 새로운 버전이 생성되었으므로, 이를 원격 저장소에 올리려면 먼저 Staging Area에 (git add 명령어를 이용하여) 파일을 Stage해서 커밋할 스냅샷을 만들어야한다. 이후 (git commit 명령어로) Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다.
커밋할때에는 코드 변경사항에 대한 빠른 이해와 효율적인 개발과 협업을 위해서 커밋 메세지가 굉장히 중요한데, 어떤 작업을 했는지에 대한 동사를 명령어로 작성한 뒤, 작업 내용(What)과 왜(Why) 그 작업을 했는지를 간단히 한 문장으로 적어주면 좋다. (예 : Fix error that prevents users from choosing the categories) 자세한 내용은 아래 필기에 있다.

혹시 각 파일들이 어떤 상태인지를 확인하고 싶다면 git status 명령어를 이용하면 되고, 특정 원격저장소를 복제하고 싶다면 git clone을, 커밋 히스토리를 조회하고 싶다면 git log 명령어를 이용하면 된다.

파일을 삭제할때에는 git rm 명령어를 사용하면 된다.(그냥 rm으로 파일을 삭제하면, git이 삭제되었다는 것도 추적한다) git rm은 rm과 git add가 포함된 것이라 생각하면 된다. 이 명령어를 쓰면 working directory와 staging area에서 모두 파일이 사라진다.
이렇게 삭제한 파일을 복구하고 싶으면 git restore 명령어를 쓰면 된다.
명령어 한번으로 복구하고 싶으면 git restore —staged —worktree (파일 이름)을 하면 된다.
상세히 보자면, git restore —staged는 stage 상태의 파일을 원격 저장소의 HEAD로부터 복구한다. 그리고 git restore —worktree는 그렇게 HEAD로부터 복구되어 Staging Area에 있는 파일을 Working Directory로 복구한다.