🍳머리말
GUI로 commit, push와 pull 등 여러 git 명령어를 편하게 하나의 버튼으로 해결이 되도록 구성이 되어있는 IDE가 많습니다. 물론 편리하지만 여러 옵션을 추가해 원하는 결과를 출력해 보기는 어렵습니다. 또한 자신이 참가하지 않은 프로젝트에 대해 히스토리를 분석하고 빠르게 파악하는 부분은 버튼을 찾는 시간이 오래 걸릴 수 있습니다.
처음보는 프로젝트라도 한 번에 정보를 파악하는 reading skill은 중요합니다.
Open source의 history를 확인하고 기여를 한 개발자의 특정 역량을 파악하기 위해서는 세밀한 option들을 통해 git log들을 확인해봐야 합니다. 이 외에 commit을 쪼개거나 협업하며 일어날 다양한 상황에 대처하는 것에 command를 직접 입력하는 것이 더 유리한 경우도 있습니다. 다음은 명령어들과 출력 결과 예시를 설명합니다.
IDE : 구름 IDE
예시 Project : pytorch example project
https://github.com/Taeung/pytorch-example
IDE상 version을 control 하는 것 외에 terminal 상에서 유용하게 쓸만한 명령어를 정리해 보았습니다. [] 부분은 custom해야하는 부분을 나타낸 것입니다. 명령어가 아닙니다.
📕 git status
📑 기능
folder안 파일의 상태 확인
📑 출력결과
📕 git log
📑 기능
project 전체 commit log 확인하기
📑 출력결과
📔 git log [commit id]
📑 기능
특정 commit id의 log보기
📔 git log -p
📑 기능
project 전체 commit log들을 자세하게 보기
📔 git log --oneline
📑 기능
전체 파일 수정 내역(commit history)의 제목을 간단히 확인하기 위해 한 줄씩 출력
📔 git log --oneline [폴더명]
📑 기능
특정 folder안에 있는 수정 내역을 한 줄씩 출력
📑 출력결과
📔 git log --oneline --after=2020-01-01 --before=2020-06-30
2020-01-01 ~ 2020-06-30의 커밋 로그들을 보기, 범위는 inclusive.
📑 출력결과
이렇게 --no-merges, |, folder 또는 file명을 자유자재로 활용할 수 있습니다.
📕 git shortlog
📑 기능
전체 프로젝트 참여자와 commit 수 해당 commit의 commit message를 출력
📔 git shortlog -sn
📑 기능
전체 projcet 내 기여자의 rank 뽑기, 개수(merge, commit 수)로 순위 메기기. 개수, 이름 형태
📑 출력결과
📔 git shortlog -sn | nl
📑 기능
line number를 명시하여 전체 project 내 rank 출력
📑 출력결과
📔 git shortlog -s
📑 기능
개발자별 commit 개수 요약 뒤에 [폴더명] 입력가능
📑 출력결과
📔 git shortlog -h | grep summary
📑 기능
커밋 설명 생략해 커밋 수만 표시
📑 출력결과
📔 git shortlog -sn [폴더명]
📑 기능
특정 폴더 내 기여자의 rank 뽑기
📑 출력결과
📔 git shortlog --no-merges -sn | head -3
📑 사용 이유
git shortlog -sn명령어만으로 확인한다면 정확한 정보를 파악하기 힘듭니다. 이 경우에는 진짜로 소스를 수정한 개수로 ranking하는게 아닌 사용자의 merge와 commit을 포함한 개수로 순서를 매기게 됩니다. source 수정을 많이 한 것처럼 오해할 수 있기 때문에 명확한 정보를 알기 위해 해당 명령어는 필요합니다.
📑 기능
merge,commit 수를 제외하고 기여자 rank상위 3개 뽑기
📑 출력결과
📔 git shortlog --no-merges -sn | head -3 [파일명]
📑 기능
merge,commit 수를 제외, 특정 파일의 rank 상위 3 뽑기
📑 출력결과
📔 git shortlog --no-merges -sn | head -3
수정된 파일을 commit merge수 빼고 보기
📑 출력결과
📕 git show
📑 기능
HEAD가 가르키고 있는 commit의 정보 출력
📑 출력결과
📔 git show [commit id]
📑 기능
commit id의 정보
📑 출력결과
📔 git show [commit id] | grep "diff --git"
📑 기능
commit id의 수정한 파일 보기
📑 출력결과
a/ b/ 는 directory라기 보다는 before, after같은 개념으로 a가 이전이며 b로 바뀌었다의 의미입니다. file명이 바뀔수도 있지만 안바뀐 경우 안의 내용이 수정된 것입니다.
📔 git show [commit id] | grep "diff --git" | wc -l
📑 사용이유
commit id의 수정한 파일 개수 보는 명령어 입니다. 한 commit에서 수정된 file은 여러개일 수 있습니다. 따라서 commit하는 단위가 중요합니다. source code를 몇 천 줄을 짤 때마다 한 번 commit을 하게 된다면 그리고 여러 file을 한번에 수정을 한다면 어떤 것이 변경사항인지 파악하기 어렵기 때문입니다.
📑 출력결과
📕 git stash
📑 사용 이유
자신이 어떤 작업을 하던 중에 다른 요청이 들어와 하던 작업을 멈추고 잠시 브랜치를 변경해야 할 일이 있다고 가정해 봅니다. 이 경우, 다른 branch로 옮길 때 기존 branch에 있던 변경 기록을 commit하게 된다면 제대로 검증되지 않은 source가 원본 file에 올라갈 수 있습니다. 특히 현업자들도 branch를 왔다갔다 하는 상황에서 add를 잘못했다가 다른 branch에 들어갈 내용이 "실수로" commit 과 함께 올라가는 경우가 있다고 합니다. stash는 해당 명령어를 입력할 때 기준의 현재 브랜치에 작업내역이 저장되기 때문에 add 로 인한 잘못된 변경 내역이 반영될 수 있는 여지를 없애줍니다.
이 명령어를 입력하면 woking directory에서 수정한 file만 임시로 stash라는 공간에 저장하게 됩니다.
📕 git commit -m "commit message 입력"
📑 기능
commit 을 -m으로 입력하면 한 줄로 간단히 commit message를 적을 수 있습니다. 하지만 이 option을 생략한다면 여러줄을 입력하기 위한 editor창이 뜹니다. commit message를 적는 이유는 해당 변경사항을 왜 하게 되었는지에 대한 설명을 적는 부분입니다. 주로 -m option을 넣어 한 줄로 적지만 여러줄로 입력하는 것이 자연스럽습니다.
📕 git reset --head HEAD-[행의 수]
📑 기능
commit된 부분을 정리하고 싶을 때 특정 commit을 지울 수 있습니다. git reset --head HEAD-1로 입력하게 되면 HEAD가 가르키고 있는 commit을 지우고 HEAD를 한 칸 아래로 내리게 됩니다. 여러개의 commit을 지우고 싶을 때는 git reset --head HEAD-[행의 수]로 입력하면 됩니다.
📕 git commit --amend
amend는 update와 동의어입니다.
commit을 이미 했으나 변경할 사항이 있어 다시 commit을 해야하는상황이 올 수 있습니다. 계속해서 commit하고 변경하고 또 commit을 한다면 불필요한 commit message가 git flow에 쌓일 수 있습니다. 이 때 --amend option을 사용합니다.
📑 기능
현재 HEAD가 가르키고 있는 commit에 대해 message를 수정하거나 변경사항을 덮어쓸 수 있습니다.
📕 git rebase upstream/master, git fetch upstream master
📑 사용이유
fork하게 된 project는 origin, 원본 project는 upstream이라 합니다. open source project에서는 많게는 몇 천명의 개발자가 함께 개발하게 됩니다. 혼자서 개발할 때는 변경사항을 pull하고 push, merge하는 것이 간단하지만 여러 개발자가 fork를 한 후 원본 project에 pr을 하게되는 경우에는 충돌상황이 발생할 수 있습니다. 개발자 a와 제가 있는 경우 각자의 repository로 fork한 후 변경사항을 merge해야하는 상황을 가정해 봅니다. 제가 upstream에 push했는데 이미 개발자 a의 변경사항이 upstream에 반영이 된 것입니다. 이 경우에 저는 merge가 되지않습니다. 기존 base가 개발자 a의 변경사항을 반영함으로써 바뀌었기 때문입니다. git bash를 쓰는경우에는 pull을 하라고 안내해줍니다. 하지만 pull을 하게되는 경우 제 변경사항이 반영되지 않고 모두 날아갈 수 있습니다. 이런 눈물나는 상황을 막고자 rebase를 이용합니다.
rebase를 이용하게 되면 개발자 a의 변경사항이 반영되고 자신의 변경사항 또한 유지하면서 merge할 수 있습니다.
만약, 반대로 자신의 변경사항이 먼저 merge되었다면 댓글로 rebase를 하는 센스도 중요합니다.
📕 git rebase -i --root
📑 기능
i는 interactive 명령어로 rewind기능입니다. 과거로 돌아가는 방법이라고 합니다. 해당 명령어를 입력하면 돌아갈 수 있는 commit 목록이 과거부터 보여지게 됩니다. git log --oneline과는 반대이니 주의합니다. list중 하나를 선택해 "edit"으로 바꿔주면 해당 base로 돌아가게 됩니다.
📕 git rebase --continue
📑 기능
rewind했던 base를 -i -root 명령어를 치기 바로 전 시점으로 돌아갑니다.
📕 git push -f
📑 기능
PR내용을 수정하고 싶은 경우에 사용합니다. 해당 명령어를 사용하면 기존 PR을 등록해놓은 경우 자동갱신이 됩니다.
논외로,
git clone해서 노트북(로컬 저장소)에 저장해 수정 후 add, commit하는 방법도 있지만 fork후 자신의 개인 repository에서 마음껏 수정한뒤 pull-request(commit들을 제출)하는 경우도 있습니다. 여러 방식으로 프로젝트를 다루게 되면서 다양한 git 명령어들이 있습니다. 이를 다양하고 유용하게 다루기 위해 명령어를 숙지하는 것은 중요합니다.
📕 git diff [commit id]
📑 기능
특정 commit과 현재 branch의 마지막 commit과의 차이점을 비교
📑 출력결과
'Git' 카테고리의 다른 글
| git이란 (0) | 2021.04.13 |
|---|---|
| Git(for Window) - git pull 해보기 for git bash users (2) | 2019.02.09 |
