🐱 Git과 친해지기

"깃? 깃허브는 또 뭐야..? 우리 친해질 수 있는거니?😂"

이번 우테코 5기 프리코스 1주차의 미션 목표 중 하나는 바로

Git과 Github에 익숙해지는 것 이였다.

실제로 이번 프리코스 4주동안
git과 github를 이용하여 미션 과제를 제출해야 했다.

그 동안 Git을 무의식적으로만 삽질해가며
add하고 commit하고 push하면서 사용했던 순간이 많았는데,
이참에 Git에 대해 본격적으로 파고 들고, 친해져 보도록 하자.

---

🚂 프로젝트 진행 순서

Git에 대해 파고 들기 전에,
Git과 Github를 통해 프로젝트를 제출하는 순서에 대해 먼저 알아보자.

🍴 1. 프로젝트를 자신의 계정으로 fork 하기

fork는 프로젝트의 저장소를 자신의 계정으로 복사하는 기능입니다.

앞으로 모든 미션은 자신의 계정 아래에 있는 저장소를 활용해 진행해주세요.

Github에서 미션 저장소의 링크를 타고 들어가면,
우측 상단에 fork 버튼을 볼 수 있다.
이 버튼을 클릭해 fork하면 내 github 저장소에 복사되어 추가된다.

fork는 단어적으로도 무언가를 찍먹한다는 느낌을 준다.
말 그대로 프로젝트 저장소를 찍어서 내 저장소 접시 위에 올려놓는 느낌이다.

---

👥 2. fork한 저장소를 로컬에 clone하기

fork를 완료했다면 내 저장소에 프로젝트 저장소가 복사되어 있을 것이다.

프로젝트를 작업하기 위해선 내 로컬pc(본인의 컴퓨터)로
clone(복사)해놓는 과정이 또 필요하다.

fork가 저장소에 복사를 해놓는 것 이였다면,
clone은 저장소에 있는 것을 로컬pc로 복사해놓는 느낌이다.

fork한 저장소는 github.com에 존재하기 때문에 소스 코드를 추가하고, 수정하는 작업을 할 수 없습니다.

clone 명령은 github.com에 존재하는 이 저장소를 자신의 노트북 또는 PC로 복사하는 과정입니다.

터미널에서 다음과 같은 명령을 입력한다.

git clone https://github.com/{본인_아이디}/{저장소 아이디}.git
ex) git clone https://github.com/woowacourse/java-baseball.git

// clone한 폴더로 이동하는 방법
cd {저장소 아이디}
ex) cd java-baseball

클론을 완료하면 내 로컬pc에 똑같이 복사된 것을 확인할 수 있다.

---

👩‍🔧 3. 기능 구현을 위한 브랜치(작업공간) 생성

git은 서로 다른 작업을 하기 위한 별도의 공간을 만들기 위해
브랜치를 생성할 수 있습니다.

터미널에서 다음 명령을 입력해 브랜치를 생성합니다.

git checkout -b {본인 아이디}
ex) git checkout -b javajigi

브랜치를 생성한 후의 상태는 다음과 같다.

브랜치를 생성하게 되면 내 로컬pc에 새로운 브랜치 작업공간이 만들어지게 된다.

---

👩‍💻 4. 통합 개발 환경(IDE)으로 가져온 뒤, 기능 구현

미션 진행을 위해 clone한 저장소를
자신이 사용하고 있는 통합 개발 환경(IDE)으로 가져옵니다.

자신이 사용하는 도구(VS code나 IntelliJ 등등)를 사용해서 진행해주세요.

1. Visual Studio Code를 시작
2. Open Project (앞에서 clone한 폴더를 선택합니다.)
3. 미션 요구사항을 파악해 기능을 구현합니다.

---

📩 5. 기능 구현 후 add, commit, push 하기

기능 구현을 완료한 후 로컬 저장소에 변경된 부분을 반영하기 위해 add, commit 명령을 사용합니다.

git status // 변경된 파일 확인
git add -A(또는 .) // 변경된 전체 파일을 한번에 반영
git commit -m "메시지" // 작업한 내용을 메시지에 기록

기능 구현을 완료하고 add, commit 명령을 실행한 후의 상태는 아래와 같습니다.

내 로컬pc에 기능구현을 완료한 커밋파일들이 추가된 것을 볼 수 있다.

그렇다면 이제 나의 원격 저장소에 commit된 파일들을 올려줘야한다.
로컬에서 commit 명령을 실행하면 로컬 저장소에만 반영되고,
원격 github.com의 저장소에는 반영되지 않습니다.

github.com의 저장소에도 동일하게 반영하기 위해 push 명령어를 사용합니다.

git push origin 브랜치이름
ex) git push origin javajigi

push 명령을 실행한 후의 상태는 아래와 같습니다.

push를 하게되면 내 Github에 만들었던 브랜치가 올라온 모습을 볼 수 있고,
그 안에 commit했던 파일들이 기록 된 모습을 확인 할 수 있다.

---

📮 6. github 서비스에서 Pull Request를 보낸다.

Pull Request는 github에서 제공하는 기능으로 코드리뷰 요청을 보낼 때 사용합니다.

Pull Request는 original 저장소(woowacourse의 저장소)의 main 브랜치와
앞 단계에서 생성한 브랜치 이름(앞 단계의 예에서는 javajigi)을 기준으로 합니다.

ex) 미션을 진행한 javajigi/java-baseball javajigi 브랜치 => woowacourse/java-baseball main
브랜치로 Pull Request를 보낸다.

1. 브라우저에서 github 저장소에 접근
2. 브랜치를 작업 브랜치로 변경(앞 단계의 예에서는 javajigi)
3. 브랜치 오른쪽에 있는 "New pull request" 버튼 클릭
4. Pull Request 제목은 [$미션제목] $이름 미션 제출합니다. 형식으로 작성해주세요.
5. 현재 미션에서 작업한 내용을 입력하고 "Create pull request" 버튼을 클릭해 Pull Request를 보내주세요.

풀리퀘스트까지 모두 마치면
미션저장소에 내가 작업했던 브랜치와 커밋내용들이 PR된 모습을 확인할 수 있다.

여기서 주의해야 될 점은,

1. Pull Request를 보내기 전 브랜치를 확인한다.
기능 구현 작업을 fork된 Repository의 main branch가 아닌,
기능 구현을 위해 새로 만든 브랜치에서 작업한 후 PR을 보낸다.

2. PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다.
PR을 이미 한 번 보냈다면, 새로운 PR을 생성할 필요가 없다.
수정이 필요하다면 추가 커밋을 하면 자동으로 반영된다.

---

🚣 upstream 과 origin

만약 upstream, origin이 무슨 말인지 모르겠다면 아래의 내용들이 도움을 줄 것이다.

upstream은 상류, downstream은 하류를 나타낸다.

이 용어들은 굉장히 상대적인 개념이다.
절대적인 upstream과 downstream은 없다.

관계의 흐름을 나타낼 때 이를 명확하게 표현해주기 위해서
생겨난 개념이라고 보면 된다.

아래의 그림을 추가로 살펴보자.

보통 저장소 생성하고 remote add하고 origin을 붙여주거나,
pull을 하거나 push를 사용할때 origin이라는 키워드를 붙인다.

remote는 "원격" , "원격으로 관리하는" 이라고 생각해주면 된다.

원격저장소의 미션을 진행하기 위해선 가장 먼저 clone을 하며 시작하게 된다.
clone이 완료가 된 후 git remote -v 를 입력해보면
자동적으로 원격 저장소가 등록이 되는 것을 확인할 수 있다.

git remote add origin 내 원격저장소 주소

git push -u origin main
//내 main 브랜치로 push한다.

이때 origin은 말 그대로 원천이라는 의미이다.

물이 흐르는 방향이 있으면 그 물의 원천(origin)이 있다고 생각하면 된다.
내 원격 저장소를 origin이라는 원천으로 이름을 부여해서
관리하겠다는 명령을 내린 것이다.

그렇다면 -u 는 무슨 말일까?

--set-upstream의 약자로 쓰는 말

앞서 얘기했듯이 upstream, downstream은 상대적인 개념이다.
이때 상류와 하류 관계를 설정해주기 위해서 -u 를 써서 관계를 설정 해주는 것이다.

remote origin이라고 사용하는 것은
저장소를 만들면, 보통 그 원천보다 더 상위의 흐름(상류)가 생기는게 많이 발생하지 않기 때문에 origin 이라는 이름으로 표현하고 upstream은 정말 개념적인 의미로만 세팅하는 것이다.

하지만, 위 그림을 프로젝트를 진행하는 상황이라고 본다면
remote upstream -> remote origin -> local
프로젝트 저장소 -> 나의 저장소 -> 나의 로컬
이런 흐름이 된다.

처음 상류는 fork한 레파지토리 저장소,
가운데는 나의 github 저장소,
마지막은 나의 로컬pc가 된다.

즉, origin을 기준으로 했을때 더 위로 가는게 upstream개념이 된다.

상류에서 하류로 흐르면서
점차 여러 갈래의 줄기로 흘러간다고 생각해주면 좋다.

그리고 git clone을 하게 되면
이미 origin을 알고있기 때문에 자동으로 상하관계가 생성이 된다.

---

🕵 git 명령어와 객체들

Q. 혹시 add, commit, puch를 기계적으로 반복하고 있나요?🤔

만약 그렇다면
터미널의 내장 객체인 Git을 도구로서 잘 사용하는 방법을 고민해보자.

가장 추천해주고 싶은 방법은
git 안의 사용설명이나 도움말 같은 기능을 이용하는 것이다.

git에서 기본적으로 제공해주는 것들만 잘 살펴보아도 도움을 많이 받을수있다.

앞서 프로젝트를 진행하며 사용했던 Git 명령어들과
그 외 다양한 객체들을 살펴보자.

Git 명령어를 사용하는 방법은 여러 가지가 있다.

• 명령프롬프트(CMD)
• 통합 개발 환경(IDE)에 내장되어 있는 터미널
• Git을 설치할 때 딸려오는 Git Bash, Git GUI

무엇을 사용하든 명령어는 같으니 너무 걱정하지 않아도 된다.

---

📌 git init

새로운 저장소 만들기

위에서는 프로젝트를 진행할때 이미 생성된 미션 저장소를 fork하는 방식으로 진행했지만,
아예 새로운 저장소를 만드는 방법도 있다.

먼저 프로젝트 폴더를 하나 만들고, cd 명령어를 이용해서 프로젝트 폴더 위치로 이동한다.

cd 폴더경로

그리고 git init을 쳐봅시다.

git init

새로운 git 저장소가 만들어집니다.

Q. 현재 디렉토리에서 git init을 입력하면 현재 디렉토리가 로컬 저장소가 된다.

정답은 yes 이다.

git의 로컬저장소는 .git 안에 있다.
.git안의 구조를 보면 재밌는데

tree .git/ 이라는 명령어를 쓰면 구조를 살펴볼 수 있다.

git init을 하면 여러 메세지로 표시를 해준다.
가능하면 이 피드백 주는 메세지들을 이해해 보려한 다음
찾아보면 훨씬 더 git을 도구로서 잘 사용할 수 있게 된다.

명령어에 대해 궁금하다면
git init -help 를 치면 설명이 잘 나와있다.

명령어를 잘 쓸 수 있는 아이디어를 얻기에도 좋다.

---

📌 git clone

저장소 받아오기

로컬 저장소를 복제(clone)하려면 아래 명령을 실행하세요.

git clone /로컬/저장소/경로

원격 서버의 저장소를 복제하려면 아래 명령을 실행하세요.

git clone 사용자명@호스트:/원격/저장소/경로

프로젝트 진행시 다른 원격 저장소를 복제해올 땐 아래 명령을 실행하였다.

git clone https://github.com/{본인_아이디}/{저장소 아이디}.git
ex) git clone https://github.com/woowacourse/java-baseball.git

---

📌 git 작업 흐름 tree 객체

로컬 저장소는 git이 관리하는 세 그루의 나무로 구성되있다.

tree는 blob를 묶어서 관리한다.(디렉토리 구조와 유사)
blob은 git의 파일 객체를 의미한다.
기본적으로 git에는 blob객체(파일)이 있다.

첫번째 나무 작업 디렉토리(working directory) 는 실제 파일들로 이루어져 있다.
두번째 나무 인덱스(Index)는 준비영역(staging area)의 역할을 한다.
마지막 나무 HEAD는 최종 확정본(commit)을 나타낸다.

---

📌 git status

현재 상태 확인

git status

명령어를 입력하면 현재 git 변경되거나 추가/삭제 된 현재 상태를 확인할 수 있다.
git status를 치면 git에게 인사를 하여 안부를 묻는 것 같은 느낌을 준다.

---

📌 git add

변경된 파일 추가하기

add를 비유 하자면 돌(새롭게 변경된 부분)을 든 검댕이들(index)과 같다.

변경된 파일은 아래 명령어로 (인덱스에) 추가 할 수 있다.

//한개의 특정 파일만 추가하고 싶을땐,
git add 파일이름

//한번에 모든 파일을 추가하고 싶을땐,
git add .

이것이 바로 git의 기본 작업 흐름에서 첫단계에 해당된다.

하지만 add을 하는 것은 index(스테이지)에만 올려둔 상태이기 때문에,
commit과 push를 통해 HEAD에 최종적으로 올려 놓아야 한다.

---

📌 git commit, git push

확정(commit), 변경내용 발행(push)

용광로(HEAD)까지 가서 집어넣는것이 commit이라면, 용광로에서 녹이는 것(원격저장소로 반영)이 push이다.

변경 내용을 확정하려면 아래 명령을 내려야 한다.

git commit -m "커밋 메세지 작성"

자, 이제 변경된 파일이 HEAD에 반영됐다.
하지만 아직 로컬에만 저장되었고, 원격 저장소에는 반영이 되지 않았다.

현재의 변경 내용은 아직 로컬 저장소의 HEAD안에 머물고 있다.
이제 이 변경 내용을 원격 저장소로 올려보자.
아래의 명령을 실행하면 된다.

git push origin master
(다른 브랜치로 발행하려면 master 대신 원하는 브랜치 이름으로 바꿔주세요.)

만약 기존에 있던 원격 저장소를 복제한 것이 아니라면,
원격 서버의 주소를 git에게 알려줘야한다.

git remote add origin 원격서버주소

이제 변경 내용을 원격 서버로 발행 할 수 있다.

결국 status, add, commit, push는 순차적 흐름이라는 것을 알 수 있다.

아래에서 commit에 대한 추가적인 내용을 더 알아보자.

commit은 git의 굉장히 중요한 객체이다.

보통 "저장단위 스냅샷을 찍는다"라고 많이 얘기한다.
마지막 변경사항만 딱 사진을 찍은것 처럼 보는게 스냅샷이다.

commit은 작업 디렉토리 스냅샷,
게임에서의 세이브 포인트와 비슷하다고 생각하면 좋다.

게임에서 세이브를 하는 이유는 무엇일까?
부활하기 위해서, 내가 삽질을 하거나 망치거나 했을때 돌아가기 위해서이다.

commit 객체에는 세이브포인트로 돌아가기 위한 정보들이 포함 되야한다.

스테이지(index)의 내용으로 tree 객체를 생성하기 때문에,
commit객체는 tree 객체를 포함하고 있다.

커밋 객체에 저장되는 것은 아래와 같다.

• 최상위 트리 객체의 참조
• 커밋 메세지
• 부모 커밋에 대한 참조

즉, 저장한 단위에 tree+blob+메타정보 등의 정보들이 포함된다.

Q. git add나 commit 명령어를 나눈 이유는 무엇일까?

먼저 하나의 파일을 만들고 git add를 하면 무슨 일이 일어날까?

tree .git을 입력해서 tree구조로 git 디렉토리를 확인해보면
index와 object가 추가되는 것을 볼 수 있다.
git이 관리대상이 되서 파일단위로 파일을 인식하는 것이다.

이후, git commit을 하게 되면 여기서 객체가 2개가 더 생성이 된다.

내가 추적할 객체를 하나 만들면 그 객체가 로컬 저장소에 추가된다.
이것을 commit을 하게 되면 tree객체와 commit객체를 같이 만들어서
총 3개의 객체가 생성 된 것이기 때문이다.

즉 git add를 했을때 생성되는 객체들이 있고,
git commit을 했을때 생성되는 객체들이 있다.

이렇게 상하관계가 생기고
관리하는 입장에서 객체를 생성 해야하는 시점이 다르기 때문에
다른 상황에서 쓰게 되는 것이다.

이런 관점으로 생각해보면
"아..이래서 이런 관계들을 만들고 참조를 하게하고 명령어를 나눠놨구나!" 라고 생각해 볼 수 있게 된다.

Q. 파일의 내용을 수정하고 commit하면 git은 공간효율을 위해 변경사항만 저장한다?

정답은 no 이다.
깃은 절대로 변경사항 만을 저장하지 않는다.(파일을 통체로 저장함)

변경사항을 저장하면 용량이 유리하긴 하지만,
git은 속도적인 측면에서 통채로 저장하는 것이 더 유리하기 때문이다.

각각의 파일들로 하나의 객체로 관리를 하는데
그것들을 매번 다 관리하면 부담되기 때문에
그걸 tree객체가 관리하는 것이고,
그 tree객체를 commit객체가 관리하는 구조이다.

일부러 commit을 reset하거나 없애는게 아닌 이상
git은 굉장히 안전한 도구이다.

---

📌git branch(가지)

Q. 다음중 Git의 객체가 아닌것은?

1. blob
2. commit
3. tree
4. tag
5. branch

정답은 5.branch 이다.

브랜치는 commit 객체들에 대한 참조(레퍼런스)일 뿐이다.

blob : 파일
commit: 저장 단위, tree+blob+메타정보
tree: blob를 묶어서 관리(디렉토리 구조와 유사)
tag: 커밋에 대한 참조이지만 설명이 추가되는 객체
branch : commit 객체들에 대한 참조(레퍼런스)

그래서 브랜치가 뭔가요?

branch는 소프트웨어를 개발할 때
개발자들 간에 동일한 소스코드를 함께 공유하고자 할 때 그때 다르게 사용된다.

👨‍🔧👩‍🔧

여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할때
동시에 다양한 작업을 할 수 있게 만들어 주는 기능이다.

각자 독립적인 작업 영역을 생성하고
그 곳에서 작업 후 원래 버전과 비교해서
새로운 버전을 만들어내는 작업을 할 수 있다.

branch(가지) 만들기/삭제하기

브랜치는 안전하게 격리된 상태에서 무언가를 만들때 사용한다.(안전한 작업공간)
저장소를 새로 만들면 기본으로 master 혹은 main 브랜치가 만들어진다.

이제 다른 브랜치를 이용해서 개발을 진행하고, 나중에 개발이 완료되면
master로 돌아와 병합하면 된다.

브랜치를 생성하려면 무엇을 먼저 해야할까?

• 먼저 터미널을 연다.
• 아래 명령으로 "feature_x"(예시)라는 이름의 브랜치를 만들고 갈아탈수있다.

git branch feature_x(브랜치이름)

//이외에도 checkout이나 switch등으로 생성을 하고 바로 checkout 하는게 가능하다.
git checkout -b feature_x
git switch feature_x

//아래 명령(중 하나)으로 master 가지로 돌아올수있다.
git branch -m master
git checkout master
git switch master

//아래 명령으로 가지를 삭제할 수 있다.
git branch -d feature_x

새로 만든 브랜치를 원격 저장소로 전송하기 전까지는 다른 사람들이 접근할 수 없다.

//새로만든 브랜치로 원격저장소에 전송하기
git push origin feature_x

---

📌 HEAD와 상대참조

앞서 살펴본 branch에는 HEAD라는 숨겨진 녀석이 있다.
HEAD는 현재 checkout 된 commit을 가리킨다.
즉, 현재 작업 중 인 commit이라는 것이다.

HEAD는 항상 작업트리의 최신, 최근 커밋(브랜치 이름)을 가리키고 있다.

작업트리에 변화를 주는 Git 명령어들은 대부분
HEAD를 변경하는 것 부터 시작한다.

이곳을 기준으로 몇 번째 이전 커밋은?(상대참조)

상대참조를 알아두면 정말 유용하다.

주로 caret(캐럿) ^ 과 tilde(틸드) ~ 가 쓰인다.

//아래와 같이 캐럿을 붙이면 한번 이전 커밋으로 돌아가는 것을 볼 수 있다.
git switch HEAD^

캐럿은 붙인 만큼 뒤로 간다.

//2번 뒤로 가기
git switch HEAD^^

이 때 더 유용한 방법이 있다.
바로 틸드 뒤에 숫자를 붙이는 방법이다.
그 숫자만큼 이전 부모 커밋을 찾아가게 된다.

//HEAD로부터 2번째 부모커밋
git switch HEAD~2

이렇게 브랜치가 가리키는 커밋의 위치도 바꿀 수가 있다.

---

📌 git pull, git merge

갱신(pull)과 병합(merge)

"브랜치들 합체 진화!"

만약 다른 브랜치에 있는 변경 내용을 현재 브랜치(예를 들면, main)에 병합하려면?

두 브랜치를 합치는 과정을 깃에서는 merge라는 기능이 도와준다.

기능 브랜치를 main에 merge하는 작업을 진행해보자.

git merge 기능브랜치이름

merge할 때 두 브랜치의 base가 같으면 Fast-forward 할 수 있다.

• Fast-forward

가리키고 있던 commit을 merge할 브랜치의 commit으로 이동시키는 것이
merge의 방법중의 하나인 Fast-forward이다.

최신 정보들을 모두 따라가는 두 브랜치의 base가 같을 때
Fast-forward를 기본적으로 제공한다.

즉 A브랜치에 B브랜치를 merge할때,
B브랜치가 온전히 A브랜치 이후의 commit들을 가리키고 있으면
A브랜치를 B브랜치로 이동하기만 한다라는 것이다.

fast-forward라는 명령어에는 옵션을 제거하지 않으면 항상 fast-forward 동작을 기본적으로 제공한다.

그런데 프로젝트를 로컬 저장소에서 진행하던 도중,
기존 원격 저장소의 코드가 새롭게 갱신 되었다고 가정해보자.😂

실제로 4주차 프리코스 도중 테스트 코드가 새롭게 바뀌게 되었는데,
이럴때는 작업하고 있던 내 로컬 저장소도 원격 저장소에 맞춰서 갱신을 해주어야 한다.

로컬 저장소를 원격 저장소에 맞춰 갱신하려면 아래명령을 실행하면 된다.

git pull

이렇게 하면 원격 저장소의 변경 내용이 로컬 작업 디렉토리에 받아지고(fetch),
병합(merge)된다.

첫번째 명령이든 두번째 명령이든, git은 자동으로 변경 내용을 병합하려고 시도한다.

• 3-way-merge

위 메일의 상황처럼 기존 브랜치의 base가 달라졌다면
새로 만든 브랜치에 upstream/main의 변경점을 반영해야한다.

upstream/main의 변경점을 현재 작업중인 로컬 기능 브랜치에 적용을 해야되기 때문에 기능브랜치에 이 픽스된 commit을 합쳐야 한다.

따라서 기능브랜치로 가서 upstream에 있는 정보들을 모두 merge해서 합쳐줘야 한다.

merge할 때 base가 다르면 merge commit을 생성하여 auto merge해야한다.

fast-forward의 조건인 두 브랜치의 베이스가 같은 것이 아니기 때문에
git이 별도의 최적 공통 조상을 자동으로 찾는 auto merge로 commit을
하나 생성하고, 해당 commit을 가리키도록 이동해야 한다.

Github에서 제공하는 pull request는
조금 다르게 동작하는 세 가지 merge 방법을 따로 제공을 한다.
이 세가지 동작을 지금부터 하나하나 알아보자.

pull request 시에는 각각의 merge방법에 대한 장점과 단점을 파악해서
현재 팀에서 가장 적절하다고 생각하는 merge 방법을 선택하는 것이 좋다.

1. Create merge commit

베이스 브랜치가 같더라도 fast-forward를 진행하는 것이 아니라
하나의 merge commit 을 생성해서 merge를 진행하는 방법이다.

이렇게 진행하게 될 경우
기능 구현을 할때 사용했던 commit들이 하나하나 살아있어
이를 사용할 여지를 남김과 동시에 만든 기능에 대해서 merge 분기점이 생김으로 어떤 기능을 만들어 main에 merge했는지 가독성이 좋아진다.

2. Squash and merge

하나의 merge commit을 생성해서 해당 commit을 바라보게 하는데
피처에서 작업했던 모든 commit을 하나의 commit으로 통합해서 merge하는 작업이다.

이렇게 될 경우
commit이 너무 길어 여러개의 기능 구현이 있을때 알아보기 힘든 점을
특정 기능에 대한 commit을 하나만 두어서 이전보다는 어떤 기능을 작업했는지 가독성이 더 좋아진다.

pull request 각각에 대한 commit을 하나를 남기고
해당 commit이 이름으로 작성이 되어 있기 때문에
PR 단위마다 commit이 작성되어 누가 계획을 완료했는지 가독성이 높아진 모습이 된다.

3. Rebase and merge

간단히 이야기하면 베이스를 다시 조정을 하는,
즉 피처에서 작업했던 commit 들을 모두 현재 main 브랜치에서 최상단에 복사 붙여넣기 하는 작업이다.

다만 이렇게 될 경우 commit이 많을 때 한 줄로 모든 commit이 저장되어 오히려 더 난잡해 보일 수 있다.

---

📌 conflicts (충돌)

merge는 항상 성공하는게 아니라 가끔 충돌(conflicts)이 일어나기도 한다.

이렇게 conflict(충돌)이 발생할 경우 개발자가 직접 처리해야 한다.

git이 알려주는 파일의 충돌 부분을 우리가 직접 수정해서 병합이 가능하도록 해야한다.

merge를 계속 진행하기 위해서는 해당 부분을 직접 수정하거나 IDE에서 제공하는 자동 수정을 진행하면 된다.

merge를 할때 같은 부분을 수정했다면 충돌이 발생하기 때문에
두 코드 중에서 최종적으로 가져갈 코드만 살리고 나머지는 지워야한다.

먼저 git switch 기능브랜치 로 가서
git merge 기존브랜치 로 merge 시켜줘야

다른 커밋이 생성되지 않고 기존브랜치와 기능브랜치가 같은 곳을 가리키게 된다.

코드를 수정후 git add를 통해서 해당 파일을 스테이징 해두면
기다리고 있던 회색 merge commit에 포함이 된다.
아래 명령으로 git에게 아까의 파일을 병합하라고 알려줘야 한다.

git add 파일이름

//변경 내용을 병합하기 전에, 어떻게 바뀌었는지 비교해볼 수 있다.
git diff 원래브랜치 비교대상브랜치

이제 git commit을 하면
merge commit이 정상적으로 생성됨을 확인할 수 있다.

---

📌 git rebase

Rebase란?

merge와는 비슷하지만 조금 다른 rebase에 대해 알아보자

merge와의 공통점은 브랜치를 합친다는 점이다.
하지만 rebase는 merge보다 깨끗한 commit history를 만든다는 차이점이 있다.

이 둘의 목적은 한 브랜치에서 다른 브랜치를 합치는 것이다.

다만 merge는 새로운 commit을 만들어서 합치는 거고

rebase는 현재 브랜치의 베이스를 재설정해서 합치겠다는 건데
베이스가 바뀔 commit들의 내용은 같지만
새롭게 복사하여 연이어 붙이는 것이다. (선형적인 모습으로 바뀜)
그렇기 때문에 기록이 없어져 버린다는 단점이 존재한다.

rebase 전의 commit들은 rebase 후의 commit들과 id가 다르다.

commit 메세지는 같은데 commit id가 다른 것을 보면
복사가 되어서 새롭게 생성되었다는 것을 확인할 수 있다.

여기서 주의할 점은 merge를 한 코드 결과와
rebase를 한 코드 결과는 같아야 한다.

---

📌 git cherry-pick

체리 케이크 같은 것에서 위에 올라간 체리만 쏙쏙 골라먹는 행위를
체리피킹이라고 한다.

즉, cherry-pick의 어원은 좋은 것만 골라서 사용한다는 뜻

그러면 Git에서 좋은게 과연 뭘까?

간단하게 다른 브랜치에 있는 commit을 선택적으로
내 브랜치에 적용시키는 것을 말한다.

체리픽은 주로 무슨 상황에서 사용할까?

체리픽을 통해 메인에 내가 원하는 커밋이 머지되는 상황을 천천히 살펴보자.
방법은 2가지가 잇다.

• 1. main브랜치에 체리픽을 하고 바로 origin main에 push하는 방법이다.

그런데 이렇게 main에 직접적으로 푸쉬하는 방법은 주로 사용되지 않는다.
주로 기능브랜치를 따로 생성해서 main브랜치로 merge PR을 요청한 후에 merge가 되는 경우가 많다.

• 2. 현재 작업중인 곳에서 해당 커밋을 가져와서 등록하는 방법

git log라는 명령을 통해 커밋들의 로그를 확인할 수 있는데
여기에서 체리픽과 커밋의 해쉬를 입력해주게 되면
현재 작업중인 곳에서 해당 커밋을 가져와서 등록할 수 있다.

커밋의 해쉬 앞부분에 대여섯 글자만 다 입력할 필요없이 찾을 수 있다.

한개의 커밋만 가져오고 싶다면
git cherry-pick 명령어 다음에 가지고 오고 싶은 커밋의 id를 적어주면 된다.

당연히 여러개를 가지고 오고싶다면
commit id를 공백으로 구분해서 적어주면 된다.

또 특정 구간에 있는 연속된 commit을 불러올 수 있다.
가져오고싶은 연속된 commit들 중
시작 커밋의 id와 마지막 id의 아이디를 적고
이 둘 사이에 ..표시로 이어주면 된다.

이렇게 원하는 커밋만 속속 골라서 다른 브랜치에 반영시킬수 있다.

체리픽을 이용해서 브랜치의 충돌된 상황을 해결할 수 있다.

• 1. conflict을 해결하기 위해 코드를 수정한다.
• 2. git add 명령으로 수정된 코드를 add한다.
• 3. git cherry-pick --continue 명령을 수행한다.

체리픽 명령어 이후에 충돌이 발생했다는 메세지가 뜨면
소스 코드를 수정을 하고 git add를 통해 스테이지 상태로 변경한다.
그 후 git cherry-pick --continue 명령어로
명령어를 수행하면 모든 충돌이 해결되고 정상적으로 commit을 불러온다.

---

📌 git tag, git log

꼬리표(tag) 달기, 확정본 식별자id 얻기 (log)

소프트웨어의 새 버전을 발표할때마다 tag를 달아 놓으면 좋다.
(물론 꼬리표는 SVN 등에 이미 존재하는 기능이다.)

아래 명령을 실행하면 새로운 꼬리표인 1.0.0을 달 수 있다.

git tag 1.0.0 1b2e1d63ff
//위 명령에서 1b2e1d63ff부분은 꼬리표가 가리킬 확정본 식별자이다.

아래 명령으로 확정본 식별자를 얻을 수 있다.

git log

확정본 식별자의 앞부분 일부만 입력해도 꼬리표를 붙일 수 있지만,
그 일부분이 반드시 고유하다는 조건이 필요하다.

---

📌 git reset, git revert

로컬 변경 내용 삭제/되돌리기

이번에는 더 유용한 작업 되돌리기를 알아보자.
(이 방법은 로컬에서 혼자 작업할때 추천하는 방법이며 완전히 기록을 지우는 방법이다.)

만약 우리가 실수로 무언가 잘못한 경우,
아래 명령으로 로컬의 변경 내용을 되돌릴 수 있다.

git checkout --파일이름
//위 명령은 로컬의 변경 내용을 변경 전 상태(HEAD)로 되돌려준다.

다만, 이미 인덱스에 추가된 변경 내용과 새로 생성한 파일은 그대로 남는다.

만약 로컬에 있는 모든 변경 내용과 확정본을 포기하려면,
아래 명령으로 원격 저장소의 최신 이력을 가져오고,
로컬 master브랜치가 전 이력을 가리키도록 할 수 있다.

git fetch origin
git reset --hard origin/master

깔끔하게 최근 커밋 1개 지우기

git reset HEAD~1

하지만 이 방법은 애초에 커밋을 하지 않은 상태로 만들어진,
즉 히스토리를 고쳐 쓴다는 점때문에
다른 사람이 사용하는 remote 브랜치에서는 사용하지 않는 방법이다.

대신에 이때는 revert를 사용하면 되는데,

git revert HEAD

현재 HEAD가 있는 곳을 revert 시켜주게 되면
기존의 커밋은 살아있으면서 다시 커밋이 생성된 것을 볼 수 있다.

이렇게 revert를 하게되면
다른 사용자에게도 변경 내역을 보낼 수 있게 된다.

그럼 이번에는 삭제한 커밋과 브랜치를 복구하는 방법을 알아보자.

한가지 알아둬야 할점은
명령어가 입력되고 실행되는 행위에는 모두 해쉬값이 생긴다는 점이다.

제거를 했어도 제거를 하기 전, 제거를 하는 행위 모두가
기록에 남아있는 것이다.

이 점을 이용해서 해당 해시값을 찾고
그 해쉬값을 reset 시키는 방법을 사용해보자.

git reflog를 입력하면 모든 log를 볼 수 있다.
그 모든 로그에는 해쉬값도 볼 수 있다.

여기서 특정 커밋을 삭제하기 전 해쉬값을 입력해주게 되면
놀랍게도 특정커밋이 다시 살아나게 된다.

git reset --hard 특정커밋의Hash

브랜치도 마찬가지로 다시 복구할 수 있다.

git switch -c 브랜치 브랜치커밋의Hash 

---

📌 그 외 유용한 명령어들

git의 내장 GUI

gitk

콘솔에서 git output을 컬러로 출력하기

git config color.ui true

이력(log)에서 확정본 1개를 딱 한 줄로만 표시하기

git config format.pretty oneline

파일을 추가할 때 대화식으로 추가하기

git add -i

---

참고자료
https://rogerdudler.github.io/git-guide/index.ko.html
https://www.youtube.com/watch?v=b72mDco4g78
https://www.youtube.com/watch?v=JsRD2AWxxFg
https://www.inflearn.com/course/git-and-github#reviews