Git Rebase & GitHub Pull Request

Jiwon·2021년 5월 9일

Git

목록 보기

5/8

Git Rebase

rebase를 사용하면, merge commit이 생성되지 않고, 최신 HEAD 뒤에 순차적으로 commit 내용을 붙일 수 있다.

잠시 commit을 뒤로 돌리고 rebase 시켜보자.

git reset --hard HEAD~

log를 보면

board.txt 전으로 돌아간 것을 볼 수 있고
병합과정을 sourcetree에서 진행시키면 merge과정 없이 진행된 것을 볼 수 있다.
(원래는 main이 login브랜치를 따라가고 있어서 board브랜치 내용을 병합시키려면 충돌이 발생 했었는데 board브랜치에 rebase 시키면서 순차적으로 따라가게 시킨 것)

로컬에서 작업하는 경우 history를 정리하기 위해 rebase하는 경우도 많지만
remote 등 어딘가로 push 한 다음에 rebase하는 것은 좋지 않다.
rebase하는 순간 그 전의 commit들에 대해서 충돌을 전부 해결해야 되는 경우가 있기 때문에 좀 더 고려해 본 다음에 쓰는 것을 권장한다.

코드리뷰 ( GitHub Pull Request)

코드 리뷰
: 한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검하고, 피드백을 주는 과정

피드백이란 오타, 버그 가능성, 개발 표준 등에 대한 의견이 될 수도 있고, 좋은 코드에 대한 긍정적인 피드백이 될 수도 있다.

장점으로는
1. 버그의 조기 발견
2. 개발 표준 준수
3. 중복 코드를 방지하고 모듈의 재사용성 증대와 같은 것들

Pull Request
: 내가 변경한 코드들을 다양한 사람들이 리뷰하는 방법
(코드리뷰와 비슷)

보통 코드리뷰는 새로운 브랜치를 통해서 코드리뷰를 작성하는 것이 대부분이다.

qna 브랜치를 만들고 파일을 만든 후 커밋하자

push하면 이번에도 로컬에만 생성됬기 때문에 에러가 발생할 것이다.
똑같이 제시해주는 코드를 복사 붙이기 해서 실행시켜주면 된다.

웹 상에서 보면 잘 들어와 있고

Pull Request를 봐보자
1분 전에 qna가 생성됬다고 떠 있는데 그 밑에 New pull request를 클릭하고

create pull request를 클릭

메세지 작성

작성된 것을 확인할 수 있다.

file changed를 보면 파일이 어떻게 변경 되었는지 볼 수 있다.
해당 파일이 비었기 때문에 Empty file이라고 되어 있는 것을 볼 수 있다.
파일이 잘 추가되었다는 것만 보자

a.txt를 수정하고 rm으로 board.txt를 지워보자

add . 로 모든 변경사항을 추적하고, commit