GIT 명령어 모음

GIT에 대하여 알아보자

Git 커밋

COMMIT : 아랫 단계를 만들어 주는 것???

기존에 있는 것에 자식을 만들어 주는 것이며 c2의 부모가 c1이 된다.

---

 

Git 브랜치

branch : 브랜치는 특정 커밋에 대한 참조(reference)에 지나지 않습니다

 

같은 c1안에 새로운 newImage를 넣어주는 것이 branch이다.

 

 

이 상태에서 commit을 하게 된다면 현재 선택이 되어있는 main이 내려가며 newimage는 c1에 남아있게 된다.

 

 

 

새로운 명령어 checkout을 통하여 브랜치명을 선택하여 줄 수 있다.

그다음에 commit을 하여 newimage를 c2로 보내줄 수 있다.

 

---

브랜치와 합치기(Merge)

merge : 두 개의 브랜치를 합치는 

 

 

git에서 서로 다른 작업을 했던 것들을 다시 붙이는 방법으로 MERGE가 있다.

붙이는 방법으로 MAIN을 CHECKOUT 하고 MERGE '브리지'를 한 다음에 대상을 브리지로 옮기고 다시 MERGE MAIN을 하면 서로 같은 위치에 커밋으로 이동할 수 있다.

---

Git 리베이스(Rebase)

MERGE와 같은 기능으로 브랜치 끼리 서로 작업을 접목하는 기능을 하는 REBASE다.

 

 

 

---

 

Git에서 여기저기로 옮겨 다니기

git에서 이동할 수 있는 방법

HEAD

 HEAD는 현재 체크아웃된 커밋을 가리킵니다

HEAD는 항상 작업트리의 가장 최근 커밋을 가리킵니다.

 

 

---

상대 참조

 

매번 해시를 확인하려고 git log 명령어를 치고 있을 겁니다

 

Git의 상대 참조(Relative Ref)가 여기서 등장합니다

 

• 한 번에 한 커밋 위로 움직이는 ^
• 한번에 여러 커밋 위로 올라가는 ~<num>

---

"~" 연산자

 

커밋트리에서 위로 여러 단계를 올라가고 싶을 수 있습니다.

 ^를 계속 입력해서 올라가는 것 말고 좋은 방법이 있습니다.

Git 에는 틸드 (~) 연산자가 있습니다.

(~) 틸드 연산자는 (선택적) 올라가고 싶은 부모의 개수가 뒤에 숫자가 옵니다

 

---

브랜치 강제로 옮기기

-f   옵션을 이용해서 브랜치를 특정 커밋에 직접적으로 재지정할 수 있습니다

git branch -f main HEAD~3

(강제로) main 브랜치를 HEAD에서 세 번 뒤로 옮겼습니다. (three parents behind HEAD)

 

---

Git에서 작업 되돌리기

Git에서 변경한 내용을 되돌리는 방법은 크게 두 가지가 있습니다 --

하나는 git reset을 쓰는 거고,

다른 하나는 git revert를 사용하는 것입니다.

 

Git 리셋(reset)

각자의 컴퓨터에서 작업을 하는 상황에 사용을 하기 좋다.

 

Git 리버트(revert)

로컬로 작업을 하여 수시로 정보를 공유받아야 하는 경우에 사용하기 좋

뒤로 가기 : undo, 초기화 : reset 도 있다.

---

작업을 여기저기로 옮기기

 

Git 체리-픽 (Cherry-pick)

첫 명령어는 git cherry-pick입니다. 다음과 같은 형태로 사용합니다:

git cherry-pick <Commit1> <Commit2> <...>

현재 위치(HEAD) 아래에 있는 일련의 커밋들에 대한 복사본을 만들겠다는 것을 간단히 줄인 말입니다

 

 

---

Git 인터렉티브 리베이스(Interactive Rebase)

인터렉티브 리베이스가 의미하는 뜻은 rebase 명령어를 사용할 때 -i 옵션을 같이 사용한다는 것입니다

실제" git에서는 UI창을 띄우는 것 대신에 vim과 같은 텍스트 편집기에서 파일을 엽니다

 

 

로컬에 쌓인 커밋들

 -i 의 의미

 

대화형 (-i 옵션)

• git rebase -i
• git cherry-pick

이 두 가지를 이용해서 버그를 발견하고 수정을 위해 사용이 되었던 불필요한 커밋들을 삭제를 시킬 수 있습니다.

 

 

직접 해보자

 

• git rebase -i 명령으로 우리가 바꿀 커밋을 가장 최근 순서로 바꾸어 놓습니다
• git commit --amend 명령으로 커밋 내용을 정정합니다
• 다시 git rebase -i 명령으로 이 전의 커밋 순서대로 되돌려 놓습니다
• 마지막으로, main을 지금 트리가 변경된 부분으로 이동합니다. (편하신 방법으로 하세요)

이용을 하다 보니 새로 알게 되는 것들이 많은데 일단 처음 사용법을 깨달은 것은

git rebase는 이전의 커밋을 복사해서 내가 원하는 지점부터 다시 만들어 주는 것이라는 것과

branch는 커밋과는 다른 것이라는 거 일정에 지점표시??? 같은 거라 branch를 옮길 때에는 브랜치 명령어를 

사용하여서 옮겨주어야 한다

 

그리고  git cherry-pick을 사용하는 방법은 지금 내가 어디에 checkout이 되어 있는지가 중요하다.

내가 checkout을 한지점에서부터 원하는 commit들 중에서 필요한 commit만 가져올수 있기 때문이다.

그렇기에 다시 생각을 해보면

 

git rebase -i는 아래에서 시작해서 위로 내가 원하는 것을 집어서 지정된 지점에서 부터 만들어 주는 것이고

git cherry-pick은 내가 만들고 싶은 지점을 먼저 고르고 거기에서 필요한 commit을 가져와서 만들어주는 개념이다.

 

문제풀이를 완료한 나의 작품 해보니 점점 이해하는 게 쉬워지는 것 같다.

 

 

Git 태그

주요 릴리즈나 큰 브랜치 병합(merge)이 있을 때 ( 작업 이력)에서 중요한 지점들에 영구적으로 표시를 할 방법

Git 태그는 커밋들이 추가적으로 생성되어도 절대 움직이지 않는다는 것입니다

 

맨뒤에 위치를 넣어주지 않으면 지금 내가 있는 위치에 만들어준다는 것을 알아두자.

 

 

 

Git Describe

git에는 여러분이 가장 가까운 "닻(태그)"에 비해 상대적으로 어디에 위치해 있는지

*describe(묘사)*해주는 명령어가 있습니다

Git describe는 커밋 히스토리에서 앞 뒤로 여러 커밋을 이동하고 나서

커밋 트리에서 방향감각을 다시 찾는데 도움을 줍니다

 

이런 상황은 git bisect(문제가 되는 커밋을 찾는 명령어라고 간단히 생각하자)를 하고

나서라던가 휴가를 다녀온 동료의 컴퓨터에 앉는 경우가 있습니다

 

 

git rebase를 할 때 

git rebase <checkout 할 위치>  <가져올 위치 >를 입력하면 한 번에 옮겨 줄 수 있다는 것을 알았다.

 

부모를 선택하기

~ 수식처럼 ^ 수식 또한 뒤에 숫자를 추가할 수 있습니다

 

Git은 보통 병합된 커밋에서 "첫" 부모를 따라갑니다.

하지만 ^수식을 숫자와 함께 사용하면 앞의 디폴트 동작대로가 아닌 다른 결과가 나타납니다

 

 

 

main^2를 붙여준다면?

 

 

두 번째 경로에 있는 커밋으로 이동을 하게 된다.

 

 

예상해 보기

 

 

 

직접 위치를 선택을 해도 되지만 길을 따라 올라가는 방법도 있다.

 

 

 

한 번에도 사용이 가능하다는 

 

또한 브랜치를 만들어 주는 것에도 가능하다.

 

 

 

merge를 하면 기존에 있는 것과 내가 원하는 것을 선택하여서 두 개를 잊는 새로운 커밋을 하나 만든다는 것.

 

 

checkout 할 때 새로운 브랜치가 필요하다면 -b를 추가해 주면 브랜치를 바로 추가할 수 있다.

 

---

2시 강의필기

S.A. : 개발을 하기 전에 어떻게 만들 것인가 계획을 하는 과정을 정해두는 것 

오류를 많이 내보고 그것을 해결해보는 경험을 많이 가져 보는 것이 아주 중요하다는 것을 배웠습니다.

---

 

GIT 원격

 

 

 

GIT CLONE

 

 

Git 원격 브랜치

 

 

 

처음 생각으로는 이렇게 될 것이라고 생각했다.

 

 

하지만 실제 결과

 

 

클론으로 생성이 된 메인은 commit을 넣어도 클론으로 생성이된 곳에는 반영이 되지 않지만

 

기존에 있던 main은 클론과 함께 반영이 된다는 것을 볼 수 있다.

 

 

Git Fetch

 

 

git fetch를 사용하므로 써

서버에 있는 커밋을 그대로 복사를 해오고 서버에 있는 main위치에 맞추어 o/main의 위치도 변경을 해준다.

 

 

 

git fetch는 서버에서 자료를 다운로드하여서 반영을 하지만 내가 로컬에서 작업을 하던 것에는

영향을 주지 않지 때문에 변경되거나 하는 걱정은 없다.

 

 

Git Pull

 

 

 

git fetch를 하고 git merge를 하는 것을 한 번에 해주는 것이 git pull이다 

워낙 자주 사용하게 될 기능이라서 따로 만들어 두었나 보다.

 

협동 가장하기

 

 

 

 

 

 

 이걸 만들어 보자

 

오른쪽 C0는 원격 저장소니깐 현제 c3에 있는 상태이며 로컬에서도 C3에 있도록 해야 한다.

 

그러므로 git clone을 해서 복사를 만들고 git faketeamwork로 c3까지 만들어 준 다음에

 

C1에서 commit을 만들고 c3 pull을 하면 될 것이다.

 

 

짜잔 예상에 맞추어 만들 수 있었다.

 

Git Push

 

 

 

엇갈린 작업

 

rebase

 

 

merge

 

 

git pull --rebase

 

 

 

그냥 pull만 썼을 때는?

 

 

 

원격저장소 거부! (Remote Rejected!)

 

규모가 큰 개발팀에서 일하는 경우, 보통 원격저장소의 main 브랜치는 잠겨있습니다(locked). 그래서 변경사항을 적용하려면 pull request 과정을 거쳐야 하죠. 만약에 여러분이 로컬 저장소의 main브랜치에서 커밋을 한 후 push하려고 시도한다면, 다음과 같은 오류를 받게 될 겁니다. :

! [remote rejected] main -> main (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)

 

리모트 거부 대부분의 main은 잠금이 걸려 있기 때문에 로컬로 가져와서 한다.

 

왜 거부 되었나?

원격 저장소는 자신의 main 브랜치에 대한 직접적인 커밋을 제한합니다. 왜냐하면 push 대신에 pull request가 쓰여야 한다는 규칙이 원격 저장소의 main 브랜치에는 적용되어 있기 때문이죠.

여러분은 브랜치를 따로 만들어 작업한 다음, 그것을 push하고 pull request를 하려 했습니다. 하지만 그걸 잊고 실수로 main 브랜치에서 직접 커밋을 해버렸네요! 이제 변경 사항을 push 하지도 못하고 옴짝달싹 못하는 상황이 되어버렸습니다.

 

해결방법은?

feature라는 이름의 다른 브랜치를 만들어 원격 저장소에 push 하세요. 그리고 원격 저장소와 동기화될 수 있도록 로컬 저장소의 main 브랜치를 reset 하세요. 그렇지 않으면 여러분이 다음에 pull을 시도할 때 문제가 발생하거나, 다른 협업자들의 커밋이 여러분의 커밋과 충돌할 수도 있습니다.

 

원하는 목표를 그림으로 그려 보자면 이렇게 되야 하므로

 

 

순서에 맞추어 알맞은 명령문을 사용해서 만들어 주면!

짜잔 하고 나옵니다^^

 

 

feature 브랜치 병합하기

 

 

문제를 풀어 봅시다!

목표를 봤을 때 먼저 원격에 있는 c8을 가져와야 할 것 같고

그 밑으로 side1을 rebase 하고 그 밑에 side2.... side3을 순서대로 rebase 해주고

main 브랜치를 c7'로 이동을 시켜준 다음에 push를 해주면 될 것 같다.

 

 

짠 내 생각대로 만들어졌다

하지만 뭔가 단축할 만한 방법이 있다고 하는데..

 

정답은 여기였다

굳이 git branch를 할 필요 없이 rebase를 main에 해주면 checkout이 main에 붙으므로

2번 작업을 하나로 줄일 수 있다.

 

 

왜 merge 하지 않는 거죠?

 

merge와 rebase의 기능은 서로 비슷하지만 왜 rebase를 선호하는가?

 

 

 

문장을 이해 보자면

커밋트리가 깔끔하게 정리되었으면 하는 사람들은 rebase를 선호하고

만들어진 이력을 중요시하는 사람들은 merge를 사용하는 것을 선호한다고 볼 수 있다.

 

문제 풀이

 

rebase를 했던 들을 merge으로 만들어 보자

먼저 fetch로 원격에서 받아온 다음에

각 side와 merge를 해준다 

그다음에 push를 해주면 된다고 생각했다.

 

merge의 단점이 checkout이 따라오지 않아서 마지막에 main을 가져오는 것에 손이 갔다.

해설지를 보면?

 

 

pull이 fatch와 merge인 것을 이용하여 main에 checkout을 하여 한번에 할 수 있다는 것을 알았다.

이렇게 배우면 배울수록 느껴지는 것이 

checkout이 어디에 되어 있는지가 엄청 중요하다는 것을 알 수 있다.

 

 

원격-추적 브랜치

 

체크아웃을 만들 때 뒤에 원격 브랜치 위치를 추가로 넣어주면 추적하는 브랜치를 만들 수 있다.

 

 

 

 

 

위 두 가지를 보았을 때 기존에 방식대로만 push 또는 pull을 하면 그 사용하는 브랜치 명(현재:foo)으로

원격 브랜치가 생성이 되어서 원격저장소에 만들어질 것인데 

checkout를 o/main에 추적시켜 주었기 때문에 foo의 작업을 원격에서는 main이 받아들여서 할 수 있게 된다고 

보면 될 것 같다.

 

방법 #2

 

checkout이 아닌 branch에서도 이렇게 추적을 할 수 있는 방법이 있다.

checkout이랑 적는 순서가 다르니 잘 기억을 해두어야 한다.

 

 

 

---

문제 풀이

 

브랜치를 만들고 o/main이랑 추적을 시킨 다음에 커밋을 만들고

fetch를 해서 원격에서 받아 온다음

그 밑으로 rebase를 해서 다시 push를 해서 넣어주면 끝~!

 

정답은 맞혔지만 조금 더 간단한 방법이 있다,..

 

 

pull --rebase를 하게 되면 원해는 fatch 후에 merge를 하지만 --rebase를 붙여줌으로써

merge대신 rebase를 실행시켜 주는 것이다.

 

다른 방법으로 branch -u를 사용하는 방법이다.

git branch -u를 사용하려면 기본에 브랜치가 존재를 해야 하므로 

기본에 브랜치가 존재를 했다면 branch -u

새로운 브랜치를 만들어서 추적을 하려면? checkout -b을 사용하는 것이 좋아 보인다.

 

 

Push의 인자들

 

이 말인즉슨 내가 지금 체크아웃하고 있는 위치에 상관없이 어디든지 내가 원하는 브랜치의 push를 해줄 수 있다는 것이다.

 

 

 

만약 그냥 push를 한다면??

 

 

문제 풀이

 

 

쉽게 풀 수 있었다.

 

 

<place> 인자에 대한 세부사항들

 

 

그러니깐 다시 보면 git push origin 다음에 오는 게 내가 옮기고 싶은 위치 까지를 정하고

그다음에 원격으로 밀어 넣고 싶은 브랜치를 넣어주는 것인 거 같다.

 

 

원격에서 새로운 브랜치를 만들고 main이 있는 위치까지 push를 시켜준다.

 

문제풀이

 

 

어렵게 생각할 필요 없이 목표를 보면 main의 위치는 c4에 있고 foo의 위치는 c5에 있으므로

git push origin c4:main
git push origin c5:foo

라고 해주면 간단하게 끝이 난다.

 

Git fetch 인자들

 

앞에서 했던 방법을 반대로 원격에서 위치를 맘대로 정하여서 로컬에 반영을 시키는 법이다.

 

 

 

기존에 있는 나의 로컬은 가만히 두고 원격에서 foo의 위치만 그대로 가져오는 것이라고 보면 될 것  같다.

 

 

 

 

원격은 변화가 없이 c2번만 가져오고 가져온 곳에 bar브랜치를 옮겨준다.

 

bar 브랜치가 없는 경우에도??

 

 

생성하고 만들어준다.

 

 

지정을 해주지 않는다면??

 

 

모든 브랜치를 가져오게 된다

 

문제풀이