Git & GitHub basic git flow

Gaeun·2022년 12월 26일

TIL WeCode

wecode TIL

목록 보기

8/24

Git과 GitHub를 더 정확히 이해하기 위해 프론트엔드 강의를 훔쳐보며 정리하였다...😂

Git & GitHub

Git과 GitHub를 이용하여 작업할 때에는 크게 두 가지 공간이 있다.

Remote = origin: 원격 저장소, 즉 인터넷 상에 올라가 있는 저장소를 의미(GiHub)
Local: 내 컴퓨터 안에 존재하는 작업 공간

이미 GitHub상에 Repository가 존재하는 상황

Git Clone

$ cd [원하는 폴더] # 내가 원하는 폴더로 이동
$ git clone [repository 주소] # 프로젝트를 리모트에서 로컬로 클론
$ cd [프로젝트 폴더] # 클론이 진행되고 나면 하위 폴더로 프로젝트 폴더가 생김. 작업을 위해 해당 폴더로 이동

위 과정을 진행하면 성공적으로 리모트의 코드를 내 로컬로 가져올 수 있게 된다. 이후 로컬에는 최초로 default branch에 위치해있게 되는데 이는 master 혹은 main이라는 이름으로 지정되어 있다.

git을 이용해서 작업을 할 때는 default branch인 main에서 바로 작업을 진행하면 안 된다. 항상 모든 작업은 해당 작업을 위한 별도의 브랜치를 생성한 뒤 그 브랜치에서 작업을 진행하여야 한다.

branch 생성

$ git branch [branch 이름] # 새로운 브랜치 생성
$ git checkout [branch 이름] # 해당 브랜치로 이동 후 코드 작성
$ git add .
$ git commit # 작업 이력 남기기

commit을 통해 작업 이력을 남겼지만 아직 리모트에는 로컬에서 진행된 작업 이력을 모르고 있다. 따라서 로컬에서 작업된 진행 내역을 리모트로 올려야한다.

Git Push

$ git push origin [branch 이름]

위 과정은 origin이라는 리모트의 [branch 이름]이라는 브랜치에 내가 지금 한 작업을 올리겠다는 의미이다. 이렇게 되면 리모트에도 [branch 이름]에 대한 작업 내용이 올라가게 된다. 이제, 리모트에는 해당 작업이 생성되었지만 아직 default branch인 main에는 이 작업 내역이 없다.

따라서 main에 [branch 이름]의 작업 내용을 합쳐달라는 요청을 하기 위해서 Pull Request를 작성하여야 한다.

Pull Request

자신이 push한 commit의 메시지를 남기는 작업.
PR을 통해 브랜치의 작업 내역을 확인하고 관리자 또는 다른 팀원들이 의견을 남기고 확인한 후에 commit을 병합하는 과정.

Merge

Merge가 되고 나면 [branch 이름]에 작성한 코드가 origin, 즉 리모트 상의 main에 최신화되게 된다. 하지만 이는 github 상에서 PR을 등록하고 merge가 발생한 것이기 때문에 origin main은 최신화되어 있지만 로컬 상의 main은 이 내용을 모르고 있다. 따라서 origin main의 작업 내용을 내 로컬 main으로 가져오는 작업이 필요하다.

Git Pull

$ git checkout main # main으로 이동
$ git pull origin main # origin main의 내역을 내 로컬 main으로 가져오기

위 과정을 거치면 내 로컬 main의 코드가 최신화되게 된다.

이후 또 다른 작업을 진행하고 싶다면 main에서 새로운 브랜치를 생성해서 그 브랜치에서 현재까지 진행했던 과정을 계속 반복해주면 된다.

GitHub 상에 비어있는 Repository가 존재하는 상황

GitHub 상에 repository가 존재하기는 하지만, 비어있기 때문에 로컬에서 초기 세팅을 한 뒤에 리모트에 올려주어야 하는 상황이다.

위의 스크린샷은 프론트엔드 세션에서 뽀려온 것이라 2번의 내용은 내 상황(백엔드)과 맞지 않음을 기억해야 한다.!!!!

Branch 관리

1. 기능 단위의 브랜치 생성 후 작업

개발하고자 하는 기능에 따라 feature/[기능]과 같이 브랜치를 생성한다.
기능 단위로 브랜치를 생성하고 작업을 진행하게 되면 독립적인 공간(브랜치)에서 여러 개발자가 동시에 다양한 기능을 작업할 수 있다.
Git을 활용하면 기능별로 브랜치를 나눠서 작업한 뒤 작업이 완료되면 main 브랜치에 병합하는 방식으로 작업을 진행할 수 있게 된다.

2. 브랜치는 작은 단위로 나눠서 관리

브랜치는 작은 단위로 나눠서 관리하고 병합하는 과정을 거치는 게 좋다.
만약 하나의 브랜치에서 너무 많은 작업을 하게 된다면, 이 브랜치에서 어떤 목적을 가지고 어떤 작업을 했는지 파악하기가 힘들어지고, 브랜치의 작업 내용을 함께 확인하고 검토할 팀원들의 부담이 커진다.
또 하나의 브랜치에서 너무 많은 작업을 진행하게 되면, 최종적으로 main에 병합하는 과정에서 다른 브랜치와 작업 이력이 겹쳐서 발생하는 충돌(Conflict)이 대규모로 발생하게 된다.
이는 곧 브랜치의 병합에 어려움을 야기하고, 독립적인 브랜치에서 작업 후 main에 병합하는 Git을 활용한 작업 방식을 제대로 활용할 수 없게 만든다.

3. feature 브랜치에서 또 다른 브랜치 생성하지 않기

git의 모든 명령어는 현재 내가 위치하고 있는 브랜치 기준으로 동작한다. 브랜치 생성 또한 마찬가지이다. 새로운 브랜치를 생성하게 되면 생성하는 시점에 내가 위치한 브랜치의 작업 내역(커밋)을 모두 가진 상태로 새로운 브랜치가 생성된다.
브랜치들은 최종적으로 main에 병합되는 것이 목표기에 main을 기준으로 새로운 브랜치를 생성하는 것이 좋다.
만약 feature 브랜치에서 또 다른 feature 브랜치를 생성하게 된다면 main에 있는 작업 내용이 기준이 아니라, 생성하는 시점에 위치했던 feature 브랜치가 기준이 되어서 새로운 브랜치가 생성되는 것이기에 의도하지 않은 작업 내역이 새로운 브랜치에 포함되어 있을 수 있다. 이는 브랜치마다 독립적인 기능을 작업하는 작업 방식에도 부합하지 않으며, 추후 main에 병합하는 과정에서 충돌이 발생할 가능성이 커진다.
따라서, 명백히 의도하고 사용하는 경우가 아니라면 새로운 브랜치는 항상 main을 기준으로 생성하여야 한다.

(ex. feature/login 브랜치를 feature/nav에서 생성한 경우, 빨간 박스 때문에 충돌이 발생할 수 있다.)