Git(2) branch

Git branch: Commit을 가리키는 포인터

git branch {name}

name이라는 branch 생성

 

git checkout {name}

head가 name의 branch를 가리키게 함

name 대신 Commit의 Id를 적어주면, head가 특정 브랜치를 가리키는 것이 아닌 특정 Commit에 위치하게 됨.

(Branch를 통해 Commit을 가리키는 것이 아닌 head가 직접적으로 Commit을 가리키는 형식)

-->Detach 상태 (branch와 분리되어 있는 상태이다.)

--> 과거의 Commit으로 부터 새로운 branch를 만들때 주로 사용한다.

head가 가리키는 branch의 commit의 모습으로 보임

 

git log --all --graph (--oneline)

 

--all : head가 가리키는 branch외의 모든 branch를 보여준다

--graph: branch와 commit의 관계를 그래프 형식으로 표기해준다.

--oneline: 부가적인 정보를 제외한 commit에 관한 부분만 보여주며 Commit history를 확인하기 좋다.

 

git merge {name}

현재 head가 브랜치를 통해 가리키는 커밋과 merge뒤 name이 가리키는 커밋을 합친다.

 

Fast-forward merge

head브랜치를 name 브랜치로 끌어당김.

브랜치가 이동만 한다.

 

같은 Line에 적힌 코드를 merge할 경우 Conflict 발생!

위 그림과 같이 git에서 표시해줌

원래 원하는 모습으로 편집하면 됨.

그 후에 원래대로 git add  --> git commit 하면 해결!

새로운 merge commit 탄생!

 

##git push -u origin master

 

-u : master브랜치가 git서버의 master브랜치를 바라보게 하라

 

git push, pull은 브랜치를 단위로 실행된다.

따라서 우리가 branch를 master가 아닌 다른 branch인 상태로 commit을 올렸다면

git push(pull) -u origin {branch name}

과 같은 명령어를 실행하면 된다.

 

그 이후 gitlab에서 branch를 push한 branch로 설정후 커밋을 확인할 수 있다.

 

git remote add {url을 가리킬 이름} {url}

외부 저장소 즉, 서버와 관련된 Url을 이용하여 프로젝트에 push 혹은 pull하기 위해 url을 가리키는 이름을 통해 remote하는 명령어

 

git remote -v 

컴퓨터가 인식하는 gitlab 서버상의 프로젝트를 한눈에 보는 명령어

 

git push --force {url을 가리킬 이름(ex.origin)}

깃 서버의 version보다 컴퓨터의 project version이 낮을 경우 강제적으로 컴퓨터의 프로젝트로 덮어쓰기 위해서 

사용한다.(하지만 이것은 공동 프로젝트로서 매우 지양해야 하는 행동)

-->이전 커밋이 날라가기 때문

 

Fork

원본 프로젝트를 복제하는 기능(복제본 프로젝트)

복제된 프로젝트를 통하여 commit을 생성하여 merge를 하기 위해서는 기본적으로 maintainer의 확인을 받아야 한다.

(commit 한 내용들을 확인하고 사용 가능한지 체크해야하기 때문)

이것을 위해서 복제본 프로젝트를 최신화 시키고 commit, push 하고 나서 gitlab에서 Merge request를 통하여 승인 절차를 행한다.  -- > developer가 하는 역할

 

이후 Maintainer은 developer의 merge request를 확인하고 discussion등의 부가적인 업무 뒤에 merge를 하고 프로젝트가 merge된 것을 확인할 수 있다. --> Maintainer가 하는 역할

 

Setting에서 Merge requset란에서 merge request가 왔을 때의 default 설정을 할 수 있다.

(항상 merge commit을 생성한다거나 Fast Foroward가 가능하다면 Fast Forward를 하는 등)

 

• Merge Commit : 항상 새로운 Merge Commit을 생성
• Merge Commit with semi-linear history : Fast Forward merge가 가능할때 새로운 Commit을 생성
• Fast Forward: Fast Forward가 가능할 때 commit이 Fast Forward 됨

Merge Commit / Merge Commit with semi-linear history / Fast-forward merge

 

Merge Commit

두개의 복제 프로젝트에 의해 Merge를  할 경우 두개의 Merge Commit을 만들어낸다.

Commit history 가 지저분함.

 

 

Merge Commit with semi-linear history

두 개의 복제 프로젝트 중 첫번째 Merge하는 프로젝트는 Fast Forward가 가능하므로 새로운 Merge가 생성

두 번째 프로젝트는 흐름이 쪼개져 Fast Forward가 불가능하므로 새로운 Merge 생성이 불가능하다.

--> rebase 작업을 통해 해결한다!

rebase 

Commit history 를 복제프로젝트가 Conflict 상황이 왔을때 정리되어 history가 정렬됨

 

Fast-forward merge

Fast forward가 가능해야 merge가 허용되고 Fast forward가 불가능하면 rebase 작업이 필요함

Commit history 는 깔끔하지만 branch 가 갈라지고 merge되는 관계를 파악하기 어려움

 

 rebase

 

Fast-forward-merge가 불가능한 경우  Merge request시 Maintainer의 gitlab에서는 Merge가 불가능함.

git rebase {branch name}

시작점을 최신 Commit 뒤에 붙여주는, 즉 시작점을 재설정해주는 명령어

이 때 앞서 발생한 것 처럼 merge Conflict가 일어날 수 있음.

-->사용자가 편집해주면 해결!

git rebase --continue

그대로 rebase를 진행하라는 명령어

 

이후 최종 커밋메세지를 조금 더 자세히 남길수 있는 창이 나타남.(변경하거나 혹은 변경하지 않아도 됨)

 

but, 컴퓨터에는 rebase가 진행되었고, gitlab 서버에는 rebase가 된 상태가 아니므로 push할 때는 오류가 발생하게 됨.

--> git push --force를 통하여 push를 행한다. 

 

일련의 과정 이후 gitlab에서 Merge request를 진행하면 된다!