해당 문서는 깃허브 데스크탑 유저가 작성한 내용입니다. 기본 개념에서는 개념만 다룰 예정이므로 vscode 유저나 터미널 유저가 봐도 무방합니다. 깃허브를 쓰는 이유에는 필자의 경험이 주가 되므로 개념만 필요하신 분들은 생략하셔도 됩니다.
깃허브 기본 개념
깃 & 깃허브
깃(Git)은 버전 관리 시스템의 한 종류를 말합니다. 깃의 저장소는 로컬 저장소(Local Repository)와 원격 저장소(Remote Repository)로 나눌 수 있는데 깃허브(Github)가 깃의 원격저장소역할을 합니다.
깃허브를 컴퓨터의 폴더나 네이버 클라우드와 유사하게 다양한 파일을 온라인 상의 공간에 올려둘 수 있는 저장공간인데 버전 관리 기능이 더해져 있는 것이라고 생각하면 쉽습니다.
버전 관리 기능을 통해 협업시 한 파일로 시작해 여러 사람이 다른 버전을 가지는 것이나(각기 다른 버전을 어떻게 합치게 되는지에 대해서는 추후 다른글을 통해 서술하겠습니다) 내가 만들어둔 버전으로 파일을 되돌리는 것 등이 가능합니다.
깃허브 업로드 과정
Working Directory
실제로 작업하는 공간입니다. PC에서 프로젝트를 진행하는 폴더라고 보시면 됩니다.
Staging Area
Local Repository 에 저장하기 전에 저장하는 공간입니다. 이 공간에서 프로젝트의 버전을 만든다고 생각할 수 있습니다.
Local Repository
변경 내역들과 함께 파일이 저장되는 공간입니다. 프로젝트의 변경사항들이 기록된다고 볼 수 있습니다.
Remote Repository
깃허브가 해당하는 온라인 상의 저장소입니다.
깃허브 용어 정리
commit
local Repository에 파일을 업로드 하는 것을 말합니다. Stagingg Area에서 Local Repository로 커밋을 진행합니다.
push
최종본을 Local Repository 에서 Remote Repository로 갱신, 저장 하는 것을 말합니다.
pull
Remote Repository에서 Local Repository 로 가져오는 것을 말합니다. 주로 Local Repository과 Remote Repository가 연결되어있고 일부 내용을 동기화 시킬 때 사용합니다.
clone
Remote Repository에서 Local Repository 로 가져오는 것을 말합니다. Local Repository와 Remote Repository가 연결되어있지 않아 Local Repository가 비어있는 가장 초기 상태에서 사용합니다.
fork
한 Remote Repository 다른 Remote Repository 로 복사하는 것을 말합니다.
예시로보는 깃허브 기본 설명
깃허브 기본 개념 한방에 익히는 예시
Working Directory 에서 '세계 제일 감자되기.txt'와 '오늘부터 코딩킹.txt' 를 생성하고 '세계 제일 감자되기.txt'에 위와 같은 내용을 적어 저장했습니다.
Staging Area에 '오늘부터 코딩킹은.txt'는 올리지 않고 '세계 제일 감자되기.txt' 만 올렸습니다.
Commit을 통해 Local Repository에 프로젝트 첫번째 버전을 업로드 했습니다.
Push를 통해 Remote Repository에 프로젝트를 업로드 했습니다.
Working Directory에서 '오늘부터 코딩킹.txt'의 내용을 추가하고 '세계 제일 감자되기.txt'의 문장을 수정했습니다.
Staging Area에 '세계 제일 감자되기.txt'만 올렸습니다.
Commit을 통해 Local Repository에 프로젝트 두번째 버전을 업로드 했습니다.
Push를 통해 Remote Repository에 프로젝트 두번째 버전으로 갱신 했습니다.
깃허브를 쓰는 이유
많은 사람들이 개발의 길을 걷게 되는 순간부터 깃허브를 사용할 것을 권유 받곤 합니다. 개인적으로 저는 처음 코딩에 입문했을 땐 깃허브의 중요성을 깨닫지 못했지만 시간이 지날수록 깃허브의 필요성과 유용함을 뼈저리게 느꼈던 것 같습니다.
프로젝트 협업
저 같은 경우 대학교 저학년 땐 소스파일들을 압축해 메일이나 카카오톡으로 보내고 한 사람이 합치곤 했습니다. 컴공과 학생이라고 해서 모든 프로그램을 보자마자 능숙하게 숙슉슈슉슉 사용하진 않습니다 좀 작은 규모의 c, cpp 프로젝트는 소스파일, 헤더파일 정도만 보내도 합치는데 큰 지장이 없었지만 문제는 제가 웹, 앱 프로젝트를 시작하고 나서 발생했습니다. 웹/앱 프로젝트에선 어떤 파일을 어디서부터 어디까지 압축해야할지도 명확하지 않았고 어찌저찌 파일을 보낸다고 해도 합치는 과정이 굉장히 번거로웠습니다. 이 때 저는 가장 크게 느꼈던 것 같습니다.
"이젠 진짜 깃허브를 써야겠구나"
버전 관리
Ctrl+Z 에는 한계가 있습니다. 물론 실행취소로 해결되는 경우도 있습니다만 프로젝트를 진행하다 특정 시점으로 되돌리기는 쉽지 않습니다. 이 때 깃허브가 한줄기 빛이 되어주는 경우가 많습니다. 저는 과제 제출 직전에 프로젝트를 급하게 수정해버리는 바람에 실행이 안되는 참사를 겪은 적이 있는데 깃허브에 올려뒀던 버전으로 간신히 점수를 받을 수 있었습니다. 코딩은 '왜.. 돼..?' 와 '왜.. 안돼..?' 의 반복이기 때문에 언제든 '왜..돼..?' 로 돌아갈 준비를 할 수 있다는 건 큰 이점인 것 같습니다.
포트폴리오
깃허브만큼 코딩에 얼마나 흥미가 있는 사람인지와 코드를 어떻게 짜는 사람인지 보여줄 수 있는 것도 없다고 생각합니다. 잔디밭으로 얼마나 코딩을 꾸준히, 열심히 하는 사람인지 보여줄 수도 있고, 자신있는 프로젝트를 어필할 수도 있어서 많은 분들이 포트폴리오 용으로 깃허브 링크를 첨부하기도 합니다. 정말 훌륭하신 분들의 경우 깃허브를 통해 여러 제안을 받는 경우도 있다고 합니다. 부럽읍니다...
Reference
Working Directory, Stage
깃허브 용어
Stagin Area가 있는 이유
오타, 오개념 지적 환영합니다! 읽어주셔서 감사합니다😀
