git?

버전 관리 시스템(VCS, Version Control System)의 한 종류
깃은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다. 소프트웨어 개발에서 소스 코드 관리에 주로 사용되지만 어떠한 집합의 파일의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다.

Git 영역

Working Directory (Local)

• 나의 작업 디렉토리에 있는 파일은 2종류로 나눌 수 있다. 하나는 git이 인지하고 있는 파일(tracked files) 하나는 git이 아직 존재를 모르고 있는 파일(untracked files)이다.
• 내가 원격 저장소에서 있던 파일을 clone하면 로컬 저장소와 작업 디렉토리에 저장되므로, 원격 저장소에 원래 있던 파일은 당연히 깃이 알고 있다. 그런데 내가 로컬 컴퓨터에서 추가로 작업을 하고 작업 디렉토리에 새로운 파일 new.txt를 추가했다고 하자. 이는 아직 깃이 존재를 인지하지 못하고 있다. (untracked)

git add

깃이 이 파일의 존재를 인지하게 하려면 git add 명령을 내린다. 이 명령은 스테이징 영역에 이 파일을 추가한다.

Staging Area

• 스테이징 영역은 내가 저장소에 업데이트하고 싶은 모든 변화들을 모아놓는 곳이다.
• 이제 스테이징 영역에 add를 했으면 commit할 준비가 되어 있다.

git commit -m "Add New"

git commit 명령은 스테이징 영역에 있는 파일들을 로컬 저장소에 반영한다. -m 뒤에 오는 문자열은 commit 메세지이다. (커밋 메세지는 변경사항이 뭔지 알려주기 때문에 중요하다!)

여기까지는 내 로컬 컴퓨터 안에서만 변화가 일어난 것이지, 다른 사람이랑 공유되지는 않은 상태이다. 이를 다른 사람과 공유하기 위해서는 원격 저장소를 업데이트 해야 한다.

Local Repository

git commit 을 통해서 최종 수정본을 제출

git push

로컬 저장소의 커밋을 원격 저장소와 공유하려면 push 명령을 사용한다. 이제 new.txt 파일은 작업 디렉토리, 로컬 저장소, 원격 저장소에 존재하고 있는 상태이다.

git status 명령어를 쳐보면 tracked된 것과 untracked된 파일이 무엇인지, 나의 로컬 저장소와 원격 저장소가 다른지, 내가 지금 어떤 브랜치에 있는지 알 수 있다.

Remote Repository

Branching

• 원격 저장소에서 처음 clone 했을 때에 개발환경은 자동적으로 마스터 브랜치부터 시작한다.
• 일반적으로 별도 브랜치에서 작업을 하다가, 그 작업 결과물이 확실할 때 마스터 브랜치에 머지(merge)한다.
• 깃헙같은 깃 레포지토리 매니저는 일반적으로 마스터 브랜치는 아무나 푸시할 수 없도록 디폴트를 protected로 설정한다.

git branch test

git checkout test

git checkout -b test

git branch 명령은 새로운 브랜치를 생성하여 로컬 저장소에 추가해준다. 새롭게 만들어진 test 브랜치는 내가 현재 위치한 브랜치의 커밋된 내용을 복사한다.

커밋 명령을 하면 내가 현재 위치한 브랜치에 커밋된다. 반면 작업 디렉토리와 스테이징 영역은 브랜치를 신경쓰지 않는다.

내가 현재 로컬 저장소의 어느 브랜치에 위치하고 있는가를, 포인터가 가르키고 있다고 가정하자. HEAD(local branch tail point)라는 것이 이 포인터 역할을 하며 내가 있는 브랜치의 위치(그리고 내가 커밋하게 될)를 가리킨다.

git checkout을 사용하면 그 브랜치로 스위치할 수 있는데 이는 HEAD가 그 브랜치를 가리키게 되는 것과 같다.

git checkout -b 는 브랜치 생성과 이동을 동시에 해주는 명령이다.

test 브랜치에서 git push를 하면 어떻게 될까?

fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use

git push --set-upstream origin test

여기서 remote와 upstream은 무엇일까?

조금 자세히 보면

-------- Remote Repository --------
Branches: master, tutorial

-------- Local Repository ---------
Branches: master, test
Remotes: origin/master,origin/tutorial

• 원격 저장소에 원격 브랜치가 2개 있다고 하자. 하나는 master, 하나는 tutorial이다.

• 원격 저장소를 로컬 저장소에 clone하면 깃은 리모트 저장소(=remote)를 만들고 복사한 원격 저장소를 세팅한다. 이 리모트 저장소의 디폴트 네임은 origin이다.

• 그러고 나서 깃은 로컬 저장소에 마스터 브랜치를 체크아웃한다.

• 로컬에서 원격 브랜치와 똑같은 이름을 가진 브랜치를 체크아웃하면, 이 로컬 브랜치는 원격 브랜치와 링크된다. 이 링크된 원격 브랜치가 로컬 브랜치의 upstream branch가 된다.

• git push --set-upstream origin test를 수행하면, 로컬 브랜치 test의 upstream 브랜치 즉, 리모트 저장소에도 같은 이름의 브랜치(origin/test)를 생성하게 된다.

• 어렵게 썼지만 로컬에 생성한 브랜치를 원격에도 만들어야 git push를 할 수 있다는 소리이다. 로컬 브랜치를 다른 리모트 브랜치(예를 들어 리모트 마스터 브랜치)에 푸시하고 싶다면 git push origin test:master 과 같이 할 수 있다.

Pull Request와 Merge

commit을 한다고 최종 코드가 수정되는 것은 아니다.

개인이 commit을 했으면, 관리자가 이 코드를 리뷰하고 바꿀것이 있으면 수정해달라고 다시 요청해야한다.

1) Pull Request 발행 (Review 의뢰자)
github에 접속 후, 원격저장소에 들어가서 해당 commit의 pull request 버튼을 누르면 Reviewer에게 풀리퀘스트 메시지 전송

2) Review & Comment (Review 수행자)
리뷰 후 comment 할 것이 있으면 comment 버튼 클릭

3) Comment 대응 (Review 수행자)
local에서 코드 수정 후 원래와 같은 방식으로 commit 수행

git add .
git commit -m "커밋 메시지"
git push

4) Review 및 병합 (Review 수행자)
리뷰 후 최종 결과 만족 시 병합(merge) → github에서 pull request merge 버튼 클릭

원본 저장소 fork ~ PR 흐름

( jQuery에서 어떤 버그를 발견해서 소스를 수정한뒤에 다시 jQuery에 적용요청을 하는 일련의 과정 )

버전 관리 시스템?

파일 변화를 시간에 따라 기록했다가 이후에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다. 동일한 정보에 대한 여러 버전을 관리하게 되며, 버전을 통해 시간적으로 변경 사항과 변경 사항을 작성한 작업자를 추적할 수 있다.

VCS는 크게 아래의 두가지로 나눠볼 수 있다.

1) 클라이언트-서버 모델
하나의 중앙 서버가 존재하며, 여러 클라이언트들은 중앙 서버에서 각자 맡은 파트만 가져와서 작업하고, 다시 중앙으로 통합하는 것을 말한다.
대표적 시스템으로 CVS, Subversion 등이 있다.

2) 분산 모델
하나의 중앙 서버가 존재하지만, 여러 클라이언트들은 각자의 컴퓨터 저장소에 중앙 서버의 전체 사본을 가지고 작업을 하는 것을 의미한다.
대표적 시스템으로 Git이 있다.

git? github?

git - local 내에서 소스코드를 관리하는 것

github - local에서 관리한 소스코드를 업로드하고 공유할 수 있는 공간

Gitflow?

github에 올리기 https://2hyes.tistory.com/91