Git & Github

Critical Important Nice To Have

깃 리포지토리는 깃 저장소(워크스페이스)라고 할 수 있다. 깃에게 어느 디렉토리에 저장소를 만들어야하는지 수동으로(Manually) 지시해야 한다. 즉 깃에게 한 프로젝트를 수행할 새로운 저장소를 생성하라고 지시해야 한다. 깃 리포지토리는 그 프로젝트의 이력을 갖고 있

프로젝트에서 작업하면서 깃을 사용할 때, 갖고 있는 파일이나 디렉토리가 어느 시점에서 깃에게 알려지거나 추적되는 것을 원치 않고 완벽하게 제외되는 상황이 있다. 이때 .gitignore라는 특정 파일을 생성할 수 있다.이에 앞서서 이런 상황을 필요한지에 대해 알아보자.

브랜칭을 알아보기 전에, 깃이 어떻게 작동하는지 이야기 해보겠다. 우선 커밋을 하면 각 커밋은 숫자와 문자가 연속적으로 조합된 해쉬를 갖는다. 987fac676ac7dd765e 와 같은 해쉬가 있는데 이는 커밋과 1대1로 대응한다. 그리고 커밋은 부모 커밋을 참조하고

Fast Forward 병합은 특별한 케이스로 모든 병합이 이런 방법으로 작동하는 것은 아니다. 브랜치는 단순히 브랜치 포인터에 의해 정의된다는 것을 기억한다면, Fast forward 병합은 단순히 master 브랜치의 브랜치 포인터가 bugfix 브랜치 포인터가 가

Critical Reading Diffs 박스 친 부분은 비교할 파일들이 있다. 보통 이 파일들은 동일한 파일이다. 박스 친 부분의 a와 b는 같은 파일이지만 다른 버젼을 의미한다(항상 구버전, 신버전으로 작동되는 것은 아님). 이때 다른 파일이 올 수도 있지만 따로

Git Stash 는 무슨 일을 하는지 알아보자. 잠시 상상해보자. 지금 저장소에서 작업하고 있고 master 브랜치에 있다고 하자. 아래의 그림과 같은 상황이다.그리고 커밋한 후 새 브랜치를 만들고 이동한다.그리고 puppy 브랜치에서 새로운 작업을 하고, 아직 커밋

git checkout d8194d6(축약된 해쉬 사용 가능(7자리)) 처럼 git checkout을 브랜치를 체크아웃하기 위해 사용하는 게 아니라, 특정 커밋 해시를 체크아웃하기 위해 사용할 수 있다. 그러나 이와 같은 명령을 실행하면 다음과 같은 에러가 나올 수 있

Critical Important Nice To Have

Critical Remote Tracking Branches 원격 추적 브랜치는 무엇일까? 저장소를 클론할 때는 일어나는 일에 대해 먼저 알아보자. 처음에는 내 컴퓨터에는 아무것도 없는데 git clone을 하면 저장소에서 온 모든 파일과 세 개의 커밋이 생긴다. 그

공개 저장소는 인터넷의 모든 사람이 접근할 수 있고 검색할 수 있고 클론할 수 있다. 그러나 다른 사람들이 모두 푸쉬할 수 있다는 뜻은 아니다. 저장소 설정에서 공개 여부를 전환하려면 소유자여야 한다. 공개 여부를 전환하려면 setting에서 Danger Zone으로

이러한 형식을 중앙 집중형이라고 한다면,이 워크플로우는 모든 사람이 마스터 브랜치나 메인 브랜치에서 작업을 하는 것이다. 만약 세명이 깃허브에서 공동작업을 한다고 해보자. 그리고 Pamela, David, Forrest는 모두 깃허브에서 클론을 했다. 그리고 나서 Fo

Critical Important Rebasing Vs. Merging 개발자 10명과 함께 프로젝트에 참여하고 있다고 가정해보자. 마스터 브랜치가 있는데 수백만 개의 커밋이 있어서 일일이 볼 수 없는 상태라고 하자. 새로운 기능을 만들어야해서 feature 브랜치를

피처 브랜치에서 작업한 후 커밋을 푸쉬하기 전에 커밋을 없애거나 수정하고 싶을 때 git rebase 를 사용할 수 있다. 현재 어떤 브랜치에 있든 해당 브랜치의 끝을 기점으로 리베이스를 한다. 이때 git rebase -i HEAD~4와 같이 -i 옵션을 사용하면

특정 커밋에 추가하는 일종의 라벨이다. 주로 프로젝트 릴리스를 표시하는 용도로 사용된다. 태그는 시간의 어떤 지점을 가리키는 라벨과 비슷하다. 브랜치 레퍼런스는 커밋이 추가되면 가리키는 대상이 변한다. 그러나 태그는 처음 지정된 커밋을 계속 가리킨다. 아래의 그림을 보

config 파일은 설정을 위한 파일로 모든 저장소에 존재한다. 이 파일에 값을 설정한다면 이 값은 현 저장소에서만 유효하고 다른 저장소에는 영향이 없다. 그러나 설정 값을 바꿀 때는 많이 없을 것이다. 예전에 사용했던 명령어인 git config user.name 과

reflog는 reference log의 줄임말로 깃이 우리들을 위해 보관하는 레퍼런스 기록이다. 깃은 레퍼런스에 변경 사항이 있을 때마다 깃이 기록을 남기고 이것들을 파일에다가 저장해둔다. .git 안에 logs 폴더로 들어가 HEAD 파일을 보면 헤드 참조의 이동을

깃을 설정해 줄 수 있는 장소는 세가지가 있다. 각각의 모든 깃파일에는 config 파일이 있고 이것은 하나의 저장소에만 적용이 된다. 그 다음 전역적 깃 설정 파일이 있다. 그리고 전체적 시스템 수준의 설정 파일이 있다. 만약에 하나의 컴퓨터에 여러 유저가 있다면 전