# 마지막 커밋 해시
git log --pretty=format:'%h' -n 1%h 는 축약 해시 자리표시자다.1
# 유저정보
git config user.name
git config user.emailFootnotes
-
git-scm — PRETTY FORMATS:
%h— “abbreviated commit hash” ↩
git checkout -- <file>
git restore <file>
git reset --hardcheckout --·restore 는 파일을 인덱스 내용으로 되돌려서 add 해둔 변경은 남고, reset --hard 는 인덱스까지 HEAD 로 맞춘다.2
리모트 브랜치 가져오기
git remote update리모트 전체를 fetch 한다.3
Footnotes
-
명령어로 discard를 하려면 ↩
-
git-restore: “By default, if
--stagedis given, the contents are restored fromHEAD, otherwise from the index.” / git-reset--hard— “Update the index to match the new HEAD, so nothing will be staged.” ↩ -
git-remote
update— “Fetch updates for remotes or remote groups in the repository as defined byremotes.<group>.” ↩
.gitignore 는 이미 추적 중인 파일에 적용되지 않는다 — 인덱스에서 빼고(--cached) 다시 add 해야 규칙이 먹는다.1
# .gitignore가 규칙이 적용되지 않을때
git rm -rf --cached .
git add .Footnotes
-
Git - gitignore Documentation — DESCRIPTION: “Files already tracked by Git are not affected” / NOTES: “To stop tracking a file that is currently tracked, use git rm –cached to remove the file from the index.” ↩
git log포맷 · 마지막 커밋 해시- 변경 사항 버리기 —
checkout·restore .gitignore가 적용되지 않을 때- 다른 저장소 히스토리 합치기 —
--allow-unrelated-histories - 스택 PR — 서로 의존하는 PR 의 연쇄
- subtree
- submodule
- 이름 변경 추적
Footnotes
-
파일 이름이 변경되거나 새 디렉터리로 이동되었지만 콘텐츠의 절반은 그대로인 경우, 커밋 기록은 이제
git log --follow와 유사하게 파일 이름이 변경되었음을 표시합니다. ↩
git merge 는 공통 조상이 없는 히스토리를 기본으로 거부한다 — --allow-unrelated-histories 가 그 안전장치를 끈다.1
git remote add {alias} {url}
git fetch {alias}
git merge --allow-unrelated-histories {alias}/{branch}- [git] 서로 다른 repository 합치기 — Falcon
- How do you merge two Git repositories? - Stack Overflow
- How to merge git repositories preserving git history - JDriven Blog
- Git - git-mv Documentation
- Merging two GitHub repositories without losing commit history - Mozilla Hacks - the Web developer blog
Footnotes
-
Git - git-merge Documentation: “By default, git merge command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently.” ↩
스택 = 서로 의존하는 PR의 연쇄. 기능 브랜치는 main에서 분기하지만 스택은 부모 PR에서 분기한다 — 그래서 검토를 기다리는 동안 다음 조각을 이어서 작업할 수 있다.
병합은 스택 아래부터. 하나가 병합되면 그 위 PR의 base를 갱신해야 한다. git 기본 기능만으로도 되지만 리베이스가 계속 따라붙어서, Graphite·Sapling 같은 도구가 그 부분을 자동화한다.