[220216][Git] 왕초보 특강_ upstream과 remote, commit, fork, clone에 대하여

우아한테크코스 4기 활동을 한지 일주일이 지났다.

git을 이용해서 clone, fetch, commit, push 등을 하고 있긴 하지만, 메뉴얼에 적혀있는대로 환경세팅을 하기 위해 진행해본거라 정확한 의미도 모른 채 기계적으로 명령어를 입력하면서 진행하고 있었기 때문에 git에 대해 아는 것이 너무나도 없었다.

 

다행히 이번에 Git 특강을 진행했고, 덕분에 궁금증을 조금이나마 해소할 수 있었다!

이번 포스팅을 통해 git과 조금 친해지는 시간을 가져보자.

---

Upstream과 remote가 뭘까?

우선 upstream과 remote의 영단어 뜻부터 보자.

 

upstream: 상류

remote: 원격

 

remote는 repository를 원격으로 관리할 수 있는 저장소를 의미한다.

우리가 git의 다양한 명령어로 저장소에 코드들을 올리고 코드리뷰를 받을 수 있는 이유도 remote를 통해 저장소 코드들을 접근할 수 있었기 때문이다.

git remote -v 명령어로 현재 remote에 어떤 저장소가 저장됐는지 확인할 수 있다.

현재 폴더의 .git 에는 remote에 origin이 저장돼있다.

위 origin 저장소는 remote에 등록돼있기 때문에 커밋, 푸시 등의 명령어로 원격으로 코드를 올리거나 받거나 할 수 있는 것이다~

 

그런데 upstream은 뭘까? 아래 그림을 보자.

출처: 우테코 git특강 강의자료

우리가 IDE에서 작업하는 코드들은 로컬에서 작업하는 코드들이다.

만약, 이 코드를 내 github repository에서 다운받아서 가져왔다면, 내 github repository가 한 단계 상위이자, 원격 저장소에 속한다.

그렇기 때문에 내 github repository가 remote에 속하게 되고, 로컬의 한 단계 upstream인 것이다.

만약 내 레포가 원본 레포를 fork한 것이라면, 원본 저장소가 내 저장소보다 한 단계 upstream인 것이다.

(fork가 무엇인지 모른다면 지금은 이해하지 못해도 괜찮다. 아래에 fork 내용이 설명돼있다.)

 

만약 fork를 하여 clone한 경우에는, 내 github repository 코드만 IDE로 가져온 것이기 때문에 내 github repository만 remote에 add돼있고, 원본 저장소는 remote에 add 돼있지 않은 셈이다. 만약 fork한 원본 저장소에 접근하고 싶을 경우 remote에 별도로 add를 해주어야 한다. (이 부분 역시 fork, clone이 무엇인지 모른다면 넘어가도 좋다.) 

 

git을 사용한다면 git push -u origin main 명령어는 한 번쯤 작성해보았을 것이다.

여기서 -u 의 의미는 --set-upstream 인데, local 코드를 내 원격 저장소(upstream)에 올리겠다는 의미의 --set-upstream을 축약해서 -u로 한 것이다.

---

Upstream에 commit할 때엔 어떤 일이 일어날까?

그럼 이제 upstream과 remote에 대해선 대략 느낌이 왔을 것이다.

이제 우리가 흔히 기계적으로 하는 add, commit을 할 때 어떤 일이 일어나는지 확인해보자.

 

먼저 commit을 하기 전에 우리는 git add . 를 하거나, git add {파일명}을 입력한다.

git add는 무슨 의미일까?

이 명령어를 입력하면 그 파일 (.일 경우 파일 전체)이 git의 관리 대상이 된다. 즉, git이 인식할 수 있는 대상이 되는 것이다. .git 폴더에 들어가면 object에 우리가 생성한 파일들이 들어가있는 것을 확인할 수 있다.

 

이제 commit에 대해 살펴보자.

commit은 git 기본 저장 단위이며, 작업 디렉토리 스냅샷을 의미한다.

즉, commit은 세이브 포인트나 다름 없으며, tree와 blob, 그리고 그 외 메타정보로 구성돼있다.

blob은 파일의 메타정보를 제외한 파일 전체의 내용을 담고 있다. 즉, blob에 우리가 작성한 코드들이 있다고 봐도 된다.

commit을 사용하면 발생하는 일. 출처: 우테코 git 특강

어떤 특정 커밋을 했다고 가정하자. 이 커밋 해시는 98ca9..이다. 이 때, commit은 이전 커밋의 파일과의 변경사항만 저장하는 것이 아닌, 전체를 저장한다. 변경사항만 저장할 경우, commit을 revert하거나, 파일을 되돌릴 때 속도 저하가 발생할 수 있기 때문이다.

 

commit에는 tree와 blob, 그리고 부모 commit에 대한 참조가 포함돼있다.

그렇기 때문에 이전 commit에서의 트리 객체를 통해 이전 커밋 내용을 확인할 수 있는 것이다.

이렇게 commit이 진행될 때마다 트리 객체끼리의 연결이 연이어 생기게 되는 것이다.

 

즉, 변경사항만 저장하는 것이 아닌, 전체를 저장하기 때문에 부모의 tree의 스냅샷과 현재 커밋의 tree의 스냅샷끼리 비교하여 변경된 부분을 인식할 수 있게 되고, 그렇게 해서 우리가 쉽게 변경사항을 확인할 수 있게 된다.

---

실습 (fork, clone, pull, review 기능을 이해해보자)

그럼 이제 실습을 진행해보자.

 

요구사항.

1. 특정 저장소의 코드를 팀원, 나 모두 fork하고 가져올 것.
2. 팀원이 먼저 자신의 브랜치 생성 후, 작업을 실시하면, 나는 팀원의 브랜치 코드만 가져와서 추가로 작업할 것.
3. 작업이 끝나고 팀원과 나 모두 PR을 날리고 서로에게 코드리뷰를 해줄 것.

   ---

우선 첫 번째는 어렵지 않다.

그냥 github 홈페이지에서 우측 상단에 fork 해주고, 자신의 깃허브 아이디를 클릭해 가져와주면 된다.

fork를 해주면 원본 저장소의 내용들을 내 github의 레포지토리로 가져와준다.

 

그 다음, clone을 해준다. 

clone을 해주면 그 저장소의 내용들을 내 로컬로 가져와준다.

즉, fork를 하고 clone을 해주면 원본 저장소(upstream) -> 내 저장소(origin) -> 내 로컬 로 코드를 가져오는 것이다.

clone의 경우 자동으로 remote에 내 레포가 add되기 때문에 아래 명령어만 쳐주면 됐다.

• git clone [fork로 가져온 내 저장소명]

---

두 번째 요구사항: 팀원의 특정 브랜치 코드 가져오기를 진행하기 위해, 먼저 내 remote에 팀원의 저장소를 add해주었다.

• git remote add [별칭] [팀원의 저장소명]

보통 별칭으로는 upstream을 많이 쓴다.

 

remote에 추가가 완료됐으니 git이 인식할 수 있는 상태가 됐다.

그 다음에 pull을 진행해주었다. 어차피 내 저장소엔 아무 코드도 없기 때문에 팀원이 작업한 코드를 pull로 가져오면 되는 상황이었다.

pull을 진행하면 그 저장소의 .git을 내 로컬로 가져와 준다.

• git pull [별칭] [팀원의 저장소명]

빨간색: 명령어, 초록색: 성공적인 결과

git pull을 했더니 자동적으로 팀원의 branch까지 가져와졌음을 확인할 수 있다.

 

이제 내 브랜치를 만들고 작업해주자.

• git checkout -b kth990303 (-b: 브랜치 생성, -d: 브랜치 삭제)
• git checkout kth990303

git branch -a는 전체 브랜치 조회 명령어이다.

빨간 박스 중에 git checkout kth990303을 했을 때, kth990303 브랜치가 없어 error가 뜬 것도 확인할 수 있다.

따라서 git checkout -b kth990303으로 내 브랜치를 만들어주고 git branch -a를 입력해주면 내 브랜치도 뜨는 것을 확인할 수 있다.

 

이제 작업 후 add, commit, push해주면 된다.

---

세 번째: 상대방의 PR에 코드리뷰를 달아주는 요구사항은 github 페이지에서 가능하다.

 

PR을 날린 경우에는 코드에 리뷰를 작성해줄 수 있다.

상대가 날린 PR의 코드에서 빨간박스로 칠해진 파란 + 박스를 눌러주면 리뷰를 작성할 수 있다.

 

리뷰를 작성하고 우측 Review changes를 submit 해주면 아래와 같이 코드리뷰완료!

- add single comment는 하나의 댓글을 달 때마다 리뷰가 추가되며, 하나의 피드백마다 상대방에게 알림이 간다.

- start a review는 여러 개의 리뷰를 한 번에 달아주며, 전체 review를 제출할 때에만 상대방에게 알림이 간다.

위와 같이 코드리뷰가 잘 작성됐음을 확인할 수 있다!

---

느낀 점

느낀 점은 이걸로 대체.

모바일에서 잘 보일지 모르겠다.

 

잘 안다고 생각했던 것들도 좀 당황하며 진행했던 하루였다.

역시 원리를 모른 채로, 기계적으로 내가 했던 습관들만 이용하다보면 언젠가는 큰코다칠 수 있음을 배우게 된 하루였다.

 

이번 레벨1 때는 java랑 더불어 git에 대해서도 열심히 공부해야겠다 ㅎㅎ