Git & Github - branch, Fork, Pull Request

박정호·2022년 11월 2일

Git&Github

git + GitHub

목록 보기

2/3

⭐️ branch

개발 작업시 개발자들은 작업 레파지토리에서 소스 코드를 공유한다. 만약 A 작업과 B작업이 있을 경우 A 작업이 다 끝난 뒤에 B 작업을 수행한다면 비효율적이다.

따라서, 별도로 작업하여 합치는 방안이 있고 Git에서는 branch와 merge라는 명령을 사용하게 된다.

브랜치는 독립적인 작업을 할 수 있는 공간이다. A기능을 A브랜치에, B기능을 B브랜치에서 서로 다른 독립적인 공간에서 작업을 할 수 있다. 이는 서로에게 영향을 주지 않는다.

즉, 메인 작업 공간의 코드를 복사한 개별적인 작업 공간을 만들고 거기서 각각의 기능 개발을 진행한다. 그리고 코드를 합치면 된다.

✅ 예시

개리가 개리1, 개리2, 개리3이라는 커밋을 남기며 기본 브랜치에 작업 중
빙키가 개리의 프로젝트에 참여
개리가 작업한 내역을 기본브랜치에서 pull받기
개리3을 커밋한 부분에서 작업 공간 기능 브랜치로 분리
이제 빙키는 분리된 작업공간에서 독립적인 진행 가능

✅ 개발자는 기능 브랜치에서 작업한 내용을 기본 브랜치로 바로 commit을 날릴 수 있고 코드를 merge하고 업데이트 할 수 있다.

브랜치로 작업을 하면 브랜치 단위로 업데이트가 되기 때문에 충돌이 일어나는 일을 방지하기 좋다.
만약 서로 같은 부분을 다르게 수정하면 충돌이 나고, 충돌이 나면 둘 중 하나를 선택하라는 선택이 뜨며 되돌릴 수 있다.

✅ git에서의 기본 브랜치는 master 브랜치(GitHub은 main)이다.

기본브랜치는 git 저장소를 초기화할 때 자동으로 만들어진다.
이때, HEAD'라는 특수한 포인터가 있다. 이 포인터는 지금 작업 중인 브랜치를 가리킨다.

💡 기본 브랜치(main, master)

앞에서 언급했듯, git에서의 기본 브랜치는 master이고 GitHub에서의 기본 브랜치는 main다.

✔️ git init 명령을 통해 초기화하고 레포지토리에 연결하는 과정을 진행하게 되면 기본 브랜치는 master가 된다.

✔️ git config --global init.defaultBranch main 로 설치 시 또는 설치 후 설정을 통해 기본 브랜치 이름을 바꿀 수도 있다.

✔️ 깃허브에서 제공하는 초기화 설정을 사용하거나 가이드라인을 따라 진행한다면 기본 브랜치가 main이 된다.

✅ 하나의 기능 개발이 완료되면 특정 브랜치의 내용들을 main 브랜치에 합친다.

또 새로운 작업을 하려고 하면 main 브랜치에서 다시 새로운 feature 브랜치를 생성하고 작업한다.

✅ 특정 기능을 작업하고 있는데 급하게 버그를 수정해야 하는 경우가 발생

현재의 작업 상태를 임시로 커밋해두고 이전 기능 작업 중인 상태로 브랜치(작업폴더)를 변경 가능
버그 패치용 브랜치를 만들고 수정 작업. 이후 작업이 완료되면 버그 패치용 브랜치의 추가된 변경 내역을 main 브랜치에 합치기 가능

👉 이런 과정을 거치면 main 브랜치는 가장 최근에 배포한 소스코드의 커밋을 가리키고 있게 된다.

branch 사용방법

✅ 현재 브랜치 목록과 현재 브랜치 확인

$ git branch

✅ branch 만들기

$ git branch 브랜치명

💡 branch naming

기호(-)로 시작할 수 없다.

마침표(.)로 시작할 수 없다.

연속적인 마침표(..)를 포함할 수 없다.

빈칸, 공백 문자, 물결(~), 캐럿(^), 물음표(?), 별표(*), 대괄호([ ]) 등은 포함할 수 없다.
아스키 제어 문자는 포함할 수 없습니다.

참고하자! branch 네이밍 규칙

✅ Branch 이동/변경, 파일 복원하기

checkout을 통해 브랜치를 이동하여 사용할 수 있다.

하지만 기존의 checkout이 가진 기능이 너무 많기 때문에 Git 2.23에서 checkout을 대신해 switch와 restore가 도입되었다.

✔️ switch

브랜치를 변경

$ git switch Gary

브랜치 생성 후 변경

$ git switch -c Gary

✔️ restore

restore는 파일의 수정 내용 복원과 add 를 통해 스테이지에 올린 파일을 빼낼 때 사용

1. 파일을 생성한 후 커밋
2. 수정 후 저장.
3. modified(수정) 파일이 있다는 것을 확인

👉 파일 변경 내역을 modified 파일에서 unmodified 파일로 되돌리는 방법은 두 가지

restore을 이용하여 변경 사항을 되돌리기

$ git restore README.md

checkout을 이용하여 파일 변경 내역을 되돌리기
- git checkout -- filename 은 해당 파일 내용이 최신 커밋 전으로 돌아가도록 한다. 이때, checkout으로 지워진 내용은 커밋을 하지 않았기 때문에 다시 복구할 수 없다.

$ git checkout -- README.md

✚ 스테이지 올린 것을 빼는 방법

상태 확인 시 stage에 수정된 파일 존재
$ git add .
$ git status
1) restore 명령어를 이용하여 빼기
$ git restore --staged README.md
2) reset 명령어를 이용하여 빼기
$ git restore --staged README.md

✅ git push 에러 발생 with upstream branch

항상 push 할때마다 뜨는 에러 코드가 있다.

✔️ 에러가 발생하는 이유는 upstream 브랜치를 설정하지 않았기 때문.

그렇기 때문에 git push --set-upstream origin branch_name 명령어를 이용하여 해당 명령어 이후부터는 원격 저장소에 브랜치를 만들어 push 하겠다는 뜻.

💡 git push vs git push <원격저장소명> <브랜치명>

왜 git push origin main일까? git push하면 안되나?

✔️ git push <원격저장소명> <브랜치명> 는 어느 원격 저장소의 어느 브랜치에 push할 지 전달한다.

✔️ git push 는 할 때에는 이미 연결된 곳에 push할 수 있지만, 원격 저장소에 해당 브랜치가 없는 경우에는 git push -u origin <브랜치명> 을 실행해주셔야 이후에 간단히 push할 수 있다. -u 옵션이 --set -upstream 이다.

✅ Branch 삭제/복구하기

✔️ 특정 브랜치를 삭제

git branch -D <삭제할 브랜치명>

✔️ 특정 브랜치를 복구

1️⃣ 1단계. git reflog로 복구 시점 확인

먼저, 삭제한 브랜치를 어떤 시점으로 복구할 것인지 파악한다. 삭제한 브랜치가 남겼었던 커밋 중 어떤 상태로 돌아갈 지를 찾아서 커밋 해시값을 가져와야 한다. 따라서 모든 참조 목록을 확인 할 수 있는 git reflog를 입력한다.

$ git reflog

💡 reflog는 모든 참조 내역들을 뜻한다. main 브랜치에서 어떤 브랜치로 참조를 했는지, 어떤 커밋을 날렸는지 등 모든 내역들을 ₩git reflog₩를 통해 확인할 수 있다.

2️⃣ 2단계. git checkout으로 브랜치 복구

$ git checkout -b <삭제한 브랜치명> <커밋 해시값>

✅ merge(합병)하기

branch로 나누어 작업했던 것을 병합하는 명령어

$ git checkout main
$ git log //커밋 히스토리 조회하기
$ git merge binky
$ git log

merge가 완료되었으면 push 까지 해주셔야 원격 저장소에 반영

$ git push origin main

✅ conflict (충돌)

만약 main으로 이동한 후 브랜치1와 merge했다고 하자. 그리고 브랜치2와도 merge를 하였다.
이때 브랜치1와 브랜치2의 같은 영역을 작업했고 수정사항이 서로 다르다면?

✔️ merge할 때 두 브랜치가 같은 곳을 수정했다면 충돌이 일어나고, 수동으로 고쳐줘야 한다.

<<<<<<< HEAD (Current Change)
hello world
hello branch1
=======
>>>>>>> branchName (Incoming Change)
hello world
hello branch2

conflict는 두가지 변경 내역을 비교한 다음에 원하는 코드를 남기는 것이다.

hello world
hello branch1 branch2

이후 add > commit > push 를 해주시면 된다.

💡 Visual Studio Code 에서의 Conflict

visual studio code에서는 충돌에 대해 좀 더 자동화된 도구를 제공.

⭐️ Fork

fork는 다른 사람의 Github repository에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 respository를 내 Github repository로 그대로 복제하는 기능이다.

fork한 저장소는 원본(다른 사람의 github repository)와 연결되어 있다. 여기서 연결 되어 있다는 의미는 original repository에 어떤 변화가 생기면(새로운 commit) 이는 그대로 forked된 repository로 반영할 수 있다. 이 때 fetch나 rebase의 과정이 필요하다.

다시 말해 기여자 등록을 따로 하지 않아도 Fork기능을 사용하여 원본 저장소를 복사해 내 저장소에서 commit > push 할수 있다. 기능 생성 후, 내 저장소 브랜치와 빙키와 개리의 저장소의 브랜치에 merge를 하면 된다.

💡 실제로 입사 과제를 할때 Fork로 과제를 복사하고 과제 수행 후 pull request 하는 경우가 많다.

사용방법

1️⃣ 복사하고자 하는 Github 레파지토리에 들어가서 오른쪽 상단에 Fork를 클릭.

2️⃣ 포크한 저장소를 클론하기 위해 주소 복사 버튼을 클릭

3️⃣ 저장하고 싶은 곳으로 이동한 후, 클론

$ cd 저장하고_싶은_디렉토리
$ git clone 복사한_git주소 .

4️⃣ 원격 저장소 이름들을 가지고 옵니다.

Fork한 사람은 원본 저장소의 변경 이력을 볼 수 없다. 원본 저장소와 알리의 저장소는 다르기 때문에 원본 저장소의 이력을 보고 싶은 경우에는 원본 저장소를 원격 저장소에 추가해야한다.

//원격 저장소 이름들을 가지고 오기
$ git remote

// 새로운 원격 저장소를 추가
$ git remote add 새로운_원격저장소_이름 fork한_git주소

//로컬 저장소에는 없지만 원본 저장소에 있는 데이터를 가져오려면 fetch 명령어를 입력
$ git fetch 새로운_원격저장소_이름