OSSCA Redis 2023 1주차 과제

13.10.2023 — OSSCA, Git — 8 min read

git clone <리모트 저장소 url>

리포지토리를 새로운 디렉토리에 복사하는 명렁어
리모트 저장소에 있는 거의 모든 데이터를 복사하며, 프로젝트 히스토리를 전부 받아온다.
자동으로 디폴트 브랜치의 가장 최신 버전을 보여준다.
저장소를 복제하면 origin 이라는 리모트 저장소가 자동으로 등록된다.
git clone <리모트 저장소 url> <로컬 디렉토리 이름> 명령어를 치면 리모트 저장소 이름이 아니라 로컬 디렉토리 이름으로 복제된다.

git branch <새로 생성할 브랜치 이름>

git push <리모트 저장소 이름> <브랜치 이름>

리모트 저장소에 로컬의 최신 버전을 밀어넣는 명령어
해당 명령어는 리모트 저장소에 쓰기 권한이 있어야 사용할 수 있다.
clone 한 시점 이후에 아무도 리모트 저장소에 push 하지 않았을 때만 바로 push가 가능하다. 만약 누군가 push 했다면, 누군가 push한 내용을 merge로 가져온 후에 push 할 수 있다.
저장소를 복제하면 origin 이라는 리모트 저장소가 자동으로 등록되기 때문에, 일반적으로 git push origin <브랜치 이름> 이라고 많이 쓴다.
만약 로컬에서 새로운 브랜치를 만들어 원격에 push 하는 상황이라면, -u 옵션이나 --set-upstream 옵션을 사용하여 upstream 브랜치를 설정해야한다.
```
git push --set-upstream <리모트 저장소 이름> <브랜치 이름>
git push -u <리모트 저장소 이름> <브랜치 이름>
```
upstream이 설정된 상황이라면 <리모트 저장소 이름>과 <브랜치 이름>을 생략할 수 있다.

git pull <리모트 저장소 이름> <브랜치 이름>

git add <파일 혹은 디렉토리의 경로>...

파일을 Tracked(스냅샷에 포함된) 상태이자, Staged(커밋으로 저장소에 기록할) 상태로 만드는 명령어
git add 명령어는 파일 혹은 디렉토리의 경로를 여러개 받을 수 있다.
git commit 명령 실행시, 커밋 명령어 실행 시점의 파일이 커밋되는게 아니라 마지막으로 git add 명령어를 실행했을 시점의 파일이 커밋되어 저장소 히스토리에 남는다.

git commit

Staged 상태의 파일을 로컬 저장소에 저장하는 명령어
해당 명령어 실행시, Git 설정에 지정된 편집기(Vim, Emacs 등)가 실행되며, 편집기에 커밋 메세지를 적고 저장하면 된다.
커밋 메세지를 인라인으로 넣고 싶다면 다음과 같이 -m 옵션을 사용하면 된다.
```
git commit -m "커밋 메세지"
```
만약 git add 명령어를 통해 Staged 상태로 올리는 작업을 생략하고 싶다면, -a 옵션을 사용하면 된다. 해당 옵션 사용시, Tracked 상태의 파일을 자동으로 Staged 상태로 올려준다.
```
git commit -a -m "커밋 메세지"
```

git checkout <합칠 브랜치(A)>
git merge <합쳐질 브랜치(B)>

B 브랜치를 A 브랜치로 병합하는 명령어
A와 B 각 브랜치의 마지막 커밋과 A와 B의 공통 조상 커밋 하나, 총 3개의 커밋을 사용한 3-way Merge의 결과를 새로운 커밋 하나로 만들어 낸다. 그리고 A 브랜치가 해당 커밋을 가리키도록한다.

git checkout <Rebase할 브랜치(B)>
git rebase <합칠 브랜치(A)>

A 브랜치와 B 브랜치를 합치는 또다른 명령어
두 브랜치의 공통 조상 커밋으로 이동한 후, 공통 커밋부터 B 브랜치가 가리키는 마지막 커밋까지 diff를 만들어 어딘가에 임시로 저장해둔다. 그 다음 A 브랜치의 마지막 커밋을 가리키게 하고, 아까 저장해둔 변경사항을 차례대로 적용하며, A 브랜치에 새로운 커밋을 만들어 낸다. 단, 이때 A 브랜치는 새로운 커밋이 아닌, 합치기 전 마지막 커밋을 가리키고 있다.
두 브랜치를 서로 동기화 하기 위해서는 Fast-forward를 시키면 된다. 아래 명령 수행시, A 브랜치가 rebase를 통해 생성된 새로운 커밋을 가리키게 된다.
```
git checkout <합칠 브랜치(A)>
git merge <Rebase할 브랜치(B)>
```
rebase는 merge와 최종 결과물은 같고 커밋 히스토리만 다르다. rebase를 하면 커밋 히스토리가 선형이 되어 좀 더 깨끗한 히스토리를 만든다.

git checkout <합칠 브랜치(A)>
git cherry-pick <rebase할 커밋 해시(C)>

현재 브랜치(A)에 커밋 하나(C)만 rebase 하는 명령어
C 커밋에서 변경된 내용을 A 브랜치에 적용하여 새로운 커밋을 생성합니다. cherry-pick 완료 후, A 브랜치는 새로운 커밋을 가리키고 있다.

Pro Git book 한국어 버전