Sevity Blog

오래된 base에서 열린 PR을 확인할 때는 최신 master와 PR branch의 merge-base를 기준으로 diff를 보거나, PR ref를 로컬 branch로 fetch해서 직접 검토할 수 있습니다.

원문은 PR branch를 최신 master로 맞추는 merge와 rebase, GitHub PR을 로컬에 가져오는 fetch 명령, Files changed 기준 diff 확인을 정리한 Git 메모입니다.

핵심 정리

Pull request를 로컬에서 확인할 때는 base branch와 head branch의 관계를 먼저 봐야 합니다. PR이 오래된 master에서 시작되었다면 단순 diff가 현재 master 기준과 다르게 보일 수 있으므로 merge-base를 기준으로 비교하면 실제 변경 범위를 더 명확히 볼 수 있습니다. GitHub에서는 pull request head ref를 fetch해 로컬 branch로 만들 수 있고, 원격 branch 이름이 남아 있다면 그 branch를 직접 pull해서 확인할 수도 있습니다.

• PR의 base branch는 변경을 합치려는 대상 branch입니다.
• PR의 head branch는 실제 작업 commit이 올라간 branch입니다.
• merge-base는 두 branch가 갈라진 공통 조상 commit을 찾을 때 사용합니다.
• merge-base부터 head까지 diff를 보면 PR이 의도한 변경 범위를 확인하기 쉽습니다.
• GitHub PR은 refs/pull 번호 head 형태의 ref로 로컬에 fetch할 수 있습니다.
• 최신 base 반영은 merge와 rebase 중 프로젝트 정책과 히스토리 관리 방식에 맞춰 선택합니다.

원문은 오래된 master 기준으로 열린 PR을 최신 기준에서 확인하고, PR 내용을 로컬 branch로 가져오는 방법을 정리했습니다. 보강 블록은 PR diff 기준과 fetch 절차의 목적을 먼저 설명하도록 다듬었습니다.

이어서 볼 글

• GitHub 기본 사용법: clone, push, pull, Pull Request - PR이 GitHub 협업 흐름에서 어떤 위치인지 확인하는 글이다.
• git branch 사용법: 생성, 전환, 삭제, 원격 브랜치 - PR 브랜치를 가져오고 전환하는 배경 글이다.
• git remote와 tag 명령어: 저장소 URL 변경, 태그 push, detached HEAD - remote branch fetch와 원격 주소 확인 흐름이 이어진다.
• git log 사용법: 커밋 기록, diff, 브랜치 그래프 - PR 변경 범위를 diff와 log로 확인하는 데 필요한 글이다.

branch생성시점의 master가 너무 오래돼서, 최신 master의 branch로 업데이트 하고 싶을때

방법1. merge

방법2. rebase

타인이 올린 PR의 Files changed를 터미널에서 확인하기

현재 master의 최신이 아닌 PR을 올린사람이 작업을 시작할때의 master가 기준이 됨에 유의

git fetch origin
git diff $(git merge-base origin/master origin/pr-branch-name)..origin/pr-branch-name

타인이 올린 PR을 내 로컬로 가져와서 검토하기

예를들어 위와 같은 PR이 올라왔다고 하자.

git fetch origin pull/51/head:bump-twisted 라고 치면 로컬에 "bump-twisted"라고 하는 브랜치가 생성된다(이것은 임의로 지정한 이름이며 생략하면 "pull/51/head"가 된다)

git branch를 해보면 아래처럼 bump-twisted라는 브랜치가 로컬 저장소에 추가된 것을 볼 수 있다.

$ git branch
* master
  bump-twisted

아직은 master를 바라보고 있어 PR의 내용이 로컬저장소에 반영되지 않았다.

git checkout bump-twisted 라고 치면 반영된다.

만약 PR을 올린사람이 merge전에 PR의 내용을 변경했다면

git pull origin pull/51/head:bump-twisted 다시 이렇게 치면 된다. 

위 방법대신

git branch -r을 해보면 다음처럼 이미 해당 PR들의 branch 들이 생성되어 있는 것을 볼 수 있는데,

(coin) sevity@raspberrypi:~/workspace/temp/coin_strategy $ git branch -r
  origin/HEAD -> origin/master
  origin/dependabot/pip/tornado-6.3.3
  origin/dependabot/pip/twisted-23.8.0
  origin/dependabot/pip/urllib3-1.26.18
  origin/master

여기서 해당 PR을 확인하고 git pull origin dependabot/pip/twisted-23.8.0:bump-twisted 이렇게 하는 방법도 있다.

git 초기 설정은 커밋 작성자 정보, 기본 에디터, GitHub SSH 접속을 미리 맞춰 두는 작업이다.

처음 저장소를 쓰기 전에 user.name과 user.email, editor, SSH key를 설정해 두면 커밋과 원격 push 과정에서 반복 오류를 줄일 수 있다.

핵심 정리

Git을 처음 설정할 때는 커밋에 기록될 사용자 이름과 이메일을 지정하고, 커밋 메시지를 편집할 기본 에디터를 정한다. GitHub를 SSH로 사용할 경우에는 공개키를 계정에 등록하고 원격 저장소 주소도 SSH 형식인지 확인해야 한다.

• user.name과 user.email은 커밋 작성자 정보로 기록된다.
• core.editor는 커밋 메시지나 rebase 편집 때 열릴 에디터를 정한다.
• SSH 키를 만들고 GitHub 계정에 공개키를 등록하면 비밀번호 입력을 줄일 수 있다.
• 원격 저장소가 HTTPS인지 SSH인지에 따라 인증 방식이 달라진다.
• git remote -v로 현재 원격 주소를 확인한 뒤 필요한 경우 변경한다.

초기 설정은 한 번 맞춰 두면 이후 clone, push, tag 작업의 인증 문제를 줄이는 기반이 된다.

이어서 볼 글

• GitHub 기본 사용법: clone, push, pull, Pull Request - 초기 설정 뒤 실제 GitHub clone, push, pull 흐름을 확인하는 글이다.
• git remote와 tag 명령어: 저장소 URL 변경, 태그 push, detached HEAD - remote URL과 tag push를 설정 이후에 이어서 확인할 수 있다.
• SSH 키 자동 로그인 설정: ssh-keygen과 authorized_keys - GitHub SSH 인증에 필요한 키 생성과 등록 배경 글이다.

git commit을 위한 사용자정보 등록. 커밋할때 누가 했는지에 대한 정보를 git이 알게 해줌.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

편집기를 vim으로 설정(초기 값은 nano로 되어 있음)

git config --global core.editor "vim"

git push를 위한 인증정보 설정(GitHub는 2021년 8월 13일부터 패스워드를 사용한 인증 방식을 지원하지 않음)

ssh키를 생성해서 github사이트에 등록해준다.

아래처럼 ssh-keygen실행후 ~/.ssh/id_rsa의 내용을 cat해서 복사한다음

 $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sevity/.ssh/id_rsa):
/home/sevity/.ssh/id_rsa already exists.
Overwrite (y/n)?

github사이트의 세팅에 들어가서 ssh키를 등록해주면 된다.

Setting > SSH and GPG keys > New SSH key

git log는 커밋 기록을 확인하고, 특정 변경이 언제 누구에 의해 들어왔는지 추적하는 Git 명령입니다.

단순 목록 확인에는 한 줄 요약 옵션이 편하고, 브랜치 흐름을 볼 때는 graph 옵션을 함께 사용합니다. 특정 커밋의 실제 diff를 확인하려면 git show나 patch 출력 옵션을 사용합니다.

핵심 정리

git log는 과거 기록을 보는 명령이지만 실제 용도는 버그 원인 추적과 리뷰 준비에 가깝습니다. 최근 몇 개 커밋만 보거나, 브랜치 그래프를 보거나, 특정 파일의 변경 이력만 좁혀볼 수 있습니다. 커밋 하나의 변경 내용을 자세히 보고 싶다면 git show가 더 직접적입니다.

• git log --oneline은 커밋을 한 줄씩 요약해 보여줍니다.
• git log -p는 각 커밋의 diff를 함께 보여줍니다.
• git log -p -2는 최근 두 개 커밋의 patch만 확인할 때 유용합니다.
• git log --graph --oneline은 merge와 branch 흐름을 보기 좋게 만듭니다.
• 특정 파일 이력은 git log -- 파일명 형태로 좁혀볼 수 있습니다.

git log를 잘 쓰면 언제부터 문제가 생겼는지 좁히기 쉬워집니다. 목록, 그래프, patch, 파일별 이력을 상황에 맞게 바꿔 보는 것이 핵심입니다.

이어서 볼 글

• git branch 사용법: 생성, 전환, 삭제, 원격 브랜치 - 브랜치별 커밋 기록을 확인하는 흐름이 이어진다.
• git remote와 tag 명령어: 저장소 URL 변경, 태그 push, detached HEAD - 태그와 detached HEAD를 log로 확인하는 흐름이 이어진다.
• Git PR 확인 방법: merge-base diff, PR branch fetch, rebase - PR 변경 범위를 diff와 log로 확인하는 후속 글이다.
• Git --no-ff 옵션: fast-forward와 merge commit 차이 - merge commit이 기록에 어떻게 남는지 확인하는 글이다.

git log -p 하면 기본적인 최근 diff화면을 보여준다.

git log -p -2 처럼 -2를 추가하면 최근 2개만 보여줌

git log --graph 하면 왼쪽에 트리그래프 나오면서 merge 상황등을 체크할 수 있음

git log --graph --oneline 하면 commit 하나당 한줄로 표시되어 그래프 merge상황 체크가 좀 더 쉬워짐

Git 저장소를 쓰다 보면 remote URL 변경, tag 생성과 push, detached HEAD 복구처럼 자주 나오지만 매번 헷갈리는 명령이 있습니다.

이 글은 Git의 전체 명령어를 넓게 나열하기보다 원격 저장소 주소 확인과 변경, 태그 관리, 태그 체크아웃 뒤의 HEAD 상태 복구를 한 흐름으로 묶어 정리합니다.

핵심 정리

git remote -v는 현재 origin이 어느 저장소를 바라보는지 확인할 때 사용하고, git remote set-url origin 새주소는 저장소 주소가 바뀌었을 때 사용합니다. tag는 로컬에 만든 뒤 git push origin --tags로 따로 올려야 원격에도 반영됩니다. tag를 checkout하면 detached HEAD 상태가 되므로 작업을 이어갈 브랜치를 만들거나 git checkout -로 원래 위치로 돌아오는 흐름을 함께 기억해야 합니다.

• git remote -v는 fetch와 push에 쓰이는 원격 저장소 주소를 확인합니다.
• git remote set-url origin 새주소는 origin의 URL을 새 저장소 주소로 바꿉니다.
• git tag는 로컬 태그 목록을 보고, git show 태그명은 해당 태그 정보를 확인합니다.
• git tag -a 태그명 -m 메시지는 주석이 있는 태그를 만들 때 사용합니다.
• git push origin --tags를 실행해야 로컬 태그가 원격 저장소에도 올라갑니다.
• git checkout 태그명 뒤에는 detached HEAD가 되므로 브랜치를 만들지 여부를 먼저 결정합니다.

태그는 배포 지점을 표시하는 데 유용하지만, 태그 체크아웃 상태에서 그대로 커밋하면 브랜치 흐름에서 떨어질 수 있습니다. 확인만 할지, 새 브랜치를 만들어 이어갈지 구분하면 실수를 줄일 수 있습니다.

이어서 볼 글

• GitHub 기본 사용법: clone, push, pull, Pull Request - 원격 저장소 작업의 전체 흐름을 확인하는 글이다.
• git branch 사용법: 생성, 전환, 삭제, 원격 브랜치 - remote와 함께 자주 쓰는 브랜치 작업 글이다.
• git log 사용법: 커밋 기록, diff, 브랜치 그래프 - 태그와 detached HEAD 상태를 확인할 때 커밋 기록을 보는 글이다.
• git 초기 설정: user.name, editor, SSH 키 등록 - remote push 전에 필요한 계정과 SSH 설정 글이다.

git remote -v 하면 repository url 확인 가능

git remote set-url origin 신규url 하면 repository변경 가능(ip가 바꼈다던가 할 때)

tag관련

git tag 하면 현재 달린 tag들 확인가능

git show v1.4 하면 태그 세부 정보 확인가능

git tag -a v1.4 -m "my version 1.4"  하면 버전 달고 메시지 쓸 수 있음

git tag -a v1.4 9fceb02 -m "my version 1.4" 하면 예전 commit에 대해서도 tag달 수 있음

git push origin --tags 이렇게 명시적으로 tag를 따로 push해줘야만 서버에 반영됨에 주의

git checkout v1.4 하면 해당 tag로 체크아웃 가능(근데 detached HEAD 상태가 된다)

git reflog 하면 detached 된 상태를 로그 히스토리 형태로 볼 수 있다.

git log --graph --decorate $(git rev-list -g --all) 하면 현재 HEAD가 어딘지 graph로도 볼 수 있다.

git checkout - 하면 detached 상태에서 원래 HEAD상태로 돌아간다. (tag 체크아웃은 풀린다)

git checkout -b version14 v1.4 하면 브랜치 만들면서 체크아웃 가능 

git branch는 작업 흐름을 분리하기 위해 브랜치를 조회, 생성, 삭제하는 Git 명령입니다.

브랜치는 독립된 작업 라인을 만들기 위한 포인터이므로 기능 개발, 버그 수정, 실험 작업을 main과 분리할 때 사용합니다. 로컬 브랜치와 원격 브랜치를 구분하면 삭제와 갱신 명령도 덜 헷갈립니다.

핵심 정리

git branch를 옵션 없이 실행하면 로컬 브랜치 목록을 보여줍니다. 새 브랜치를 만들고 전환하려면 최근 Git에서는 git switch -c를, 기존 방식에서는 git checkout -b를 사용할 수 있습니다. 원격 브랜치까지 확인하려면 git branch -r 또는 git branch -a를 사용하고, 원격에서 지운 브랜치가 계속 보이면 git fetch --all --prune으로 목록을 갱신합니다.

• git branch는 로컬 브랜치 목록을 확인합니다.
• git branch 브랜치명은 새 브랜치를 생성하지만 전환하지는 않습니다.
• git switch 브랜치명은 해당 브랜치로 전환합니다.
• git switch -c 브랜치명은 만들면서 바로 전환합니다.
• git branch -d 브랜치명은 로컬 브랜치를 삭제합니다.
• git branch -r과 git branch -a는 원격 브랜치 확인에 사용합니다.

브랜치 작업은 생성, 전환, 삭제, 원격 목록 갱신이 서로 다른 명령으로 나뉩니다. 현재 브랜치가 어디인지 먼저 확인하고 작업하면 pull, fetch, merge 흐름도 더 안정적으로 이어집니다.

이어서 볼 글

• GitHub 기본 사용법: clone, push, pull, Pull Request - 브랜치를 쓰기 전 원격 저장소 기본 흐름을 잡는 글이다.
• git remote와 tag 명령어: 저장소 URL 변경, 태그 push, detached HEAD - 브랜치 작업과 함께 원격 저장소 주소와 태그를 확인하는 글이다.
• git log 사용법: 커밋 기록, diff, 브랜치 그래프 - 브랜치 이동 전후 커밋 흐름을 확인하는 글이다.
• Git PR 확인 방법: merge-base diff, PR branch fetch, rebase - 브랜치 기반 PR 변경 범위를 확인하는 후속 글이다.
• Git --no-ff 옵션: fast-forward와 merge commit 차이 - 브랜치 병합 시 히스토리를 어떻게 남길지 판단하는 글이다.

여기 참조했습니다.

기본개념

git branch를 아무런 옵션 없이 실행하면 (local) branch 목록을 보여준다.

git branch -r 하면 원격 branch 목록을 보여준다.

git branch -d my_branch 하면 로컬에서 해당 branch를 삭제한다.

git push origin :my_branch 하면 원격에서도 삭제한다.

근데 이렇게 해도 git branch -r에서 계속 보인다면 git fetch --all --prune 하면 갱신된다.

아래 그림 좋아서 가져옴

단, 아래 그림에서는 Index(=stage)에서 workspace로 돌리는 명령어가 checkout으로 되어 있는데,

git 2.23부터는 "git restore --staged <file>" 이런식으로 restore를 써야함

위 그림에서 index = stage

git pull과 git fetch차이

fetch는 원격 저장소의 변경 사항을 가져오지만 로컬 저장소와의 병합은 수동으로 수행해야 하며,
pull은 변경 사항을 가져오고 자동으로 병합한다.
즉 git pull = git fetch + git merge

읽기쓰기 저장소가 다른 경우가 있을수 있다.

git branch -v 해보면 fetch와 push저장소가 나오는데, 보안등의 이유로 각각 다른 설정을 사용할수도 있다.(실제 그런 경우를 본적은 없다)

$ git remote -v
origin  git@github.com:sevity/online_judge.git (fetch)
origin  git@github.com:sevity/online_judge.git (push)

git branch 전략

GitHub 기본 흐름은 원격 저장소를 clone으로 내려받고, 로컬 commit을 만든 뒤 push와 Pull Request로 공유하는 과정이다.

Git은 로컬 커밋을 관리하는 도구이고 GitHub는 그 저장소를 원격으로 공유하고 리뷰하는 플랫폼이므로, 둘의 역할을 나누면 명령어 방향이 명확해진다.

핵심 정리

GitHub를 처음 쓸 때는 clone, commit, push, pull, Pull Request의 순서를 하나의 작업 흐름으로 잡는 것이 중요하다. 로컬에서 기록을 만들고, 원격에 올리고, 다른 변경사항을 받아오고, 협업에서는 PR로 리뷰 후 병합하는 방식으로 이해하면 된다.

• clone은 GitHub 원격 저장소를 로컬 작업 폴더로 복사한다.
• commit은 로컬 저장소에 변경 이력을 남기는 단계다.
• push는 로컬 커밋을 GitHub 원격 저장소로 올린다.
• pull은 GitHub의 최신 변경사항을 로컬에 가져와 반영한다.
• Pull Request는 변경 내용을 리뷰하고 main 브랜치에 병합하기 위한 요청이다.

GitHub 화면과 로컬 Git 명령을 따로 보는 것이 좋다. 커밋은 로컬 기록이고, push 이후에야 원격 저장소에 보인다.

이어서 볼 글

• git branch 사용법: 생성, 전환, 삭제, 원격 브랜치 - clone 이후 브랜치를 나누고 전환하는 다음 단계 글이다.
• git remote와 tag 명령어: 저장소 URL 변경, 태그 push, detached HEAD - 원격 저장소 URL과 태그 push를 다루는 GitHub 실무 후속 글이다.
• git log 사용법: 커밋 기록, diff, 브랜치 그래프 - push와 pull 전후로 커밋 기록을 확인하는 흐름이 이어진다.
• git 초기 설정: user.name, editor, SSH 키 등록 - GitHub를 처음 쓰기 전에 필요한 계정명과 SSH 설정 글이다.

내 github주소는 다음과 같다.

https://github.com/sevity

접속해보면 coin_strategy, ml등 여러가지 repository가 있고.. 예를 들어 이중 ml 이라는 repository를 리눅스 콘솔로 가져오고 싶으면 다음처럼 clone을 한다.

# git clone https://github.com/sevity/ml.git

Git의 --no-ff 옵션은 fast-forward로 합칠 수 있는 브랜치도 merge commit을 남겨 병합 기록을 보존하는 옵션입니다.

기능 브랜치가 main에 합쳐졌다는 흔적을 히스토리에서 명확히 보고 싶을 때 사용하며, 단순한 선형 기록보다 브랜치 단위 작업 흐름을 남기는 데 유리합니다.

핵심 정리

fast-forward merge는 현재 브랜치 포인터를 앞으로 이동시키는 방식이라 별도의 병합 커밋이 생기지 않습니다. 반대로 --no-ff를 사용하면 병합 커밋이 만들어져 해당 작업이 별도 브랜치에서 진행됐다는 사실이 기록에 남습니다. 기록을 깔끔한 직선으로 유지할지, 기능 단위의 병합 흔적을 남길지는 팀의 Git 히스토리 정책에 따라 달라집니다.

• fast-forward merge는 추가 merge commit 없이 브랜치 포인터만 앞으로 이동합니다.
• --no-ff는 fast-forward가 가능한 상황에서도 merge commit을 강제로 만듭니다.
• merge commit이 남으면 기능 브랜치가 언제 합쳐졌는지 히스토리에서 보기 쉽습니다.
• 작은 개인 작업에서는 선형 히스토리가 더 단순할 수 있습니다.
• 여러 커밋을 하나의 기능 단위로 묶어 보고 싶다면 --no-ff가 도움이 됩니다.
• 팀에서는 merge, squash, rebase 중 어떤 방식을 쓸지 미리 정하는 것이 좋습니다.

--no-ff는 항상 더 좋은 옵션이라기보다 히스토리를 어떤 모양으로 남길지에 대한 선택입니다. 브랜치 단위 맥락을 살리고 싶으면 쓰고, 커밋 흐름을 최대한 단순하게 유지하려면 fast-forward나 rebase 전략을 고려할 수 있습니다.

이어서 볼 글

• git branch 사용법: 생성, 전환, 삭제, 원격 브랜치 - 병합할 기능 브랜치를 생성하고 관리하는 선행 명령 흐름이다.
• git log 사용법: 커밋 기록, diff, 브랜치 그래프 - --no-ff로 남긴 merge commit과 브랜치 그래프를 확인하는 후속 흐름이다.

기본적인 fast forward merge와 3-way merge에 대해서는 http://devyongsik.tistory.com/624 여기를 보면 이해가 쉬웠다.

정리하자면, 둘 간의 차이점은 전자는 merge로 인한 추가 commit node가 발생하지 않는데, 후자는 발생한다는 점이고

이를 좀 더 쉬운말로 표현하면 fast forward merge가 발생할때에는 history를 볼때 branch 딴 것에 대해서 시각적으로 쉽게 확인이 안된다는 점이다.

https://i.stack.imgur.com/FMD5h.png

no-ff 옵션 자체에 대해서는 https://stackoverflow.com/a/21717431/208397 이 링크가 가장 이해하기 쉬웠다.