GitHub 정리
GitHub
버전 관리 시스템으로 버전, 백업, 협업을 위한 툴!
버전 관리의 본질은 원본을 수정하지 않고 원본의 복제본을 만들어 수정하는 것이다.
- git version check
1 2 3
git --version git -v git version
- git config list
1 2 3
git config --list git config user.name # 등등
- 로컬저장소 생성
- 여기서 생성되는 .git 파일이 저장소
1 2 3
git init # 로컬 저장소에 원격저장소를 알려줌 git remote add origin <url>
- 주소 url를 다 기억할수없어서 origin이라고 불러줌(별명)
- 지역저장소에 여러개 원격저장소를 연결할수있음
- remote tracking branch이라고 어디까지 서버로 했는지 확인할 수 있다.
- HEAD -> main -> file
origin/main -> file
git 구조
- HEAD는 현재버전
- main은 마지막 버전
- 이전엔 master 였는데 사회적 논란으로 main이 됨…
- 지금 만든 버전의 부모는 HEAD다
- HEAD는 새로운 버전을 가르키는데
- HEAD → main(head의 대리) → a
b가 추가될 경우 - HEAD → main → a
b → a - HEAD → main → b → a
- c 추가 ⇒ c → b → a
- HEAD → main → c → b → a
- HEAD → main(head의 대리) → a
- 부모는 자식이 누군지 모르지만 자식은 부모가 누군지 안다
- 각각의 commit은 commit을 한 시점에 stage area의 스냅샷이다
- 각각의 버전은 과겨의 상태를 포함한다
- main을 b로 보내면 영원히 이전 버전으로 감. HEAD를 b로 보내면 잠깐 이전 버전으로 감.
- checkout은 head를 바꾼다
1 2
git checkout b git checkout main
- reset은 branch를 바꾼다
- 일반적으로 hard를 사용
1
git reset --hard commit_id
git reflog를 통해서 commit_id와 commit 메세지를 확인할 수 있음
git 관리
- 팀원끼리 rule을 정해서 진행
- branch를 사람마다, task마다 생성할 것인지 등등
- commit 방법
- commit 메세지를 수정할 때도 새로운 복제본을 만들어 수정하는 구조이다
1 2 3 4
git add <file/folder> git commit -m <commit_message> # commit message를 수정하고 싶을때 git commit --amend -m <commit_message>
- pull
- pull = fetch + merge
- fetch의 경우 절대 conflict 발생안함
conflict - git merge hell
- 보통 다른 branch끼리 merge하는 과정에서 같은 파일에 있는 같은 부분을 동시에 수정했을 때 발생
- 병합편집기를 통해 사용자가 직접 최종 결과를 수정해 merge 한다.
rebase,revert,cherry-pick의 경우 3 way merge에 의해 conflict날 수 있다.
merge- merge의 경우, 하나의 새로운 파일을 생성하여 현재버전으로 설정한다
- conflict가 발생한 부분을 사용자가 직접 수정
rebase
- rebase의 경우, 타임라인을 간단하게 하고 싶을 때 사용한다
- 보기는 좋지만 지식이 필요하고 섣불리 시도하면 큰 고생을 할 지도?!
- conflict가 연속적으로 계속 발생할 수 있고 심도가 깊어지면 상황이 복잡해질 수 있으므로 비추
- 서로다른 group화에 불리하다
- conflict가 발생한 부분을 사용자가 직접 수정
- 더이상 가르키지 않는 부분은 마치 삭제된 것처럼 처리된다.
cherry-pick
reject
- 원격저장소의 내용을 갖고 있지 않을 채로 push하려고 할 때 발생한다
- pull(/fetch)을 통해 원격저장소의 내용을 받아옴
This post is licensed under CC BY 4.0 by the author.