🔸Git으로 협업능력 기초 다지기

* 들어가기 앞서 해당 포스팅은 짧은 강의인 만큼 한 강의당 한 포스팅으로 이루어져 있지 않다. 다만 개인적으로 실습한 과정들이 많아 '더 보기'를 참고하며 청강 후 포스팅과 함께 실습 해보길 권유한다.

---

1강의 : 커밋(commit)하고 푸쉬(push)하기

• git clone ~ : 원격 저장소를 내 컴퓨너에 복사하는 일
• git add ~ / . : 저장을 원하는 파일들을 묶어 git에 저장하는 일(commit 준비)
• git commit -m "~" : 저장하는 시점을 글로 표기하는 것.
• git push ~ : github에 업로드하는 일

---

2강의 : 마지막 커밋으로 되돌리기

• git checkout ~ : 마지막 커밋으로 되돌아 갈 수 있다.
• sourceTree의 코드뭉치 버리기 기능을 사용하면 변경사항을 되롤릴 수 있다.

* 내가 만든 파일로 실습하기

먼저 class_2.md 파일을 VSC에 새로 만들고 VSC에 저장한 후에 다시 수정을 하고 저장을 했다. status명령어를 확인해보면 Untracked files라고 되어 있다. 뜻은 '추적되지 않는다.' 즉, 현재 내가 git에 저장이 되어 있지 않은 파일이기에 추적이 되지 않는 다는 것이다. 다시 말해서 git에 add(git에 저장이)가 되어 있지 않기 때문에 checkout을 실행해도 아무런 변화가 없을 것이다.

rdwoo1024@DESKTOP-B1D88NN MINGW64 /d/myclass/Git/Github/gitflow_test/fixed (main)
$ git status
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        class_2.md

nothing added to commit but untracked files present (use "git add" to track)

git add를 한 git status는 아래와 같다. 이제 여기서 해당 파일에 글을 삭제하거나 추가하면 된다. 

rdwoo1024@DESKTOP-B1D88NN MINGW64 /d/myclass/Git/Github/gitflow_test/fixed (main)
$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   class_2.md

이제 checkout을 하게 되면 아래와 같아진다.

rdwoo1024@DESKTOP-B1D88NN MINGW64 /d/myclass/Git/Github/gitflow_test/fixed (main)
$ git checkout -- class_2.md

따라서 add를 통해서 git이 가지고 있는 또는 commit을 통해서 git이 바라보고 있는 상태의 파일들을 과거로 돌릴 수 있는 것이다. 현재 나의 local에서 변화되는 것들을 git이 모두 읽어 낼 수 없다. 그러니 add와 commit을 통해서 저장되어 있는 상태들만 알 수 있는 것이다.

---

2 강의 : branch 만들기

• README.md에 새로운 나만의 branch 규칙 작성하기 -> lecuture브런치에 강의를 들을 때 때마다 추가하고 pr을 날려 볼 것.
• branch : 기존 내용을 유지한 체 새로운 내용을 추가하고 싶을 때 사용한다.
• checkout : 특정 브랜치(혹은 커밋)으로 돌아가고 싶을 때 사용.
• 소스트리의 체크아웃 : 브랜치 이름을 더블 클릭하면 체크아웃 기능

* 내가 만든 파일로 실습하기

현재 main의 sourceTree는 다음과 같다.

이상태에서 우리가 class_1.md파일이 생성이 되기 전 부분에 lecutre branch를 생성할 것이다.(왜냐면 class_1.md파일이 없는 곳에서 class_1.md파일을 추가해야 add와 commit이 가능하기 때문이다.) 이후 lecutre 브랜치에서 다시 calss_1 브랜치를 생성할 것이다.

그렇다면 이제 class_1.md의 내용을 현재 class_1.md내용이 없는 과거에서 불러와야한다. 여기서 사용할 문법은 checkout이다. 해당 코드는 아래와 같다.

git checkout <commit-hash> -- <file-path>

여기서 <commit-hash>는 가져오고자 하는 커밋의 해시이고, <file-path>는 가져오려는 파일의 경로다. 올바르게 명령을 하게 되면 branch class_1의 vsc에서는 fixed폴더와 class_1.md파일이 생성하게 될 것이다.

현재 branch가 생성된 모습이다. 이제 커밋을 해볼 것이다.

sourceTree에서 add없이 commit만 진행 했다. 그랬더니 현재 class_1이 가리키는 부분은 아래와 같다.

branch가 class_1일때의 가지 모양이다.

branch가 lecture일때의 가지 모양이다.

이제 여기서 우리는 기억을 해봐야 한다. 다음 동작에서 필요한 것은 lecture branch에서 class_2 branch가 생성이되고 class_2 파일을 커밋해야한다. 이전에 했던 방법과 동일하게 하면 아래와 같다. (현재 커밋이 되었음을 인지하고 있어야한다.) 

branch가 class_2일때의 가지 모양이다.

이렇게 class_2 branch를 생성하고 커밋까지 완료를 했다. main branch에서 가지 모양을 확인해 보면 아래와 같다.

branch가 class_2일때의 가지 모양이다.

이제 우리는 여기서 과거 feat! : Don't remove this files, this is description about lectures scripts 까지의 커밋을 삭제 (커밋을 강제 과거로 되돌리는 것)해볼 것이다. 여기서 주의할 것은 Add newFile.js에 있는 파일은 삭제된다. 코드는 다음과 같다.

rdwoo1024@DESKTOP-B1D88NN MINGW64 /d/myclass/Git/Github/gitflow_test (main)
$ git reset --hard 4c7b53a
HEAD is now at 4c7b53a ...

 현재 main은 아래와 같다

뭔가 아직 완벽해 보이지 않는다. 다시 보니 class_2의 history가 마음에 들지 않는다. class_2가 main과 함께 HEAD가 올라가면서 발생한 것으로 보인다. 즉, class_2의 생성 위치가 불분명하다. 따라서 backup을 할 수 있는 branch를 lecutre에 생성하고 checkout을 이용해서 backup branch에 class_1과 class_2의 값들을 가져올 것이다.

현재 back branch를 만들고 class_2의 fixed를 git checkout <commit-hash> -- <file-path>로 가지고 왔다.

위의 모든 과정들을 완료 한 상태이다 .이제 commit을 하면 될 것이다.

이제 commit을 하고 class_2 branch를 삭제하면 된다.

commit을 완료 한 모습이다.

이제 class_2 branch를 원하는 곳으로 reset을 하면 된다. 결과는 다음과 같다.

이제 여기서 강제 push를 하고 branch를 삭제하면 완료가 될 것이다. 물론 원격 저장소에 있는 branch도 삭제 하면 된다. 모든 과정이 완료된 모습은 다음과 같다.

backup branch 이름을 class_2로 변경하였다.

마지막으로 모드 branch들을 push하고 history 가지들을 보면 이상한 것이 있다. lecture branch에서 class_3를 생성하려는데 현재 lecture의 현재 위치가 과거에 있다 이를 class_2로 맞추어야 한다. 이것을 reset --hard으로 이동해보자.

현재 local의 lecture branch HEAD는 class_2를 가리키고 있다. 하지만 아직 원격 저장소는 과거에 있다. push를 해주면 된다. 단 이번에는 내가 push를 강제 push를 하지 않았다. 그랬더니 pr이 날라온다는 것을 기억하자 lecture이 현재는 어느 누구와도 merge가 되지 않았지만 만약 merge가 되어 있는 상황이라면 처음부터 lecture을 건드려서는 안되는 것이다.이제 class_3 branch를 만들어보자. class 3를 만들어도 위와 같이 가지가 뻗어지지 않는다. 그 이유는 아직 merge를 하지 않아서이다.(branch를 만들어낸 class_3 history가지 이미지 첨부를 못했지만 위와 같은 모양임을 인지만하고 다음 이미지를 참고하자.)

 

---

3. 강의 : merge하는 방법

• merge : 원하는 branch와 branch를 합치는 과정이다.
• 충돌이 일어 날 수 있다. 충돌은 다음 시간에 다시 알아 볼 것이다.
• merge하는 과정에서 합쳐질 branch와 수정 사항을 확인해야 merge가 승인이 된다.
• 헤드 브랜치(합쳐짐을 당하는 branch)에 변경사항이 없어야 한다.
• 병합 대상 브랜치가 헤드로부터 시작된 경우 아주 쉽게 병합이 가능하다.(Fast-Forward)
• 헤드 브랜치에 추가적인 커밋이 생기는 경우 진짜 병합이 필요해진다. 충돌이 날수도 있도 있으니 겁먹지 말라
• merge를 할 때 lecture branch인 상태에서 다른 branch merge를 가져와야 한다. 즉, 대에서 소를 가져오는 것이다.

main까지 병합한 모습이다. 사실 완벽하게 마음에들지는 않는다.우선 class_3가 class_2에서 가지를 친거 같아서 조금 아쉽다. 항상 한 작업을 모두 마무리하고 merge를 하는 것이 좋아 보인다. branch 생성은 soureTree보다 bash에서 실행하는 것이 더 좋아 보인다.

* 내가 만든 파일로 실습하기

merge를 했을 때의 모습은 아래와 같다.

 

merge를 하고나니 일렬이였더 가지가 우리가 원하는 모습의 가지로 변환이 되었다. 나머지 branch도 병합을 해보려하지만 현재 lecture가 뒤에 밀려 있어서 class_1,2,3보다 밀려있다. 규칙상 lecture은 변경이 되면 안되기 때문에 강제로 class_1으로 옮길 것이다. 

현재는 lecture이 class_1보다 먼저 앞서있다. 이제 나머지들을 merge해보겠다. merge할 대상 branch 환경에 있는 상황에서 merge를 해야한다. 위의 방법들에 오류가 있으니 마지막 부분의 주의를 잘 읽기를 바란다.

---

4강의 : 풀(pull) 하기

• git pull~ : 서버의 내용이 내 PC보다 최신일 경우 pull을 적용한다.
• 충돌이 날 수 있지만 놀라지 말자.
• pull = fetch + merge
• 충돌이 났을때
  • 현재 나의 branch를 변경함과 동시에 master나 다른 branch에서 변경사항이 있는 도중 내가 branch를 merge하려는 순간 충돌이 발생한다. 이때 직접 에디터에서 변경사항들을 확인하고 변경사항을 저장해준다. 그리고 커밋을 해준다.
  • 또는 '저장소 것으로 충돌 해결' 하는 방법을 사용하면 된다. 이는 코드가 많이 충돌 될경우 실행하면 좋다.

---

5강의 : 리셋(reset) 하기 - 비추

• git reset --hard ~ : 커밋을 되돌린다.
• reset 이후 git push ~ ~ --force는 강제 옵션을 선택해야한다.
• 이전 커밋이 사라진다.

---

6강의 : 브렌치를 만들어서 커밋 되돌리기 - 다시 들어보기

• 장접 :쉽다
• 단점 : 트리가 더러워진다.
• 과거로 돌아갈 위치에 브랜치를 만들어서 작업을 한다.

---

7강의 : Revert를 사용해 커밋 되돌리기

• Revert와 Reset의 차이를 생각해보기
  • 우리가 지금까지 '이 커밋 현재 브런치로 초기화'는 강제 reset --hard를 한것이다.
• push를 하기 전에 revert를 해야한다.
• 장점: commit을 남기고 이전으로 돌아가는 것이다.
• 단점: 충돌이 일어나가 쉽다.

pr에서 merge를 했을 경우에는 fetch를 하고 pull을 해오면 된다. 그리고 굳이 해당 브런치를 mrege할 필요는 없는 것이다.

+ 보너스 완료된 PR을 수정해 보자

PR을 하기 위해서 PR을 할 test파일과 lecture에서 PR_edit branch를 생성한다. 그리고 커밋까지 준비를 한다.

첫 번째 커밋

이제 여기서 부터 commit을 추가해서 다시 push를 할 것이다.

두 번째 커밋

이제 여기서 두번의 커밋으로 원격 저장소에서 PR은 커밋이 두개가 존재하고 그렇게 PR을 생성한다. 

PR커밋이 두개인것을 확인

기존에 하던대로 PR을 작성하고 원래는 merge까지해서 reset을 통해 수정 해보려고 했으나 우선은 현재 PR이 Assigin이 되기 전까지로 해보겠다.

우선 본인은 reset으로 '첫 번째' commit까지 내려가서 해당 branch를 강제 push --force를 해볼 것이다. 현재 branch는 PR_edit branch여야 한다.

현재 branch가 '첫 번째' commit으로 내려온 것을 확인 할수 있다.

이제 강제로 push해서 원격 저장소의 PR이 어떻게 되는지 확인해 보자.

성공적으로 PR이 수정되었음을 확인할 수 있었다. 그렇다면 반대로 merge를 한상태에서 commit을 변경할 수 있을지 실험 해보겠다.

다시 원상복구를 하고 merge를 실행해보겠다.

기존에는 rebase merge를 했지만 이번에는 Merge pull request를 해보겠다. (PR merge에는 세가지 mrege가 있다는 것을 알아두자.)

이렇게 fetch와 pull을 해서 merge request가 완료된 모습을 확인 할 수 있다.

merge를 완료한 PR이 과연 풀릴지 궁금한 순간이다. 우선 merge는 lecture로 되어 있는 것이다. 그러니 log를 확인 할땐 branch가 lecture인 상태에서 확인해야한다. lecture의 log 상태를 확인했으니 이제 reset으로 풀어보자.(안전하게 하기위해서는 현재 위치에서 backup branch를 하나 남겨둔 상태에서 진행을 해야한다.)

현재 lecture branch의 merge가 풀려 있는 상태이다.

이 상태에서 강제 push를 진행해 보겠다. (원래라면 강제 push를 굳이 할필요가 없어 보이긴 하나 경험을 위해 진행해 보겠다.)

현재 상태로는 merge가 풀려있다. 과연 원격 저장소는 어떻게 되어 있을까?

merge가 풀려 있지 않다. 결과적으로 원격 저장소가 현재 변경되지 않았다는 것이다. 그렇다면 원격 저장소는 동기화가 되지 않는다는 것인데 여기서 강제로 '첫 번째' 커밋까지 진행을 하고 강제 push를 한다면 어떻게 될까? (현재 lecture과 PR_edit branch를 모두 '첫 번째' 커밋으로 이동해야한다는 것을 인지해야 한다.)

 현재 모든 브랜치를 되돌려 놓았다. 이제 강제로 push를 하면 어떻게 될지 살펴보자.

PR은 변경되지 않고 새로운 PR을 생성해달라고만 한다. 즉 내가 생각한 모양으로 그려지지 않았다. 하지만 원격 저장소의 lecture은 정상적으로 변경이 되었다. 지금이라도 원격 저장소의 revert를 이용하게 되면 어떻게 될지 살펴 보겠다. 

이러한 경고창이 나오게 된다. 결과적으로 다시 돌아가기 위해서는 과거의 history 모양으로 만들어서 다시 맞춰야하는 것이다. 왜 reset이 위험한지 확인 할 수 있었다. 그렇다면 원격 저장소의 revert를 사용해서 내용을 변경해보자. 아까와 같은 상황을 다시 만들어 보겠다.

아까와 달리 push를 두번 해야했지만 커밋을 덮어씌웠기 때문에 이번엔 추가를 해보겠다.

아까와 같은 두번 째 PR이다. 이제 원격 저장소에서 revert를 해보자.

결과는 merge가 다시 열렸다. 사실 PR이 새로 열렸다기보단 Revert PR이 생성된 것이다. 그렇다면 이제 여기서 강제로 '세 번째' commit을 push를 한다면 어떻게 될지 확인해 보자.

Revert branch를 이용해서 없데이트 해야한다.

강제로 push를 했을 때 PR이 변경되지 않는다 그래서 커밋을 하고 통상적인 push를 했다너 Revert PR에 추가가 되고 의도치 않게 PR을 추가 하게 되었다. Revert PR의 결과는 아래와 같다.

이 방법이 최선이 될지는 확인이 필요하다.

rebase를 해야한다. 그래야 rebase merge 전략이다. Pr은 단순히 문서화 하기 위함이다.(rebase 강의 참고)

---

8강의 : revert로 여러 커밋 되돌리기

• revert의 특징 : 커밋은 없어지지 않는다.
• revert로 여러 커밋을 되돌리려면 최신부터 순서대로 revert 하자 그렇게 하면 충돌을 막을 수 있다.

---

9강의 : 브랜치와 스태시

• git commit --amend : 커밋 덮어쓰는 명령어로 sourceTree에서도 이전 커밋 덮어쓰기가 기능이 있다.
• 이미 push를 한 경우 push --force가 필요하다.
• git stash / git stash save : stash는 다른 브랜치로 체크아웃하기 전에 현재 작업내용을 저장하는 임시 저장소이다.
• sourceTree에도 stash가 있으니 GUI를 활용해서 더욱 편리하게 저장하고 불러올 수 있다.

---

10강의 : rebase로 병합하기

• merge처럼 두 브렌치를 합칠 때 사용한다.
• 현재 브랜치가 대상 브랜치 위로 올라간다.
• 위험도가 있으니 신중하게 생각하고 사용하자.

* rebase 실습

원하는 branch로 HEAD를 옮긴 상태에서 rebase가 되어야 하는 곳을 터미널에서 아래와 같은 명령어를 작성하면 된다.(study/1 -> lecture)

$ git rebase lecture

위와 같은 결과가 도출 된다.

---

+보너스 sourceTree에서 history를 보는 방법

branch가 3개(study/test/2,study/test/1,lecture)로 가지가 뻗어야 한다고 오해할 수 있다. 또한 study/test/2와 lecture이 파란색으로 되어 있어서 이 둘이 같은 tree 선상에 있다고 생각할 수 있다. 하지만 현재 lecture은 아무런 커밋이 없고 진행되는 사항이 study/test/2, study/test/1보다 뒤에 있는 것이다. 그래서 sourceTree는 lecture을 제외한 두개의 커밋만을 구벼하고 있는 것이다. 따라서 study/test/1과 study/test/2의 branch만 바라보고 가자의 브런치로 뻗어나간 것 뿐이다. 더 나아가서 여기서 우리가 lecture에 branch를 study/test/3를 추가하고 커밋을 하게 되면 study/test/2브런치가 study/test/1처럼 가지를 새로 뻗은 형태로 될 것이다. 물론 lecutre과 study/test/3는 같은 색상으로 유지가 될 것이다.