[Git/GitHub🐱] 팀 개발을 위한 Git, GitHub 시작하기 DAY3

2월 11일에는 챕터 4인 <둘 이상의 원격저장소로 협업하기>를 학습했다. 직전 글에서 언급했던 문제를 해결했다. 다만 day2 이후로 폴더들을 전부 삭제하고 다시 복습했기 때문에 폴더명이 조금씩 다르다.
 

교재 실습하기

📌남의 저장소를 내 계정에 통째로 복제하기 (Fork)

❗실습을 위해 GitHub 계정을 하나 더 만들었다. 기존 계정 : yeonjae02, 새 계정 : chlduswo
❗새 계정으로 로그인한 상태에서 기존의 레포지토리를 찾아 Fork 버튼 클릭

❗소스트리에서 새로운 탭을 열어 클론을 클릭해서 새 계정의 원격저장소 주소를 넣는다.

과거 캡쳐라서 파일명이 조금 다릅니다.

❗소스트리를 새 계정으로 로그인한 후 기본계정으로 설정한다. 

like.md 파일을 만들어서 내용을 추가한다.

❗커밋 페이지 하단의 계정이 새롭게 추가한 계정이 아니라면 사람 아이콘 클릭 후 대체 작성자 정보 사용에서 새 계정  정보를 넣는다.

커밋 메시지를 작성 후 커밋한다.

❗push한다. -> ⚠️문제 발생⚠️

바로 이전 포스팅에서 올렸던 오류창이다.

✅ 소스트리에서 push 오류 해결법
https://github.com/Cat-Hanbit/README/issues/3

[질문][오류] 맥에서 GitHub push할때 permission 관련 오류가 발생합니다. · Issue #3 · Cat-Hanbit/README

내 환경은 맥은 아니지만 교재 Q&A에서 같은 문제를 찾았고 방법1을 사용했을 때는 되지 않았다. 그래서 방법1대로 원격 기능을 이용해서 클론한 상태에서 방법2대로 원격저장소 주소를 편집했다. 아래 그림처럼 수정한 후 확인을 누르고 Push하니 성공했다.

원격저장소 정보 수정

 

📌 원본저장소에 풀 리퀘스트 보내기

❗새 계정으로 로그인하면 풀 리퀘스트를 보낼 수 있다.

❗화살표 방향을 확인하고,  보내기 전에 변경 파일 정보를 반드시 확인한다.  설명을 적어 초록 버튼을 누르고 풀 리퀘스트 승인과 병합을 기다린다.

Able to merge : 충돌 없이 바로 병합이 가능하다.

❗기존 계정으로 로그인해 풀 리퀘스트를 확인한다.

좋아요 기능 추가를 클릭하면 코드를 확인할 수 있다.

❗코드 리뷰 후 승인한다.

코드 리뷰를 하고, 승인한다.

초록 버튼을 눌러 풀 리퀘스트를 병합한다.

초록 버튼 클릭

병합이 성공적으로 끝났다.

 

📌 묵은 커밋을 새 커밋으로 이력 조작하기 (rebase)

풀 리퀘스트를 보냈는데 코드 충돌이 난 경우, 내 브랜치로 먼저 병합하고 충돌을 해결한 후 다시 풀 리퀘스트를 보낼 수 있다. 하지만 충돌을 해결하느라 생긴 병합 커밋이 생기기에 변경한 부분만 풀 리퀘스트를 보낼 수 있는 방법이 rebase이다.

❗raccoon 폴더에서의 파일 수정 (새 계정에서 파일 수정)

커밋, 푸시

현재 히스토리

❗원본저장소에만 있는 커밋을 로컬저장소에 가져오기

원본저장소에서 Pull 받아오기

Pull 클릭

이제 원본저장소에서 받아올 커밋이 없는 최신 상태가 되었다.

❗충돌 상황을 만들기 위해 기존 계정으로 같은 부분 수정하기

기존 계정을 소스트리 기본 계정으로 변경한다.

새 계정에서 변경한 부분을 변경하기

커밋, 푸시

 

개발자 목록도 업데이트

 

커밋, 푸시

❗새 계정으로 풀 리퀘스트 보내기

코드 충돌이 발생했다.

 

❗여러 원격저장소 히스토리를 한 눈에 보기 : 리모트 추가 (Add remote)

소스트리 기본 계정을 새 계정으로 변경한다.

원본저장소 주소를 다른 이름으로 추가할 것이다.

추가 전에는 원격에 origin 하나만 있는 것을 확인할 수 있다.

원격저장소 추가 버튼을 누르면 현재 내 컴퓨터의 iTshirt-raccoon 로컬저장소에 연결된 원격저장소 주소를 볼 수 있다.

원본저장소를 지칭하는 관용적 닉네임 upstream으로 원격 이름을 정하고, 경로에 원본저장소 주소를 넣어준다.

확인을 눌러 저장한다.

upstream이 추가됐다.

upstream 원본저장소에 있는 커밋 히스토리를 받아온다 (Fetch)

upstream 아래에 이력이 추가됐다.

현재 히스토리는 다음과 같다.

❗ 묵은 커밋을 방금 한 커밋처럼 : 리베이스(Rebase)

새로운 베이스로 삼고 싶은 커밋을 우클릭해서 재배치를 클릭한다.

리베이스는 히스토리를 강제로 조작하는 것이므로 반드시 혼자만 쓰는 브랜치에서 수행해야 한다,

위에서 같은 코드를 수정했기 때문에 경고창이 나왔다.

충돌이 난 파일을 vscode에서 연다.

이와 같이 정리한다.

더 이상 문제가 없다.

rebase를 계속 진행한다.

리베이스가 완료됐다!

현재 히스토리는 다음과 같다.

이력을 조작했기에 강제 푸시해야 한다.

강제푸시한다.

원격저장소에도 리베이스한 커밋이 반영되었다.

충돌을 해결했으니 출 리퀘스트를 보낸다.

리베이스가 성공적으로 끝났다.

 
 

배운 내용 정리

⭐브랜치
- 하나의 원본저장소에서 분기를 나눈다.
- 하나의 원본저장소에서 코드 커밋 이력을 편하게 볼 수 있다.
- 다수의 사용자가 다수의 브랜치를 만들면 관리하기 힘들다.
⭐포크
- 여러 원격저장소를 만들어 분기를 나눈다.
- 원본저장소에 영향을 미치지 않으므로 원격저장소에서 마음껏 코드를 수정할 수 있다.
- 원본저장소의 이력을 보려면 따로 주소를 추가해야 한다.
- 포크한 시점 이후에는 원본저장소가 어떻게 변했는지 모른다. (원본저장소와 포크한 원격저장소는 주소까지 바뀐 서로 다른 원격저장소이다.)
⭐ 풀 리퀘스트
- 포크한 저장소에서 원본저장소로 풀 리퀘스트를 보내는 것이 성공하면 원본저장소로 페이지가 저장소가 자동으로 이동한다.
- 풀 리퀘스트는 모두 원본저장소에 쌓이기 때문에 자연스러운 현상이다.
⭐ 패치 (Fetch)
- 패치는 새로고침 기능으로, 원본저장소 이력을 업데이트한다.
- 소스트리는 10분 간격으로 자동 패치가 된다.
⭐ 리베이스 (Rebase)
- 커밋의 베이스를 떼서 다른 곳으로 붙이는 것
- 이력을 조작하는 것으로, 충돌이 발생하면 고친다.
- 이력을 조작하고 푸시할 때는 강제 푸시해야 한다.