후루룹 말아먹고 써보는 github 이야기..
막연하게 개념으로만 알고 있던 깃헙 개념을 가지고 실무를 한지 어언 n년차
개발자들 모두 깃헙의 개념을 이야기할때 열이면 열, 모두 이해하고 있는 방식이 다르다.
하지만 협업할때 꼭 사용하게 되는게 깃헙이고 우리가 모두 아는 '그 정도'의 지식이 되려면 나 스스로 정리가 한번 필요하다 생각했다. 그래서 써보는 깃헙 아는대로 정리하기!
Remote Repository 원격저장소
파일이 원격 저장소 전용 서버에서 관리되며, 여러 사람이 함께 공유하기 위한 저장소다.
Local Repository 로컬저장소
내 PC에 파일이 저장되는 개인 전용 저장소다.
저장소를 만드는 방법은 두가지가 있다.
아예 저장소를 새로 만들거나, 이미 만들어져 있는 원격 저장소를 로컬 저장소로 복사해 올 수 있다. 스테이지 내용은 .git/index 파일에 저장되고, 저장소의 내용은 .git/HEAD 파일에 저장된다.
Working Tree (Working Directory)
저장소를 어느 한 시점을 바라보는 작업자의 현재 시점
파일 수정, 저장등의 작업을 하는 디렉터리로 '작업 디렉터리'라고도 한다.
snapshot
특정 시점에서 파일, 폴더 또는 워크스페이스의 상태를 의미
스냅샷을 통해 어떤 특정 시점에 어떤 파일에 어떤 내용이 기록되어있었는지, 폴더구조는 어떠했는지, 저장소의 모든 정보를 확인할 수 있다.
Git에서는 새로운 버전을 기록하기 위한 명령인 commit(커밋)을 하면 스냅샷이 저장된다.
- 개발자는 작업 디렉토리에 있는 파일을 수정
- 수정된 파일을 모아 정리하여 만든 snapshot을 staging 디렉토리에 추가하고 저장
- git 디렉토리에 저장(staging 디렉토리에 저장된 파일을 앞으로 영구 불면의 상태를 유지하는 snapshot으로서 git 디렉토리에 저장하는것)
statging area
저장소에 커밋하기 전에 커밋을 준비하는 위치
작업트리에서 10개의 파일을 수정했는데 4개의 파일만 버전으로 만들려면 4개의 파일만 스테이지로 넘겨주면 된다.
즉, 로컬 스테이지에 올려둔 파일만 원격 저장소에 커밋할 자격이 있는 것이다.
commit
현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업
https://techblog.woowahan.com/2553/
https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0
git에서 한 브랜치에서 다른 브랜치로 합치는 방법으로는 두가지가 있다. 하나는 merge이고 다른 하나는 rebase다.
rebase의 기초
하나의 feature 아래 두개의 브랜치가 있고, 이것들을 commit 해야할 때
이 두 브랜치를 합치는 가장 쉬운 방법은 merge 명령을 사용하는 것이다.
두 브랜치의 마지막 커밋 두개와 공통 조상을 사용하는 3-way-merge로 새로운 커밋을 만들어낸다.
비슷한 결과를 만드는 다른 방식으로 변경된 사항을 patch로 만들고 이를 다시 적용시키는 방법이 있다. 이러한 방식을 rebase라고 한다. rebase 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.
일단 두 브랜치가 나뉘기 전인 공통 커밋으로 이동하고 나서 그 커밋부터 지금 checkout한 브랜치가 가르키는 커밋까지 diff를 차례대로 만들어 어딘가에 임시로 저장해 놓는다. rebase할 브랜치가 합칠 브랜치가 가리키ㄴ는 커밋을 가리키게 하고, 아까 저장해 놓았던 변경사항을 차례대로 적용한다.