Git의 기본

Git이란 소스코드를 효과적으로 관리하기 위해 개발된 '분산형 버전 관리 시스템'입니다.

👀 원래는 Linux 소스코드를 관리할 목적으로 개발 되었습니다.

장점

• 파일이 변경 이력 별로 구분되어 저장됨
  👉 비슷한 파일이라도 실제 내용 일부 문구가 서로 다르면 다른 파일로 인식하기 때문에 파일을 변경 사항 별로 구분해 저장할 수 있습니다.

원격 저장소와 로컬 저장소

• 원격 저장소(Remote Repository): 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소입니다.
• 로컬 저장소(Local Repository): 내 PC에 파일이 저장되는 개인 전용 저장소입니다.

❗ 평소에는 내 PC의 로컬 저장소에서 작업하다가 작업한 내용을 공개하고 싶을 때에 원격 저장소에 업로드
👉 물론 원격 저장소에서 다른 사람이 작업한 파일을 로컬 저장소로 가져올 수도 있습니다.

저장소 만드는 방법

• 아예 새로운 저장소 만들기
• 이미 만들어진 원격 저장소를 로컬 저장소로 복사하기

커밋

파일 및 폴더의 추가/변경 사항을 저장소에 기록하는 것

💡 커밋은 작업 트리에 있는 변경 내용을 스테이징에 올리는 것을 의미함

👉 커밋 버튼을 누르면 이전 커밋 상태부터 현재 상태까지의 변경 이력이 기록된 커밋(혹은 리비전)이 만들어집니다.

❗ revision이란 특정 Git object를 가리킬 수 있는 표현식을 의미한다.
ex) HEAD~2, master, a8dd808db6d87a1d809b1a223e08ab69602b2d3a, HEAD:test.txt 등이 모두 “revision”이다.

🌱 출처 : https://blog.npcode.com/2012/09/20/git%EC%9D%98-revision%EC%97%90-%EB%8C%80%ED%95%B4/

작업 트리(Work tree)와 스테이징(stage)

Git 에서는 우리가 흔히 말하는 폴더를 '작업 트리'(Work Tree)라고 부릅니다.
커밋을 실행하기 전의 저장소와 작업 트리 사이에 존재하는 공간을 '스테이징'이라고 합니다.

💡 스테이징 = 인덱스
작업 트리 = 변경 이력

❗ 인덱스란 공간(가상이지만요!)이 중간에 있는 덕분에 작업 트리 안에 있는 커밋이 필요 없는 파일들을 커밋에 포함하지 않을 수 있고, 파일에서 내가 원하는 일부 변경 사항만 스테이징에 등록해 커밋할 수 있습니다.

---

저장소 공유

원격 저장소에 푸시(Push)하기

웹 상의 원격 저장소로 변경된 파일을 업로드하는 것을 Git에서는 푸시(Push)라고 합니다.

👉 push 를 실행하면, 원격 저장소에 내 변경 이력이 업로드되어, 원격 저장소와 로컬 저장소가 동일한 상태가 됩니다.

원격 저장소 복제(Clone)하기

클론(Clone)이란 원격 저장소의 내용을 통째로 다운로드하는 것을 말합니다.

👉 복제한 저장소를 다른 PC에서 로컬 저장소로 사용할 수 있게 됩니다.

💡 변경 이력도 함께 로컬 저장소에 복제되어 오므로, 원래 원격 저장소와 똑같이 이력을 참조하고 커밋을 진행할 수 있습니다.

원격 저장소에서 풀(Pull)해오기

다른 사람이 원격 저장소에 올려놓은(Push) 변경 내용을 내 로컬 저장소에도 적용(Pull)하는 것

👉 pull 을 실행하면, 원격 저장소에서 최신 변경 이력을 다운로드하여 내 로컬 저장소에 그 내용을 적용합니다.

커밋 위치

• origin/master
  : 원격 저장소 「origin」의 브랜치인 「master」의 위치를 나타내고 있습니다.
• origin/HEAD
  : 원격 저장소 「origin」을 복제해 올 때 다운로드되는 커밋의 위치를 나타내고 있습니다.
  👉 일반적으로 「origin/master」와 동일한 위치를 가리킵니다.
• master
  로컬 저장소 브랜치인 「master」의 위치를 나타내고 있습니다.

변경 이력의 통합(Merge)

변경 이력 병합(Merge)하기

❗ 만약 병합하지 않은 채로 이력을 덮어쓰게 되면 다른 사람이 push 한 업데이트 내역이 사라져 버림

💡 Git에 변경한 부분을 자동으로 통합해주는 기능이 있지만, 아닌 경우에는 충돌 부분을 수정해야함

---

브랜치(Branch)

브랜치란?

여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없습니다.

👉 이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 바로 '브랜치(Branch)' 입니다.

master 브랜치

저장소를 처음 만들면, Git은 바로 'master'라는 이름의 브랜치를 만들어 둡니다.

이 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(커밋, Commit)하는 것은 모두 'master' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 됩니다.

'master'가 아닌 또 다른 새로운 브랜치를 만들어서 '이제부터 이 브랜치를 사용할거야!'라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어 집니다.

브랜치 만들기

통합 브랜치(Integration Branch)

통합 브랜치란 언제든지 배포할 수 있는 버전을 만들 수 있어야 하는 브랜치 입니다.

👉 그렇기 때문에 늘 안정적인 상태를 유지하는 것이 중요합니다.

📌 '안정적인 상태'란 현재 작업 중인 소스코드가 모바일에서 동작하는 어플리케이션을 개발하기 위한 것이라면, '그 어플리케이션의 모든 기능이 정상적으로 동작하는 상태'를 의미합니다.

💡 일반적으로 저장소를 처음 만들었을 때에 생기는 'master' 브랜치를 통합 브랜치로 사용합니다.

토픽 브랜치(Topic Branch)

토픽 브랜치란, 기능 추가나 버그 수정과 같은 단위 작업을 위한 브랜치 입니다.

👉 여러 개의 작업을 동시에 진행할 때에는, 그 수만큼 토픽 브랜치를 생성할 수 있습니다.

✔ 토픽 브랜치는 보통 통합 브랜치로부터 만들어 내며, 토픽 브랜치에서 특정 작업이 완료되면 다시 통합 브랜치에 병합하는 방식으로 진행됩니다. 이러한 토픽 브랜치는 '피처 브랜치(Feature branch)' 라고 부르기도 합니다.

브랜치 전환하기

현재 선택된 브랜치가 아닌 다른 브랜치에서 작업하고 싶을 때에는, '체크아웃(checkout)' 명령어를 실행하여 원하는 브랜치로 전환할 수 있습니다.

💡 체크아웃을 실행하면, 우선 브랜치 안에 있는 마지막 커밋 내용이 작업 트리(변경 이력)에 펼쳐집니다. 브랜치가 전환 되었으므로 이 후에 실행한 커밋은 전환한 브랜치에 추가됩니다.

수정 이력 커밋하는 과정

❗ 예를 들어, develop에서 idx1.js를 수정한 경우,

1) idx1.js는 변경 이력(work tree)에 추가되게 된다.
2) idx1.js를 커밋하고 싶은 경우, 변경 이력에서 idx1.js를 스테이징 상태로 만든다.
👉 git add idx1.js
3) 스테이징에 올린 해당 파일을 커밋하면, 성공적으로 커밋이 완료된다.

✔ 만약, 커밋 전 다른 브랜치로 checkout하는 경우 코드가 많이 다른경우에는 충돌이 발생하기 때문에 checkout에 실패할 수 있다.
👉 단, 선택된 브랜치의 부모 브랜치인 경우에는 가능하다.

HEAD

'HEAD' 란 현재 사용 중인 브랜치의 선두 부분을 나타내는 이름입니다.

👉 기본적으로는 'master'의 선두 부분을 나타냅니다. 'HEAD' 를 이동하면, 사용하는 브랜치가 변경됩니다.

커밋 위치 명명하는 법

커밋을 지정할 때, '~(틸드, 물결기호)'와 '^(캐럿, 삽입기호)'을 사용하여 현재 커밋으로부터 특정 커밋의 위치를 가리킬 수 있습니다.

이 때 자주 사용하는 것이 'HEAD' 로서, '~(틸드)'와 숫자를 'HEAD' 뒤에 붙여 몇 세대 앞의 커밋을 가리킬 수 있습니다. '^(캐럿)'은, 브랜치 병합에서 원본이 여럿 있는 경우 몇 번째 원본인지를 지정할 수 있습니다.

STASH

커밋하지 않은 변경 내용이나 새롭게 추가한 파일이 스테이징과 작업 트리에 남아 있는 채로 다른 브랜치로 전환(checkout)하면, 그 변경 내용은 기존 브랜치가 아닌 전환된 브랜치에서 커밋할 수 있습니다.

단, 커밋 가능한 변경 내용 중에 전환된 브랜치에서도 한 차례 변경이 되어 있는 경우에는 체크아웃에 실패할 수 있습니다. 이 경우 1)이전 브랜치에서 커밋하지 않은 변경 내용을 커밋하거나, 2)stash 를 이용해 일시적으로 변경 내용을 다른 곳에 저장하여 충돌을 피하게 한 뒤 체크아웃을 해야 합니다.

stash 란, 파일의 변경 내용을 일시적으로 기록해두는 영역입니다.

👉 stash 를 사용하여 작업 트리와 인덱스 내에서 아직 커밋하지 않은 변경을 일시적으로 저장해 둘 수 있습니다. 이 stash 에 저장된 변경 내용은 나중에 다시 불러와 원래의 브랜치나 다른 브랜치에 커밋할 수 있습니다.

브랜치 통합하기

merge

merge 를 사용하면, 여러 개의 브랜치를 하나로 모을 수 있습니다.

1) 경우1 - 'fast-forward(빨리 감기) 병합'

👉 병합할 대상(bugfix)이 병합되어야할 대상(master)의 데이터를 모두 포함하고 있는 경우

2) 경우2 - 'merge commit(병합 커밋)'

merge commit = non fast-forward 병합

👉 병합할 대상(bugfix)이 병합되어야할 대상(master)의 데이터가 서로 다른 경우

❗ 이 경우에는 'master' 브랜치 내의 변경 내용과 'bugfix' 브랜치 내의 변경 내용을 하나로 통합할 필요가 있습니다.

💡 3) 경우3 - fast-forward 병합이 가능한 경우에 merge commit(non fast-forward 병합)을 진행하는 경우

👉 'non fast-forward 병합'을 실행하면, 브랜치가 그대로 남기 때문에 그 브랜치로 실행한 작업 확인 및 브랜치 관리 면에서 더 유용할 수 있습니다.

rebase

1) 'non fast-forward 병합' 방식으로 진행되는 시나리오가 있을 때

2) 우선 'bugfix' 브랜치를 'master' 브랜치에 rebase 하면, 'bugfix' 브랜치의 이력이 'master' 브랜치 뒤로 이동하게 됩니다.
👉 때문에 그림과 같이 이력이 하나의 줄기로 이어지게 됩니다.

3) 'rebase'만 하면 아래 그림에서와 같이, 'master'의 위치는 그대로 유지됩니다.

4) 'master' 브랜치의 위치를 변경하기 위해서는 'master' 브랜치에서 'bugfix' 브랜치를 fast-foward(빨리감기) 병합 하면 됩니다.

merge와 rebase의 공통점과 차이점

공통점

• 통합 브랜치에 토픽 브랜치를 통합하고자 하는 목적을 가짐

차이점

• merge
  - 변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해짐.
  
• rebase
  - 이력은 단순해지지만, 원래의 커밋 이력이 변경됨.
  ❗ 정확한 이력을 남겨야 할 필요가 있을 경우에는 사용하면 안됨.
  

merge 와 rebase을 팀 운용 방침에 따라 구별

📌 예를 들어, 이력을 하나로 모두 모아서 처리하도록 운용한다고 치면 아래와 같이 구별해 사용할 수 있습니다.

• 토픽 브랜치에 통합 브랜치의 최신 코드를 적용할 경우
  👉 rebase 를 사용
• 통합 브랜치에 토픽 브랜치를 불러올 경우
  👉 우선 rebase 를 한 후 merge

컬럼 「A successful Git branching model」- 성공적인 Git 브랜칭 모델

메인 브랜치(Main branch)

master

'master' 브랜치에서는, 배포 가능한 상태만을 관리합니다.

👉 커밋할 때에는 태그를 사용하여 배포 번호를 기록합니다.

develop

'develop' 브랜치는 앞서 설명한 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행합니다.

피처 브랜치(Feature branch) 또는 토픽 브랜치(Topic branch)

피처 브랜치는, 앞서 설명한 토픽 브랜치 역할을 담당합니다.

• 이 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때에 'develop' 브랜치로부터 분기합니다.
• 피처 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 원격으로는 관리하지 않습니다.
• 개발이 완료되면 'develop' 브랜치로 병합하여 다른 사람들과 공유합니다.

릴리스 브랜치(Release branch)

릴리즈 브랜치에서는 버그를 수정하거나 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작하는지 확인합니다.

• 릴리즈 브랜치의 이름은 관례적으로 브랜치 이름 앞에 'release-' 를 붙입니다.

  • 이 때, 다음 번 릴리즈를 위한 개발 작업은 'develop' 브랜치 에서 계속 진행해 나가면 됩니다.

• 릴리즈 브랜치에서는 릴리즈를 위한 최종적인 버그 수정 등의 개발을 수행합니다.

  • 모든 준비를 마치고 배포 가능한 상태가 되면 'master' 브랜치로 병합시키고, 병합한 커밋에 릴리즈 번호 태그를 추가합니다.

• 릴리즈 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 'develop' 브랜치에도 적용해 주어야 합니다. 그러므로 배포 완료 후 'develop' 브랜치에 대해서도 병합 작업을 수행합니다.

핫픽스 브랜치(Hotfix branch)

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, 'master' 브랜치에서 분기하는 브랜치입니다.

• 관례적으로 브랜치 이름 앞에 'hotfix-'를 붙입니다.

📌 예를 들어, 'develop' 브랜치에서 개발을 한창 진행하고 있는 도중에 이전에 배포한 소스코드에 아주 큰 버그가 발견되는 경우를 생각해 보세요.

문제가 되는 부분을 빠르게 수정해서 안정적으로 다시 배포해야 하는 상황입니다. 'develop' 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어렵습니다.

👉 그렇기 때문에 바로 배포가 가능한 'master' 브랜치에서 직접 브랜치를 만들어 필요한 부분 만을 수정한 후 다시 'master'브랜치에 병합하여 이를 배포하려고 하는 것이죠.

이 때 만든 핫픽스 브랜치에서의 변경 사항은 'develop' 브랜치에도 병합하여 문제가 되는 부분을 처리해 주어야 합니다.

---

원격 저장소

pull(가져와 병합하기)

fetch + merge = pull
👉 원격 저장소의 데이터를 로컬에 가져와 병합하기

❗ 보통 자동으로 merge가 실행되지만, 충돌이 난 경우, 수동으로 해결한 다음 직접 commit해야함

fetch(가져오기)

pull 을 실행하면, 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행하게 됩니다.

💡 그러나 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우에는 fetch 명령어를 사용할 수 있습니다.

❗ fetch 를 실행하면, 원격 저장소의 최신 이력을 확인할 수 있습니다. 이 때 가져온 최신 커밋 이력은 이름 없는 브랜치로 로컬에 가져오게 됩니다. 이 브랜치는 'FETCH_HEAD'의 이름으로 체크아웃 할 수도 있습니다.

push(밀어넣기)

💡 로컬 저장소에서 원격 저장소로 push(밀어넣기) 할 때에는, push 한 브랜치가 'fast-forward 병합' 방식으로 처리 되도록 지정해 둘 필요가 있습니다.

태그(Tag)

태그란, 커밋을 참조하기 쉽도록 알기 쉬운 이름을 붙이는 것을 말합니다.

👉 한 번 붙인 태그는 브랜치처럼 위치가 이동하지 않고 고정됩니다.

일반 태그(Lightweight tag)

• 이름만 붙일 수 있어요

주석 태그(Annotated tag)

• 이름을 붙일 수 있어요
• 태그에 대한 설명도 포함할 수 있어요
• 서명도 넣을 수 있어요
• 이 태그를 만든 사람의 이름, 이메일과 태그를 만든 날짜 정보도 포함시킬 수 있어요

사용 용도

• 보통 '릴리스 브랜치(Release branch)'에서는 주석 태그를 사용하여 설명이나 서명을 넣은 보다 상세한 정보를 포함하는 태그를 사용
• 로컬에서 일시적으로 사용하는 '토픽 브랜치(Topic branch)'에서는 이름만 만들어 붙이는 태그를 사용

💡 태그 이름을 지정하여 checkout 하거나 reset 함으로써, 간단하게 과거의 특정 상태로 되돌릴 수 있답니다!

Commit 변경하기

commit 수정하기

--amend 옵션을 지정하여 커밋 수행시, 같은 브랜치 상에서 이전 커밋 수정 가능
👉 git commit --amend

📌 예시

• 누락된 파일을 새로 추가하거나 기존의 파일을 업데이트 해야할 때
• 이전 커밋의 설명을 변경하고 싶을 때

commit 지우기

revert 명령어를 사용해 지울 수 있지만, 안전을 고려해 해당 부분을 지우는 커밋을 추가하는 것이 옳다
👉 git revert HEAD
// HEAD는 지울 commit 위치

커밋을 버리고 특정 버전으로 다시 되돌아가기

reset 명령어를 이용하면 더 이상 필요 없어진 커밋들을 버릴 수 있습니다.
👉 git reset --hard HEAD~~

💡 명령어 실행 시 어떤 모드로 실행할 지 지정하여 'HEAD' 위치와 인덱스, 작업 트리 내용을 함께 되돌릴지 여부를 선택할 수 있습니다.

git reset --hard ORIG_HEAD

👉 reset 전의 커밋은 'ORIG_HEAD'라는 이름으로 참조할 수 있습니다. 실수로 reset 을 한 경우에는, 'ORIG_HEAD'로 reset 하여 reset 실행 전의 상태로 되돌릴 수 있습니다.

📌 예시

• 커밋만 되돌리고 싶을 때 (soft)
• 변경한 인덱스의 상태를 원래대로 되돌리고 싶을 때 (mixed)
• 최근의 커밋을 완전히 버리고 이전의 상태로 되돌리고 싶을 때 (hard)

다른 브랜치로부터 특정 커밋을 가져와서 내 브랜치에 넣기

cherry-pick 을 이용하면 다른 브랜치에서 지정한 커밋을 복사하여 현재 브랜치로 가져올 수 있습니다.
👉 git cherry-pick [커밋번호]
ex) git cherry-pick 99daed2

❗ commit 번호는 git log 명령어로 확인할 수 있음

📌 예시

• 특정 브랜치에 잘못 추가한 커밋을 올바른 브랜치로 옮기려고 할 때
• 다른 브랜치의 커밋을 현재 브랜치에도 추가하고 싶을 때

커밋 이력 편집하기

rebase 명령어에 'i' 옵션을 지정하면 커밋을 다시 쓰거나 다른 커밋과 바꿔 넣을 수 있으며 특정 위치의 커밋을 삭제하거나 여러 커밋을 하나로 통합하는 작업을 할 수 있습니다.
👉 git rebase -i [통합할 과거의 커밋 위치]
ex1) 커밋 이력 통합하는 경우
git rebase -i HEAD~~
ex2) 커밋 이력 수정 후, 저장하는 경우
git rebase -i HEAD~~
$ git add sample.txt
$ git commit --amend
$ git rebase --continue // 커밋 작업이 종료했다는 것을 알리기 위한 명령

❗ 이때, 다른 커밋에서 충돌이 발생하는 경우, 충돌 부분 수정후 add와 rebase --continue를 실행하면 됨

❗ rebase 작업을 중지하고 싶은 경우, rebase에 --abort 옵션을 지정하여 실행하면 됩니다.

💡 rebase 전의 커밋은 'ORIG_HEAD'라는 이름으로 남아 있습니다. 만약 rebase 한 후 원래대로 되돌리고자 하는 경우에는 'git reset --hard ORIG_HEAD'을 실행하여 rebase 전의 상태로 되돌릴 수 있습니다

📌 예시

• push 하기 전에 이전의 커밋 내용을 정리하고자 할 때
• 그룹으로 묶을 수 있는 커밋들을 알기 쉽게 하나로 통합하려고 할 때
• 이전 커밋에 누락된 파일들을 나중에 추가하고자 할 때

브랜치상의 커밋을 하나로 모아 병합한다

병합(merge) 할 때, '--squash' 옵션을 지정하여 브랜치를 병합하면 해당 브랜치의 커밋 전체를 통합한 커밋이 추가됩니다.
👉 git merge --squash [브랜치명]
ex) git merge --squash issue1

📌 예시

• 토픽 브랜치 안의 커밋을 한꺼번에 모아서 통합 브랜치에 병합하고자 할 때

🌱 출처 : https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html