[git, 오픈소스] 협업을 위한 git 사용 <part 3 : rebase & blame>

OSS 오픈소스 컨트리뷰톤 2020에 대한 내용은 여기로

PART 3 : rebase & blame

오픈 소스 협업을 진행하다보면, 충돌은 너무나 자연스러운 현상입니다. 특히, Part 2에서 언급했던 Pull Request는 언제나 충돌의 가능성을 가지고 있습니다.

만약, 다른 사람이 올린 PR이 먼저 merge된다면 같은 파일을 수정했던 사람들의 PR에 충돌이 발생하게 됩니다. 따라서 이러한 문제를 해결하려면 base 상태를 바뀌주는 rebase 과정이 필요합니다.

이렇듯 많은 사람들이 작업하다보면 코드가 계속 업데이트 되기 마련입니다. 그래서 규모가 큰 오픈소스들에 기여를 하기 위해서는 오류가 나는 코드가 언제 최초로 선언되었는지, 또 궁금한 지점의 코드가 어떻게 변화해왔는지를 살펴보는 것이 중요합니다.

이를 blame이란 명령어로 진행할 수 있습니다.

rebase의 일련의 과정은 되감기(rewind) + 풀기(continue)이다.

• rebase로 현재 상태를 변경 전의 최신상태로 되감기

# -i : interacive
# --root : rebase all reachable commits up to the root(s) 
# 도달할 수 있는 모든 커밋에 대해서, 되감을 시점을 선택할 수 있다.
# 변경하고자 하는 commit앞에 edit을 걸어주면 각 시점으로 되감아진다.
# 즉, -i 옵션으로 rebase를 부분부분 잘게 쪼개 진행할 수 있다.
git rebase -i --root

• rebase를 풀기

# 되감은 후 변경내용을 적용하고 풀면 rebase가 완료된다.
git rebase --continue

오픈 소스의 최신버전을 받아와, PR의 충돌을 해결해보자

• 오픈소스의 최신버전으로 rebase해 PR 충돌 해결하기

# 원 저장소의 최신버전을 가져온다.
# pull과 다른점은 강제 merge 과정이 없는것이다. 
git fetch upstream master
# fetch해온 최신 변경사항을 가져와 rebase한다.(자동 풀기+되감기)
git rebase upstream/master
# --force : force updates
# 해당 옵션을 통해 push하면 자동으로 PR에까지 적용되어 Merge 버튼이 활성화 된다.
git push --force origin master

단, fetch 해온것으로 rebase를 진행하고 다시 본인의 Commits들을 얹을때, 충돌이 발생할 수 있습니다. rebase전에 작업한 파일이 rebase에서 변경된 파일과 같을 수 있기 때문입니다.

이는 git status로 충돌 파일을 확인하고 충돌을 각각 해결해 준 후 commit 수를 늘리지 않기 위해 git commit --amend로 선언한 후 push를 진행하면 됩니다.

blame으로 소스를 누가 어떻게 수정했는지 찾기

• 특정 파일 기준으로 blame 실행하기
  • blame 상태에서 문자열을 검색할 때는 /[문자열] 형태로 타이핑한다.

git blame [filename]

• 파일이 선언된 최초 커밋 찾기
  • git reset --hard [commit ID]를 통해 해당 커밋으로 돌아가며 반복적으로 blame을 실행하여 찾을 수 있다.
  • 특정 함수나 생성자 기준이라면, '}' 기준으로 찾는것이 유리하다.
  • 또한 최초커밋을 찾으려면, 최신커밋이 아닌 오래된 순서부터 찾는 것이 유리할 수 있다.(--reverse)

# --reverse : 최초커밋-최신커밋 순서로 출력
# -p 커밋의 상세내용을 표기한다.
git blame --reverse -p [filename]

Reference

• 본 명령어들은 2020 오픈소스 컨트리뷰톤 사전 강의인 수강하고 정리한 내용입니다.
  • 강좌 : 오픈소스 101
  • 스피커 : 리얼리눅스 송태용님 [git]