| En

Git stash의 apply와 pop

커밋하기 애매한 변경이 남은 상태에서 브랜치를 바꾸면 Git이 막는다. $ git checkout develop error: Your local changes to the following files would be overwritten by checkout: file.txt Please commit your changes or stash them before you switch branches. Aborting git stash는 작업 디렉터리의 변경을 임시 스택에 저장하고 디렉터리를 HEAD 상태로 되돌린다. 변경은 사라지지 않으며 나중에 다시 꺼내 적용할 수 있다. 명령 자체는 단순하지만 apply와 pop의 동작 차이, 그중에서도 pop이 충돌했을 때의 동작에서 실수가 자주 나온다. ...

2024년 7월 26일 · 3 분 · 471 단어 · In-Jun

GitHub CLI로 Pull Request 관리

PR을 만들고 CI를 기다리고 리뷰하고 머지하는 흐름은 보통 브라우저 탭을 여러 번 오가게 한다. GitHub CLI(gh)로는 이 과정을 터미널에서 끝낼 수 있다. 설치는 OS별로 다르니 공식 설치 안내를 참고한다(macOS는 brew install gh, Ubuntu/Debian은 sudo apt install gh). 설치 후 인증을 한 번 한다. gh auth login 브라우저 기반 OAuth가 가장 간단하다. 인증 여부는 다음으로 확인한다. $ gh auth status github.com ✓ Logged in to github.com account in-jun (keyring) - Active account: true - Git operations protocol: https - Token scopes: 'gist', 'read:org', 'repo', 'workflow' 1. PR 만들기 먼저 브랜치를 만들고 작업을 push한다. ...

2024년 7월 19일 · 4 분 · 731 단어 · In-Jun

Git 커밋 히스토리 정리

로컬에서 기능 하나를 만들다 보면 커밋 히스토리가 이렇게 쌓인다. f16a902 Add logout feature fbfb5b2 Fix login button style 6cc4fec Add missing import cacd382 Fix typo in login 0559677 Add login feature Fix typo, Add missing import, Fix login button style는 전부 Add login feature에 들어갔어야 할 수정이다. 작업 중에 자주 커밋하는 것 자체는 문제가 없다. 잃어버릴 일이 없고 되돌아갈 지점이 많다. 다만 이 상태로 push하면 리뷰어가 의미 없는 커밋 4개를 읽어야 한다. ...

2024년 7월 13일 · 3 분 · 604 단어 · In-Jun

병합된 Git 브랜치 삭제

PR을 머지하고 나면 로컬에 쓸모없어진 브랜치가 쌓인다. 몇 달 지나면 git branch 출력이 한 화면을 넘기고 작업 중인 브랜치를 찾기 어려워진다. 정리 명령은 간단하다. 무엇을 지워도 안전한지 구분하는 것이 관건이다. -d는 안전하고 -D는 위험하다 로컬 브랜치 삭제 명령은 두 가지다. git branch -d는 이미 병합된 브랜치만 지운다. 병합 안 된 커밋이 남아 있으면 거부한다. $ git branch -d feature/login Deleted branch feature/login (was 13d794b). $ git branch -d feature/experimental error: the branch 'feature/experimental' is not fully merged hint: If you are sure you want to delete it, run 'git branch -D feature/experimental' feature/login은 main에 병합됐으니 바로 지워졌고, feature/experimental은 고유 커밋이 남아 있어 거부됐다. 이 거부가 작업을 실수로 날리지 않게 막는다. ...

2024년 7월 11일 · 3 분 · 513 단어 · In-Jun

Git 커밋 타임스탬프 조정

Git 타임스탬프의 구조 Git의 타임스탬프 시스템은 2005년 Linus Torvalds가 Git을 만들 때부터 두 가지 시간을 별도로 기록하도록 구성되었다. 이는 Linux 커널 개발의 특성상 패치를 작성한 시간과 실제로 커밋된 시간이 다를 수 있기 때문이다. AuthorDate와 CommitDate Git 커밋은 두 가지 타임스탬프를 가진다. AuthorDate는 코드를 처음 작성한 시간, 즉 원저자가 변경을 만든 시간을 나타내며, git commit --date 옵션이나 GIT_AUTHOR_DATE 환경변수로 설정된다. CommitDate는 커밋이 실제로 저장소에 기록된 시간을 나타내며, rebase, cherry-pick, amend 등으로 커밋이 재생성될 때마다 갱신되고, GIT_COMMITTER_DATE 환경변수로 설정할 수 있다. ...

2024년 5월 25일 · 4 분 · 790 단어 · In-Jun
[email protected]