서론
새로 프로그래머스에서 진행하는 자율 주행 교육에 들어가면서 앞으로 깃허브로 협업을 할 일이 많아진다고 하셨다. 그러나 오랜만에 하려고 하니 학부때 배웠던게 가물가물했고 개인적으로 올리기만 했어서 간단하게 내가 보기 쉽게 정리해보려고 한다.
Git Hub란?
먼저 Git 과 Github는 비슷하면서 다르다.
Git
Git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.
간단하게 강의에서 버전 관리의 중요성에 대해 들었는데 버전 관리의 대표적인 예로 IOS, 카카오톡 나아가서 구글 드라이브 같은 것이 있었다. 변경 사항이 일어난 시점별로 맞춰서 버전을 관리 할 수 있는 대표적인 예시가 바로 구글 드라이브다.
아무튼 쉽게 이야기하면 Git은 개인 컴퓨터에서 돌아가며 개인 계정을 사용할 필요도 없고 인터넷이 연결되어 있을 이유도 없다.
그럼 왜 버전 관리를 해야할까? 그건 Conflict 부분에서 잘 다뤄보자.
GitHub
GitHub는 대표적인 무료 Git 저장소이다. 일종의 Git 소프트웨어를 지원하는 클라우드 시스템인것. 비슷한 계열로 Gitlab과 Bitbucket이 있으며 Bitbucket을 간단하게 사용해본 기억이 있다.
다량의 오픈소스가 있고 개발자들의 포트폴리오라고 불린다.
Add
Add는 Local에서 올리기 위해 올릴 파일들을 리스트업 하는 작업을 git add라고 한다. 처음 파일을 등록하는 작업이라고 할 수 있다.
Commit
의미있는 변경이라고 정의했다.
Local 환경에서 Add된 파일을 Local repository에 변경하고 부가 설명을 달아놓는 작업을 Commit이라고 한다.
Git에서는 버전을 분산해서 관리하고 작업한다. 그리고 그걸 한데 모아 GitHub에서 협업을 진행하는데 단순히 변경된다는 개념이 아니라 내가 맡은 분야에서 코드를 수정해 Commit하면 의미있는 변경이 되기 때문이다. 그 예시로 버그를 고쳐서 그 코드를 Commit 한다거나 메인 페이지를 만들어서 코드를 Commit 할 수 있을 것이다.
그리고 그 Commit은 계속해서 쌓이고 쌓여 의미있는 변동사항을 기록해가며 버전 관리를 하게 되는 것이다.
하나의 안좋은 예시로 커밋을 할 때 설명을 적을 수 있는데 안좋은 개발자의 GitHub 예로 위처럼 Commit을 하고 아무 설명을 달아 놓지 않는다는 것이다. 내가 수정한 코드가 도대체 어떤 부분을 수정했는지 알 수 없게 되기 때문이다.
계속해서 Commit에 설명을 자세하게 적을 수 있도록 하는 습관을 들여야겠다.
push
그럼 이제 Commit을 한 코드를 Remote repository에 올려야한다. 이 과정을 push라고 한다.
- Working Dierctory
- 코드작업을 하는 공간
- 변경이 생기는 공간
- 파일이 생성/수정/삭제됨
- Staging Area
- 버전이 될 후보들이 올라오는 공간
- Working Directory에서 선별
- Repository
- 버전들이 저장된 공간
