Git &amp; Tips

예를 들어 마지막 세 번째에 있는 커밋 로그를 수정하고 싶다면 rebase -i를 사용해서 수정한다. 주의할 점은 이미 서버에 push된 커밋은 SHA-1 값이 바뀌기 때문에 가능하면 수정하지 말아야 한다. 만약 rebase에 익숙하지 않다면 다음을 주의 깊게 봐야 한다. https://git-scm.com/book/ko/v1/Git-도구-히스토리-단장하기

$ git rebase -i HEAD~3

텍스트 편집기가 열리면 다음 같은 커밋 목록이 첨부되어 있다.

pick ...
pick ...
pick ...

여기서 커밋 목록 순서는 위쪽이 오래된 것이다. 마지막 세 번째 커밋 메시지를 수정하려면 pick을 edit로 변경하고 저장 및 종료한다.

edit ...
pick ...
pick ...

저장하고 편집기를 종료하면 Git은 목록에 있는 커밋 중에서 가장 오래된 커밋으로 이동하고, 아래와 같이 다음은 어떻게 해야 하는지 메시지를 보여준다.

$ git rebase -i HEAD~3
Stopped at 7482e0d... updated the gemspec to hopefully work better
You can amend the commit now, with

       git commit --amend

Once you’re satisfied with your changes, run

       git rebase --continue

마지막 커밋 메시지를 변경했을 때와 같이 git commit --amend 으로 메시지를 변경하고 git rebase --continue로 rebase를 계속한다. 이것을 반복하면 어떤 위치의 커밋 메시지도 수정할 수 있다. 다시 말하지만 주의할 점은 이미 서버에 push된 커밋은 rebase를 하면 SHA-1 값이 바뀌기 때문에 동료 개발자들을 혼란스럽게 할 가능성이 있다. 될 수 있으면 수정하지 말아야 한다.

3. rebase #

3.1. 커밋 합치기 #

git rebase -i HEAD~3 는 HEAD부터 3개의 커밋을 대상으로 interactive rebase를 연다.

커밋이 다음처럼 있다고 가정하면,
a <- b <- c <- d(HEAD)

$ git rebase -i HEAD~3

interactive editor에는 보통 이렇게 뜬다.

pick b
pick c
pick d

예를 들어 세 커밋을 하나로 합치려면 interactive editor에서 내용을 다음과 같이 수정하고 저장한다.

pick b
squash c
squash d

b 커밋을 기준으로 b+c+d를 합친다.

※pick이 하나도 없으면 어떻게 되나요?
rebase가 에러로 멈춘다. squash는 "바로 위 커밋에 흡수"되는 동작인데, 맨 첫 줄이 squash이면 흡수될 대상(위 커밋)이 없기 때문이다.
다음과 같은 에러 메시지가 나오고: error: cannot 'squash' without a previous commit
Git이 편집 화면을 다시 열어주므로, 맨 첫 줄을 pick으로 바꾸고 저장하면 정상 진행된다.

3.2. squash와 fixup의 차이 #

둘 다 커밋을 병합하지만 squash로 합치면 합쳐지는 커밋들의 메시지가 모두 합쳐진 채로 편집 화면에 나타난다.

fixup은 합쳐지는 커밋들의 메시지를 버리고 기준 커밋 메시지만 유지한다. 즉 코드 오타 수정처럼 메시지가 필요 없는 경우.

3.3. reword와 edit의 차이 #

둘 다 커밋을 수정하지만 바꾸는 대상이 다르다.

reword(r)는 커밋 메시지만 수정한다. rebase가 진행되다 해당 커밋에서 멈추고 메시지 편집 화면만 열어준다. 내용을 고치고 저장하면 자동으로 다음으로 넘어간다. 변경사항(코드)은 건드리지 않는다.

edit(e)는 커밋 자체를 수정할 수 있게 멈춰준다. 해당 커밋 시점에서 rebase가 일시정지하고 셸로 돌아오는데, 이때 파일을 고치거나 git commit --amend 등 원하는 작업을 할 수 있다. 작업이 끝나면 git rebase --continue로 직접 다시 진행시켜야 한다.

3.4. 인터랙티브 rebase의 모든 명령과 단축 약자 #

p = pick
s = squash
f = fixup
r = reword
e = edit
d = drop

4. log #

4.1. log .. 커밋 범위 지정하여 로그 보기 #

$ git log START_COMMIT..END_COMMIT
ex) git log ea87e9..60a6da

4.2. log --since= 특정 날짜 이전/이후 commit만 출력 #

$ git log --sinceafter,until,before
ex) git log --before="2018-07-15"

4.3. log -N 개수 출력 #

$ git log -2
2개만 출력

4.4. log --pretty= commit 메시지의 첫 번째 줄만 출력 #

$ git log --pretty=short

4.5. log -p 특정 브랜치 변경된 내용을 출력 #

$ git log -p <브랜치이름>

$ git log -p <브랜치이름> -- <파일/경로/이름.cpp>
특정 브랜치의 특정 파일 변경된 내용을 출력

4.6. log --graph 브랜치를 시각적으로 출력 #

$ git log --graph

5. show #

5.1. 기본 사용법 #

$ git show
현재 브랜치의 가장 최근 커밋 정보를 확인

$ git show 커밋해시값
특정 커밋 정보를 확인

$ git show HEAD
HEAD 포인터가 가리키는 커밋정보를 확인

$ git show HEAD:/파일/경로/파일이름.cpp
HEAD 포인터의 파일 내용을 확인

6. branch #

6.1. 브랜치 확인 #

현재 브랜치
$ git branch
모든 브랜치
$ git branch -a

6.2. 브랜치를 만들고 변경 #

예) <new-branch> 브랜치로 변경
$ git checkout -b <new-branch>

checkout -b는 git branch <new-branch> 브랜치를 만들고, git checkout <new-branch> <new-branch> 브랜치로 이동하는 것과 동일함.

6.3. 브랜치 제거 #

$ git branch -D <branch-name>

6.4. 커밋 ID로 브랜치 찾기 #

커밋 ID로 어떤 브랜치에 속하는지 찾을 수 있다.
$ git branch --contains <commit-id>
원격 브랜치까지 포함하려면,
$ git branch -a --contains <commit-id>

7. merge #

7.1. 브랜치, commit id 머지 #

예)
머지 대상 브랜치: develop
머지 브랜치: <branch-name>
또는 머지 commit id: <commit-id>

git checkout develop
git merge --no-ff <branch-name>
git merge --no-ff <commit-id>

The --no-ff flag prevents git merge from executing a "fast-forward" if it detects that your current HEAD is an ancestor of the commit you're trying to merge.

7.2. 머지 conflict 해결 #

머지할 때 conflict가 발생해도 간단히 해결할 수 있기 때문에 당황할 필요가 없다.
Merge conflict를 해결할 때 IDE의 도움을 받을 수도 있지만 수동으로 해결하는 과정을 알아두면 도움이 된다.

예)
1. 충돌 발생

<<<<<<< HEAD
...
=======
...
>>>>>>> <this-branch> changes

2. 충돌이 발생한 코드에서 <<< (upstream change), >>> (작업 중인 change) 코드를 직접 확인하며 적절한 코드를 선택하거나 병합하여 충돌을 해결한 다음 저장한다.

3. 병합한 코드에 문제가 없으면 commit 한다.
$ git add <conflict-files>
$ git commit -m 'Fix conflict'

4. 다시 merge 한다.

7.3. prevents the MERGE COMMIT to occur #

$ git merge --no-commit

--no-ff 와 같이 사용할 수 있다.
$ git merge --no-ff --no-commit

7.4. 머지 취소 #

$ git merge --abort
머지 수행 전 상태로 돌아간다.

8. stash #

8.1. 기본 명령 #

* 현재 작업 상태 stash 저장
$ git stash

* 저장된 stash 확인
$ git stash list

* 저장된 stash 적용하고 제거
$ git stash pop

* 저장된 stash 적용하고 제거하지 않음
$ git stash apply

* 특정 stash만 제거할 때

$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
$ git stash drop stash@{0}
Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)

8.2. How can I delete all of my Git stashes at once? #

It does what you need:
$ git stash clear
from git documentation(http://www.kernel.org/pub/software/scm/git/docs/git-stash.html)

9. tag #

특정 커밋으로 제품을 릴리즈 하였다면 커밋 요약에 Release v1.0.0 또는 변경 요약을 포함하여 커밋하는 방법도 있지만,
만약 코드 변경 없이 태그만 찍는 용도라면 커밋 대신 git tag v1.0.0으로 현재 커밋에 태그를 다는 것이 더 일반적이다.

git tag는 특정 커밋에 대해 레이블을 지정하여 태그를 붙이는 기능이다. 이를 사용하여 특정 커밋의 버전을 명시할 수 있다.

9.1. tag 추가 #

$ git tag <tag-name>
예)
$ git tag v1.0

9.2. tag 검색 #

$ git tag

// 출력
v1.0
v2.0
v3.0

git tag 명령은 로컬 저장소에 존재하는 태그 목록을 알파벳/버전 순으로 출력한다.

9.3. tag 삭제 #

$ git tag -d <tag-name>

9.4. tag 확인 #

$ git tag -n
-n 옵션은 각 태그 옆에 annotation 메시지(또는 lightweight 태그의 경우 커밋 메시지 첫 줄)를 함께 표시한다.
-n5처럼 숫자를 붙이면 메시지를 최대 5줄까지 보여준다.

9.5. 로컬 tag 저장소 올리기 참고 #

참고 (자주 헷갈리는 점):
브랜치와 달리 tag는 기본 git push에는 포함되지 않기 때문에 따로 명령을 써야 한다.

특정 tag 하나만 push
$ git push origin v1.0

모든 tag push
$ git push origin --tags

commit push할 때 tag도 같이 push
$ git push --follow-tags

참고:
$ git push
→ 브랜치만 push, tag는 안 올라감

$ git push --tags
→ 로컬의 모든 tag를 원격으로 push

$ git push origin <tagname>
→ 특정 tag만 push

10. patch #

10.1. 생성 #

$ git diff > <patch-file>
$ git diff --no-prefix > <patch-file>

10.2. 적용 #

--no-prefix 옵션 없이 패치파일 생성한 경우 -p1 (diff의 a/ b/ path prefix 무시)

$ cd path/to/top                   # 패치하고자 하는 소스 위치
$ patch -p1 < patchfile            # 패치 적용

$ cd path/to/top                   # 패치하고자 하는 소스 위치
$ patch -p0 < patchfile            # 패치 적용

11. config #

11.1. git config 순서 및 위치 #

$ git config --system
## /etc/gitconfig

$ git config --global
## ~/.gitconfig

$ git config --local
## repo/.gitconfig

각 설정 파일에 중복된 설정이 있으면 system부터 순서대로 덮어 씌운다. 즉, git은 가장 먼저 /etc/gitconfig을 찾고, 다음으로 ~/.gitconfig 순서로 찾는다.

11.2. editor 변경 #

$ git config --global core.editor editor경로

ex)
$ git config --global core.editor vim

11.3. CRLF 문제 #

https://www.lesstif.com/pages/viewpage.action?pageId=20776404

2줄 요약

CORE.EOL
- core.eol = native 기본 설정. 시스템에서 line ending 을 처리하는 방법에 따른다. windows에서는 CRLF 를 사용하고 Linux, OS X 는 LF 만 사용한다.
- core.eol = crlf CRLF 를 line ending 으로 사용한다.
- core.eol = lf LF를 line ending 으로 사용한다.
CORE.AUTOCRLF
- core.autocrlf = false 기본 설정이다. 파일에 CRLF 를 썼든 LF 를 썼든 git 은 상관하지 않고 파일 그대로 checkin, checkout 한다. 이 설정은 line ending 이 다른 OS 에서는 text file 이 변경되었다고 나오므로 위에서 언급한 여러 가지 문제가 발생할 수 있다.
- core.autocrlf = true text file을 object database 에 넣기전에 CRLF 를 LF 로 변경한다.
- core.autocrlf = input LF를 line ending 으로 사용한다.

## 설정
$  git config --global core.eol native
  
## 설정 확인
$  git config --global --list|grep core.eol

12. 기타 #

12.1. git 작업내역 완전 초기화 #

$ git reset --hard
$ git clean -fd

git clone 상태와 동일하게 바꿔주는 git 명령.

12.2. git 파일이나 폴더 이름 변경 #

$ git mv oldName newName

git 으로 버전 관리할 경우 파일이나 폴더의 이름 변경도 추적할 수 있어야 한다.
특히 리팩토링시 클래스나 패키지 폴더의 이름 변경은 자주 발생하는 작업이므로 변경 내역을 잘 관리해야 한다.

변경 사항을 추적하기 어려워지니 절대 삭제후 add 하지 마십시오.
-n( --dry-run) 옵션을 사용하면 적용전에 어떻게 변경되는지 테스트가 가능하다.

12.3. fixup #

오늘 배운 유용한 git command `fixup`
1. 변경사항 A 커밋!
2. 변경사항 B 커밋!
3. 미처 A에 포함시키지 못한 변경사항 AA 발견!
4. git add AA
4. git commit --fixup=A
— Jbee🐝 (@JbeeLjyhanll) January 2, 2022

12.4. cherry-pick 중 conflicts 해결 #

1. conflict 발생 파일 수정

2. Merge 상태 제거(reset) 후 add
stash 하는 방법도 있지만 이 방법이 가장 쉬운 방법이다.
$ git reset filename
$ git add filename

12.5. gerrit에 push 할 때 unpacker error 발생 시 #

unpacker error는 --no-thin 옵션으로 packing을 하지 않고 push 하면 진행될 수 있다.

$ git push origin HEAD:refs/for/master --no-thin

12.6. .gitignore #

12.6.1. Visual Studio #

https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

(※ .gitignore는 확장자가 아니다. 오직 .gitignore 파일만 적용 된다.)

12.7. Passing ssh options to git clone #

* run git clone without checking the repository host's key
$ git config core.sshCommand 'ssh -o StrictHostKeyChecking=no'

12.8. Emoji for GitHub #

http://www.emoji-cheat-sheet.com/
Emoji emoticons listed on this page are supported on Campfire, GitHub, Basecamp, Redbooth, Trac, Flowdock, Sprint.ly, Kandan, Textbox.io, Kippt, Redmine, JabbR, Trello, Hall, Plug.dj, Qiita, Zendesk, Ruby China, Grove, Idobata, NodeBB Forums, Slack, Streamup, OrganisedMinds, Hackpad, Cryptbin, Kato, Reportedly, Cheerful Ghost, IRCCloud, Dashcube, MyVideoGameList, Subrosa, Sococo, Quip, And Bang, Bonusly, Discourse, Ello, Twemoji Awesome, Got Chosen, Flow, ReadMe.io, esa, DBook, Groups.io, TeamworkChat, Damn Bugs, Let's Chat, Buildkite, ChatGrape, Dokuwiki, Usersnap, Discord, Status Hero, Bitbucket, Gitter, and YouTube.

12.9. Git 커밋 탐색 도구 #

12.9.1. GUI Clients #

https://git-scm.com/downloads/guis/

12.9.2. ubuntu CLI 환경 #

tig - 커밋 히스토리 열람에 가장 특화된 도구
$ sudo apt install tig
커밋 히스토리 확인이 주 목적이라면 이게 가장 가볍고 빠름. 무엇을 골라야할지 모르겠다면 이것부터 사용을 추천.

lazygit - GUI에 가장 가까운 풀기능 TUI
$ sudo apt install lazygit

gitui - Rust로 만들어져 커밋 수만개 짜리 대형 저장소에서 체감 속도가 가장 빠름
cargo install gitui 또는 릴리즈 바이너리

Git & Tips

목차

1. 일반 #

1.1. 알아두면 좋은 기능 #

1.1.1. alias g='git' #

1.1.2. stashing #

1.1.3. blame #

1.2. 작업의 취소 #

1.3. push의 취소 #

2. commit #

2.1. commit 메시지 수정 #

2.1.1. 마지막 커밋을 수정하기 #

2.1.2. 커밋 메시지를 여러 개 수정하기 #