Learn Git Branching
git을 쉽게 게임처럼 이해하는 게임입니다
https://learngitbranching.js.org/?locale=ko
git commit
우리는 새로운 변경점이 만들어 졌을 때 그 순간을 기반으로 커밋을 만들 수 있습니다
예시로 파일을 삭제하거나 수정, 생성했을 때를 들 수 있습니다
예시는 커밋 동작을 실행했을 때의 예시이며 HEAD가 달려있는 곳에서 커맨드가 작동했음을 알 수 있습니다
git checkout
깃에서의 명령어의 결과는 대부분 HEAD에서 일어나게 됩니다
checkout 이러한 HEAD를 달아주는 명령어입니다
편의를 위한 명령어로
git checkout -b (브랜치이름) 등이 있습니다
checkout 명령어로 절대 참조로 주소를 찍어줄 경우 HEAD를 분리시킬 수 있습니다
- 간편 명령어로 git checkout -b (브랜치이름)가 있습니다
명령어를 사용할 경우 브랜치가 생성됨과 동시에 체크아웃이 이루어집니다
git branch
방대한 바다에서 배가 항구로 돌아올 때 기준이 되는것은 등대의 밝은 빛입니다
마찬가지로 데이터의 바다에서 우리가 돌아올 커밋의 등대를 세워야합니다!
이 명령어로, 당신은 이정표를 세울 수 있습니다
git branch (브랜치이름) 명령어를 사용할 경우 HEAD가 있는 커밋에 브랜치가 생성 됩니다
이 브랜치는, 당신의 명령에 사용할 수 있는 절대 참조 혹은 상대 참조 주소의 기준이 됩니다
- git branch -f (브랜치이름) (주소)
위 명령어를 사용할 경우 HEAD의 위치가 아닌 다른곳에 브랜치를 생성할 수 있습니다
HEAD가 아닌 다른 곳에 브랜치가 생성되는 모습입니다
git rebase
우리는 작업한 결과물을 합쳐야 하는 순간이 있습니다. 그럴 때 사용할 수 있는 명령어에는 두 가지가 있는데 rebase 명령어는 그 중 하나입니다
rebase의 경우 HEAD가 있는 커밋트리가 옮겨가게됩니다
git rebase의 명령어가 입력된 모습입니다
C2에서 작업했던 내용을 팀원의 C3 커밋과 합쳐진 모습인데, 커밋 트리가 깔끔해지는 장점이 있습니다
- git rebase -i (주소)
리베이스 인터렉티브 명령어의 경우 리베이스 순서를 섞거나, 삭제한 채로 보낼 수 있습니다
명령어를 사용하여 C3는 삭제되고, 다른 커밋의 순서를 바꾼 모습입니다
git merge
앞서 우리는 rebase를 사용하여 커밋을 합쳐보았습니다
다음 merge 명령어는 다른 방식입니다. merge 명령어는, HEAD가 있는 커밋을 중심으로 다른 커밋을 끌어와 합치게 됩니다
git merge main의 결과입니다
같은 상황에서 merge와 rebase의 결과 값은 같습니다
하지만 계획되지 않은 merge의 무분별한 사용은 커밋트리를 지저분하게 만들 뿐입니다
git reset
우리는 잘못된 커밋을 진행했을 때 다시 돌아가고 싶은 경험이 있었을 것입니다
그럴 때 사용 하는 명령어로 대표적인 두 가지가 있는데 우선 reset입니다
이 명령어는 기본적으로 HEAD의 위치를 위로 올린다 라고 이미지하는것이 좋습니다
보통의 경우 reset은 내역의 삭제를 의미하지만 커밋트리에서는 명령어가 입력되도 한번 만들어진 커밋은 삭제되지 않습니다
다만 이정표인 브랜치도 없고 HEAD도 달려있지 않고, 이미 커밋트리의 일부가 된 커밋이 아닌이상 절대 참조 주소를 통한 방법 외에 그 커밋으로는 영원히 돌아갈 수 없습니다
git reset C1을 사용한 결과입니다
C2의 경우 연결된 커밋도 없는 상태이기 때문에 절대 참조를 모른다면 다시 돌아갈 수 없는 상태가 된겁니다
git revert
잘못된 커밋의 결과를 되돌리는 방법 중 두번째입니다
커밋은 변경점이 발생할 때 만들 수 있습니다
커밋트리로 연결된 바로 전 커밋은 변경점이 나타나기 전의 커밋이란 뜻입니다
revert 명령어는 해당 커밋의 변경점의 발생 이전 상황으로 돌려주는 명령어입니다
reset과 가장 큰 차이점은, revert의 경우 '과거로 되돌린다' 라는 커밋 조차 새로 만들어 기록을 만드는 것에 있습니다
git revert C4를 입력한 결과입니다
예를들어 C4에서 만든 파일을 삭제해서 C5로 온 것인데, revert를 사용해서 되돌아간다면 C4에서 삭제하기 전 상황으로 돌아가게 되는 것입니다
revert의 주의점은, 만약 오래전으로 거슬러 가고 싶다면 반드시 한단계 한단계 천천히 올라가야 한다는 점입니다
다음은 HEAD가 C5에 있던 상황에서, git revert C4 C3 명령어를 입력한 상태입니다
그러면 현재 상황은 C5에서 C4의 작업내역으로 귀환, C4에서 C3의 작업내역으로 귀환한 상태입니다
만약 여기서 작업을 하고 커밋을한다면
그리고 rebase 인터렉티브의 응용
커밋트리를 정리할 수 있습니다
지금은 커밋트리가 단순하여 별거 아니지만
수많은 커밋이 꼬여있는 현업 상황에서는 이러한 응용력 하나하나가 큰 힘을 발휘할 것입니다
git cherry-pick
아주 유용한 체리픽 명령어는 자기가 원하는 작업물만을 가져오고 싶을 때 주로 사용됩니다
여기서 각각의 테스트 결과만을 가져오고 싶다면
git cherry-pick C3 C5 C7 명령어의 결과입니다
여기서 C3 C5 C7의 자리는 상대 참조의 주소가 들어가도 결과값은 같습니다
git clone
로컬에서 개인이 작업할 때는 괜찮지만, 우리는 협업을 하는 상황이 많습니다
협업을 하는 상황 대부분은 외부에 git 서버를 두며
우리는 그 origin을 로컬에 가져와야합니다
이 때 사용되는 명령어가 git clone 입니다
이때 origin/main의 의미는, 깃 서버의 main 브런치 위치도 C1에 있다는 의미입니다
origin/main을 옮기기 위해 로컬에서는 아무리 노력해도 소용 없습니다
저것은 원격 서버에 존재하기 때문입니다
git fetch
fetch 명령어는 외부 서버에서의 작업 내역을 로컬 서버에 끌어오는 명령어입니다
이 명령어를 사용해도 로컬 서버에서의 헤드와 브런치는 변하지 않는데, 그 이유는 단순히 작업 내역을 로드했을 뿐 무언가가 수정이 된 것이 아니기 때문입니다
당신은 여전히 C3 bugFix에서 작업을 하고 있으며 그 작업내역을 바탕으로 커밋을 하면
이제 당신의 작업 내역을 합치길 원한다면 merge 혹은 rebase 명령어를 적절하게 사용해줍니다
git push
만약 당신의 작업내용을 업데이트 하고싶다면, push 명령어를 사용하면 됩니다
origin서버의 bugFix가 당신의 작업내역까지 업데이트 된 모습을 볼 수 있습니다
git pull
우리는 fetch와 push의 개념에 대해 알아보았습니다
fetch는 서버의 작업 내역을 다운받는 것이며 push는 내가 작업한 내역을 서버로 전송하는 일입니다
그렇다면 두 명령어를 한 번에 처리하는 방법은 없을까요?
그 답은 pull 명령어에 있습니다
자신의 작업내역은 C2이며 서버의 작업내역은 C3라는 서로 다른 작업내역입니다
이때 작업내역인 C3를 다운받아 로컬에 있는 C2의 작업 내역을 합칠 수 있는데 한 번의 명령어로 간단하게 처리를 할 수 있습니다
git pull (merge 방식)
git pull --rebase (rebase 방식)
알아두면 좋을 것들
로컬 서버에 업로드 한다는 의미를 간단하게 이해하자면
branch는 앞에서 이정표라는 의미로 생각하면 된다 했습니다
그렇다면 로컬 서버에서는 C3, C4, C5, C6의 작업 내역이 있는데 오리진에는 브랜치도 없고, 작업 내역이 없습니다. 이 때는 단순하게 push를 진행하면 됩니다
git push의 결과
로컬 서버에 저장된 main과 Test라는 이정표를 따라 업데이트 된 것을 볼 수 있습니다
