Git은 소스 코드 기록을 관리하고 추적할 수 있는 버전 관리 시스템.
Github은 Git Repository를 관리할 수 있는 클라우드 기반 서비스.
Git으로 버전을 관리하는 폴더에 대해서 Github을 통해 여러 사람들이 공유하고 접근할 수 있음.
Git으로 관리되는 폴더를 Git repository 라고 하는데, 내가 작업하는 소스 코드 폴더가 버전 관리를 받게 하기 위해서는 내 폴더를 Git의 관리 아래에 두는 작업이 필요함.
Remote Repository와 Local Repository 두 종류의 저장소를 제공함.
Local Repository는 작업 공간이고, 작업한 코드를 공유하려면 Remote Repository에 업로드해서(push
) 다른 사람들이 볼 수 있게 공유함. 그리고 다른 사람이 Remote Repository에 올려 놓은 소스 코드를 내 Local Repository로 가지고 올 수도 있음.(pull
)
대략적인 흐름은 다음과 같다.
혼자 : fork -> clone -> add -> commit -> push -> pull request
with 페어 :
fork -> clone -> remote add pair -> add -> commit -> push -> pull pair -> add -> commit -> push -> pull request
하지만 작업 파일의 상태에 따라 달라짐.
파일의 상태는 크게 untracked / tracked
로 나뉘고, tracked는 unmodified / modified / staged
로 나눠짐.
untracked는 한 번도 깃에서 버전 관리를 하지 않아서 수정내역을 추적하지 않은 상태를 말함. 예를 들어 내 컴퓨터에서 생성한 디렉토리는 untracked 상태임. 이때 init 명령어로 git의 관리 하에 놓을 수 있음. 여기서 add 하면 staged 상태가 됨.
tracked는 한 번이라도 깃에서 버전 관리를 한 적이 있는 파일의 수정 여부를 추적하는 상태를 말함.
여기서 unmodified는 commit 할 사항이 없는 깨끗한 상태를 말하는데, 외부에서 clone해서 받아온 폴더나, commit을 마친(=committed) 작업 파일의 경우, 이에 해당됨. 여기서 수정을 하게 되면 modified가 되는데, 이 상태의 파일을 staged 상태로 만들어줄 수 있음. 이때 add를 하면 staged 파일이 되는 거임.
staged 파일은 commit 할 수 있는 상태임. 이후 committed(= unmodified) 상태가 되면, push해서 내 remote 저장소로 내보낼 수 있는 거임.
*add는 용도가 비슷한 물건들을 한 박스에 담는 행위, commit은 그 박스에 라벨링을 해주는 행위와 같다고 생각하면 됨.
+) 이미 커밋이 끝난 파일을 다시 수정하게 되면 modified 상태가 되어서 다시 add, commit를 해줘야 함.
+) 페어와 작업하는 중, 페어의 리포짓으로부터 pull한 파일이 나의 커밋 파일과 내용이 다를 때 자동 병합(merge)이 일어남. 이때는 add, commit을 안 해도 됨. 근데 만약 나와 페어가 같은 줄을 수정했다면 병합 충돌(conflict)가 일어나는데, 이때는 내가 직접 충돌을 없애야 함(+4가지 선택지가 나옴). 이런 경우 수동 병합이라 따로 add, commit을 해줘야 함. 그리고 merge commit은 자동으로 Commit 메시지가 생성돼서 옵션 없이 써도 됨.(물론, 메세지 수정도 가능.)
다른 Remote Repository있는 공유 프로젝트를 내 Remote Repository로 가지고 옴. 이 시점부터 해당 프로젝트는 내 Repository에 복사본으로 저장된 거임.
그리고 그 프로젝트를 작업하기 위해 내 컴퓨터로 가져옴.
git clone <레파지토리 주소>
add 명령어를 통해 파일들을 staged 상태로 만들어줘야 함. 즉, staging area로 올려야 함. 파일이 staged 상태에 있어야 commit할 수 있음.
+git status
작업 파일의 상태가 어떠한지 알아야 해당 파일에 대해 어떤 행동을 할 수 있는지 알 수 있음. 이 명령어를 통해 staging area와 untracked files 목록에 어떤 것들이 있는지 확인할 수 있음.
staging area에 들어온 파일들은 commit이 가능함. 변경 사항을 저장하기 위해서는 commit을 활용함. 어떤 사항이 변경됐는지 간단한 메모를 통해서 버전의 변경 기록들을 관리할 수 있음.
-m
옵션을 통해 코멘트를 작성함.
git commit -m '커밋 메시지'
커밋이 완료된 파일은 다시 unmodified
상태로 돌아감.
Q. 방금 commit한 기록을 취소하고 싶다면?
아직 Remote Repository에 업로드 되지 않고 Local Repository에만 commit 해 놓은 기록이라면 reset 명령어를 통해서 commit 을 취소할 수 있음. git reset HEAD^
*HEAD는 연속된 ^의 shortcut 임.
예를 들어 HEAD3은 HEAD^^^와 같음.
HEAD^은 HEAD~1 라고도 쓸 수 있음.
추가적으로 hard, soft 옵션도 있음.
~push하기 전까지는 Local Reposit, push 후엔 Remote Reposit~
commit 후, 내 remote repository에 push 해서 commit 기록을 remote 에도 남겨줄 수 있음. git push origin branch
git push origin main, git push pair dev 등 git push 뒤에 따라오는 명령어는 상황에 따라 변경할 수 있음. 참고로 pair는 내가 부르고 싶은 별칭으로 쓸 수 있음.
ex) git push ys master
Q. 남긴 commit들이 잘 기록되었는지 확인해 보고 싶으면?
: git log
현재까지 commit 된 로그들을 터미널 창에서 확인할 수 있음.
*q를 입력하면 이 터미널 창은 종료됨.
push를 완료한 후 remote의 원래 레파지토리에 pull request
를 보내면 내가 수정한 코드를 업로드할 수 있음.
(이건 브라우저로 진행)
git init
untracked file(내가 생성한 파일) --init-->
:init
은 기존 프로젝트를 Git Repository로 변환하거나
새로운 Repository를 초기화하는 데에 사용할 수 있음.
이렇게 Local Repository가 생성되었음.
git remote add origin <리포짓 주소>
Local Repository --- Remote Repository
: 내 컴퓨터의 Git 디렉토리를 Remote Repository와 연결시켜 주는 작업임.
git remote add pair <리포짓 주소>
: 다른 사람의 Repository 와 연결.
**상대방의 Repository의 이름은 편의상 pair라고 지음.
:git remote -v
명령어를 통해 현재의 Local Repository와 연결된 모든 Remote Repository 목록을 확인할 수 있음.
서로의 변경 사항을 pair와 Remote Repository를 통해 공유함.페어가 작업한 내용을 확인하고 싶으면 다음의 명령어를 사용함. git pull <shortname> <branch>
ex) git pull pair master
Accept Incoming Changed은 pull한 Remote Repository의 내용을 파일에 반영하는 거고, Accept Both Changes는 변경 사항 모두를 반영함. 위 4가지 옵션 이외에도 직접 파일을 수정해서 반영하는 방법도 있음.
git add 파일
, git commit 파일
(자동병합때는 안 해도 됨.)이후에 Remote Repository로 push함.
*페어와의 remote 지우기: git remote remove