[Git] Git(깃)에 대해 알아보자 (2)

저번 글에서 push, pull 까지 알아보았다면 이번에는 공동으로 사용하는 작업공간이라고 생각하고 git에서 제공하는 다른 명령어들을 알아보려고 한다.

 

한 브랜치에서 다수의 작업자가 공동으로 사용하는 일은 정말 많다. 지금 우리 회사에서도 이와 같이 사용하고 있어 종종 소스간에 충돌(conflict)이 일어나고 있다. 이를 효과적으로 나누기 위해 브랜치의 개념이 등장하였지만 부득이하게도 같은 브랜치에서 작업을 해야 하거나, 급하게 서버에 반영을 해야하는 등 브랜치를 사용하기 애매한 시점에는 다른 방법을 사용한다.

 

가장 먼저 확인할 사항은 소스가 최신화가 되어 있는지 pull을 받는 것이다. pull을 받게 되면 1초 전에 같은 브랜치에 올라간 소스일지라도 체크가 가능하지만, 일일히 소스를 수정할 때마다 pull command를 타이핑하는 것은.. 번거롭다(그렇게 습관드는 것이 너무 어렵다..ㅠ)

이를 대체하고자 만든 명령어가 merge, rebase 이다.

 

merge

 

git merge branchname

merge: 작성한 소스를 HEAD위로 올려보낸다. 하지만 commit 이력을 push가 되는 시점의 브랜치의 최상단 아래로 넣어버린다.

중도에 conflict된 소스는 IntelliJ에서 제공되는 Smart Merge 를 이용하여 어떤 소스를 push할 지 선택할 수 있다.

 

merge (글씨 못씀 주의)

mac의 intelliJ의 경우 브랜치 > 우측 아래를 누르면 Merge가 가능하다

 

rebase

 

git rebase -i HEAD

rebase: 내가 작성한 소스가 HEAD 위로 올라가는 것은 merge와 같지만, commit 이력이 최근 push 시점 이후로 갱신된다는 것이 merge와의 차이이다.

 

rebase (글씨 못씀 주의222)

IntelliJ Rebase 위치

Onto에서 어느 브랜치의 위로 올릴지 정해주면 된다

우측 하단에서 브랜치 > Rebase 를 하는 방법도 있다

revert

 

git revert HEAD

revert: 기존에 커밋하였던 내역을 삭제하고 HEAD로 소스를 되돌린다. 또, 여기서 git add된 파일들은 커밋하기 전의 상태로 되돌아가기 때문에 IntelliJ에서는 빨간색으로 출력된다. 마치 파일을 추가하고 add를 하기 전과 같다.

이를 활용해서 특정 시점으로 되돌리는 것도 가능하다.

단, 주의할 것은 푸시를 하지 않았기 때문에 최근까지 작성한 소스를 날릴 위험도 있다.

 

revert (악필 주의)

IntelliJ Revert 위치

 

 

reset

 

git reset HEAD

reset: revert랑 비슷한 개념이지만 차이가 있다면, reset은 현재 로컬에 가지고 있는 소스와 대조하여 revert를 시킬 수 있다. 

여기서 '--' 로 붙는 부분은 3가지로 나뉘게 된다. 아무 옵션을 주지 않으면 default값은 mixed이다.

IntelliJ에서는 Reset HEAD 뿐이다

git reset --soft  22cf28(CommitId)

soft는 커밋 내역을 그대로 유지한채 로컬 소스만 reset이 되는 것인데, 말로는 설명하기 어려워 그림을 보아야 이해가 쉬울듯 하다.

이는 git add가 되지 않은 파일들은 건드리지 않고, 소스 변경 이력이 있는 친구들만 해당 커밋했을 때의 소스로 롤백된다.

 

 

git reset --mixed  22cf28(CommitId)

mixed는 해당 브랜치까지는 소스를 변경하고 그 전의 이력은 유지하는 것을 의미한다. 

여기서는 다시 앞의 이력인 git reset ab861d를 통해 소스를 원상복구 시킬 수 있고, commit 전의 파일들도 자동으로 add된다.

 

git reset --hard  22cf28(CommitId)

hard는 로컬의 소스를 무시하고 해당 브랜치의 HEAD까지 push되었던 모든 내역으로 갱신하는 작업이다.

revert와 역할이 같다.

 

fetch

 

git fetch

fetch: 원격 저장소의 최신 이력을 확인한다. remote 브랜치가 생성/삭제 되었는지 상황을 보여주고 보통 checkout과 많이 쓴다.

git fetch && git checkout branchname

 

 

cherry-pick

 

// 1개만 cherry pick
# git cheery-pick 34abb1(CommitId)

// 2개 이상 cherry pick
# git cheery-pick 34abb1(CommitId1) 1c8d26(CommitId2)

cherry-pick: 특정 커밋내역에서 수정된 소스만 로컬로 가져와 덮어쓰기 하는 방법이다.

커밋 당시 소스 수정 이력이 파일 1개 내에서 이루어졌다면 굳이 추천하지는 않는 방법이지만,

여러 개의 소스가 복합적으로 몰려있고 일일히 소스 복사/붙여넣기가 어렵다면 사용하기 좋다.

 

tag

 

tag: 커밋 메시지를 commit 마다 붙일 수 있다면, 태그는 저장소의 소스 버전을 표시하기 위해 사용한다.

태그를 조회하는 명령어는 아래와 같다.

git tag

만약 원하는 태그명으로 검색하고 싶다면 

git tag -l v1.0.*

와 같이 v1.0의 전체 값을 범위로 정할수 있다.

 

tag를 설정하는 법은 두 가지가 있는데 Lightweight / Annotated 가 있다.

Lightweight tag: 특정 커밋내역을 가리키는 포인터의 역할

Annotated tag: 태그 작성자/이메일/날짜/메시지를 저장

 

작성하는 법과 조회하는 법은 아래와 같다.

 

원격 저장소에 올리는 방법은 푸시하는 것과 같다.

# git push origin v1.2.0

 

이상 git의 기본적인 개념들과 협업 시 자주 사용하는 명령어 / 사용 방법등을 확인해보았다.

사실 git은 자주 사용하는 것이 1편에 나와있는 내용이 대부분이고, 소스가 얽히거나 운영상의 이슈때문에 기존으로 돌아가기 위해 사용하는 경우가 대부분이다.

 

나같은 초심자라면 숙지해두면 정말 유용하게 사용하고 있어서 정리를 해보았는데..

시간이 너무 오래 걸렸다.ㅠㅠ

 

항상 느끼는 것이지만 개발은 잘 하는 것도 중요하고 다른 사람이 알아보게 짜는 것도 중요하다.

하지만 팀 프로젝트에서는 서로 간의 의사소통을 확실하게 해서 효율적으로 코드를 분담해서 작성하는 것이 베스트라고 생각한다.

 

참조: https://backlog.com/git-tutorial/kr/stepup/stepup3_2.html