04. [Git 뿌수기] 4주차 내용 정리 (pull과fetch의 차이점, fetch, ahead, behind, diff, cherry-pick, rebase )

pull과 fetch의 차이

pull

• 원격 저장소로부터 필요한 파일을 다운+병합
• 지역 브랜치와 원격 저장소 origin/master가 같은 위치를 가리킨다.

fetch

• 원격 저장소로부터 필요한 파일을 다운 (병합은 따로 해야 함)
• 지역 브랜치는 원래 가지고 있던 지역 저장소의 최근 커밋 위치를 가리키고, 원격 저장소 origin/master는 가져온 최신 커밋을 가리킨다.
• 신중할 때 사용한다.
• 사용하는 이유?

     1. 원래 내용과 바뀐 내용과의 차이를 알 수 있다. (git diff HEAD origin/master)

     2. commit이 얼마나 됐는지 알 수 있다(git log --decorate -all --oneline)

     3. 이런 세부 내용 확인 후 git merge origin/master 하면 git pull 상태와 같아진다. (병합까지 완료)

 

 

 

pull

1. fetch 레포지토리를 생성합니다.

 

2. fetch-1, fetch-2 로컬 저장소를 생성하고 fetch 레포지토리랑 연결합니다.

 

3. fetch-1에서 work.txt 파일을 만들고 원격 저장소에 push 합니다.

 

원격 저장소(fetch)

 

4. fetch-2에서 pull 합니다.

pull 하면 work.txt 파일이 생기고 안에 내용은 fetch-1에서 push 했던 내용과 같습니다.

---

fetch

1. fetch-1에서 새로운 버전을 생성하고 원격 저장소에 push 합니다.

원격 저장소(fetch)

 

2. fetch-2에서 fetch를 합니다.

git fetch

fetch는 pull과 다르게 work.txt 파일에 변동이 생기지 않습니다.

 

3. 로그를 확인해 봅니다.

git log

원래는 origin/master가 표시되는데 표시가 없어졌습니다.

 

4. log에 --all 옵션을 추가해서 다시 확인합니다.

git log --all

원격 저장소의 master 브랜치의 버전이 더 앞서 있는 걸 확인할 수 있습니다.

 

5. merge 명령어를 이용해서 병합하면 pull 한 것과 같습니다. (fast-forward 됩니다.)

git merge origin/master

 

 

파일 수정 > add, commit > fetch > merge를 하는 경우

1. fetch-1에서 work3 버전을 만들어 push 합니다.

 

원격 저장소(fetch)

 

2. fetch-2에서 memo.txt 파일을 생성하고 commit 합니다.

 

log는 아래와 같습니다.

 

3. fetch를 하고 log를 확인합니다.

origin/master가 사라진 모습입니다.

 

4. log에 --all 옵션을 줘서 다시 확인해 봅니다.

work3 버전이 보입니다. 

 

5. 하지만 work.txt 내용에는 반영되어 있지 않습니다.

 

6. git merge 합니다.

git merge origin/master

merge commit이 자동으로 생성됩니다.

 

merge commit이 최상단에 있고 work.txt 내용을 확인해 보니 work 3 버전의 내용이 적용되어 있습니다.

---

ahead

원격 저장소의 브랜치보다 버전의 앞서 있을 경우

 

아래와 같은 메시지가 나옵니다.

origin/master보다 commit이 하나 앞서있다는 뜻입니다.

 

behind

반대로 늦을 때는

 

behind로 표시됩니다.

---

diff

파일의 어떤 내용이 변경되었는지 차이점을 비교할 수 있습니다.

Working Derectory와 Staging Area 간의 비교도 가능하고 commit 간의 비교, branch 간의 비교도 가능합니다.

 

관련 명령어

 

# commit된 파일상태와 현재 수정중인 상태 비교
git diff

# commit된 파일상태와 add된 파일 상태 비교
git diff --staged

# commit간의 상태 비교하기 - commit hash 이용
git diff [비교할commit해쉬1] [비교할commit해쉬2]
# ex) git diff 04e16f 0d813c

# commit간의 파일 상태 비교하기 - commit hash 이용
git diff [비교할commit해쉬1] [비교할commit해쉬2] [파일이름]
# ex) git diff 04e16f 0d813c work.txt

# commit간의 상태 비교하기 - HEAD 이용
# 가장 최근의 커밋과 그 전의 커밋을 비교한다
git diff HEAD HEAD^

# branch간의 상태 비교하기 - HEAD 이용
git diff [비교할branch1] [비교할branch2]
# ex) git diff feature/test origin/master
# local의 feature/test브런치와 remote의 master branch 비교

 

삭제된 부분을 빨간색으로 추가된 부분은 초록색으로 표시됩니다.

---

cherry-pick

수정된 부분만 적용

1. master 브랜치에서 a와 b브랜치 생성

git branch a
git bracnh b

2. a에서 a1.txt / a2.txt 생성 후 add commit

touch a1.txt
git add a1.txt
git commit -m "a1"

touch a2.txt
git add a2.txt
git commit -m "a2"

 

3. b로 브랜치 전환

git checkout b

4. b에서 b1.txt / b2.txt / b3.txt 생성 add, commit

touch b1.txt
git add b1.txt
git commit -m "b1"

touch b2.txt
git add b2.txt
git commit -m "b2"

touch b3.txt
git add b3.txt
git commit -m "b3"

5. a브랜치에 b2.txt 수정 내용을 cherry-pick

git checkout a
git cherry-pick "b2_commit_id"

 

merge의 경우 스냅샷 전체를 가져오기 때문에 b2_commit_id를 입력하면 b1.txt / b2.txt를 동시에 가져옵니다.

 

참고 사이트

https://like-a-drizzle.tistory.com/204

26. [Git] cherry-pick 개념과 기본 사용법

---

rebase

아래는 c에서 master와 topic 브랜치로 나눠지는 그림입니다.

 

c에서 파생된 master를 아래와 같이 이동시키는 기법이 rebase(베이스를 변경한다)라고 합니다.

 

commit history를 깨끗하게 유지할 수 있습니다.

 

 

cherry-pick과 같은 환경을 준비합니다. (4번까지)

 

5. a브랜치에서 rebase 실행

git checkout
# git rebase "브랜치 이름"
git rebase b

 

6. log를 확인해 보면 a1과 a2 commit이 b3 뒤로 이동되어 있습니다.

 

merge와 rebase가 다른 점