Git memo, 깃 고수가 되어보자
프롤로그
이 글은 앞으로 쓸 예정인 필로소퍼, 미니쉘에 대한 회고 기록, 학습 기록을 남기기 앞서 다시 블로그 관리에 시동을 거려는 나름의 처절한 몸부림(…) 입니다.
협업으로 학습과 개발을 해보니, 자연스레 저보다 깃에 익숙한 팀원에게 사실상 깃 관리를 맡겼었습니다.
하지만 아무래도 관리적으로 아쉬운 점이나, 깃의 제대로된 활용(?) 에 있어서 배워야 한다는 생각, 보완을 어떻게 하면 좋을까? 하는 생각을 하게 되었습니다.
따라서 협업에서 충분한 숙지가 필요한 ‘깃’이라는 협업 관리 툴에 대한 이해도를 높이고, 유용한 기능들을 놓치지 않기 위해 정리하는 글입니다.
사실은 이런 글을 굳이 적을 필요가 없다? 는 생각도 한 켠에 들긴 했습니다.
사실상 모든 기능들이나, 개념은 매뉴얼을 참조하면 되고, 커맨드 몇 번 입력하면 되니…
그러나 막상 팀업으로 빌드가 이어지는 와중에 그런 식으로 맥을 끊는 고민들이 발생하는게, 상당히 안 좋다는 걸 느꼈습니다.
개발 흐름을 끊기도 하고, 무엇보다 그걸로 시간을 쓰는게 ‘경험’ 적으론 유익하나 ‘개발’ 면에선 다소 아쉬움을 느꼈습니다. 내가 얼마나 빠르지만 정확하게 개발이 가능하냐 는 정말 중요한 강점이 될 수 있기 때문입니다.
이에 필요한 기능이나, 알아야 할 점들을 정리해 보았습니다. 다소 주의하실 사항은 이 글은 팀 개발을 위한 Git GitHub 시작하기
라는 교재를 학습하고, 거기서 필요한 일부만 남겨둔 것이라는 점입니다.
내용이 완벽하게 담긴 것은 아니니, 학습에 참고 용 정도고 부정확한 내용도 있을 수 있음을 먼저 알립니다.
유용한 명령어 & 팁들 정리
1. 깃 커밋에서 되돌리기 & 돌아오기
$> git log
commit a970fdc6ede8fc06c6b6e1f0c4ezOd5f92af2bcd12 (HEAD -> main, origin/main, origin/HEAD)
Author: haryu <ryu.axel@gmail.com>
Date: Thu Jun 23 13:39:30 2022 +0900
22-06-23 : study English #16, 17
commit 68c843d338e47a08001ad1f90b2f1ccf7376e322
Author: haryu <ryu.axel@gmail.com>
Date: Tue Jun 21 09:42:00 2022 +0900
22-06-21 : study English #15
.
.
.
$> git checkout 68c843d
# 앞에 7자리의 커밋 아이디를 복사하여 넣게 되면, 해당 커밋을 되돌아가는 것이 가능합니다.
# 전체 아이디를 다 넣어서 이동도 가능합니다.
$> git checkout -
# 가장 최신의 커밋으로 돌아갈 수 있습니다.
2. 로컬 저장소에 원격 저장소를 지정해주기
$> git remote add origin $(github_link)
.
.
$> git push origin $(branch_name)
# 깃 푸시 상황에서 브랜치 명은 github default는 main, git 은 master 로 되어 있습니다.
# 따라서 상황에 따라선 새로운 브랜치가 생성될 수 있습니다.
3. git clone 시 알아둘 사항
- git clone 으로 clone 시 버전정보가 같이 내려받기 가능함.
- 이에비해 ZIP 파일로 다운 받게 되면, 원격저장소와 버전정보는 제외됨.
4. git clone 시 꿀팁
git clone $(github_link) .
: 현재 폴더에 깃 관련 내용을 정리합니다.git clone $(github_link) $(relative/absolute PATH)
: 일반적으로 사용 방법
5. git origin 이란?
- 보통 로컬 저장소를 원격 저장소와 연결 시키거나, 새로운 브랜치를 원격 저장소에 독자적인 저장소로 push 하는 경우 다음처럼 사용한다.
$ git remote add origin $(LINK)
$ git push --set-upstream origin $(BRANCH_NAME)
- 이때, origin 이라는 용어가 사용되는데,
원격 저장소
의 이름을 뜻한다. - 해당 키워드가 가지는 의미는 원격저장소에, 현재 지정한 저장소의 이름과 동일한, 대응되는 원격 저장소를 언급하는 키워드이다.
- 참고로
upstream
은 브랜치들이 저장되는 레포지터리 그 자체를 의미한다. - 따라서 두번째 명령어의 경우, git 을 보내되, 레포지터리에 $(BRANCH_NAME)에 해당하는 독자적인 브랜치를 설정해라- 정도로 해석할 수 있다.
6. 커밋은 Delta(차이점) 이 아니라 스냅샷(snapshot)이다.
- 원리적인 측면에서 기존 개발 업계의 버전 관리 툴 SVN이 존재했고, 지금도 일부 쓰인다고 하는데, 그럼에도 git이 대세가 된 가장 큰 차이는 git이 커밋에서 바뀐 영역 + 기존 영역을 전부 다 저장한다는 점이다.
- 이는 일견 비효율적인 것으로 보이지만, git은 커밋된 순간 순간의 상태를 기록해둔 것이고, 따랏 git에서 버전관리로 롤백을 하거나, 무언가 관리 측면에서 연산을 한 번만 하면 되고 바뀌지 않은 파일은 그대로 두기에 오히려 용량이 적다는 장점이 있다.
7. Git 으로 관리하는 파일의 상태
- untracked : Git 관리대상이 아닌 상태. 변동 사항이 기록되지 않은 상태를 의미합니다.
- tracked : git add 를 통해 파일 자체를 관리하도록 처리된 상태입니다.
- no modified : 스테이지에 올라가 있으나, 변경사항이 없는 상태
- modified : Git이 상태 변경됨을 확인하고, commit 대기 중인 상태의 파일
- staged : git add 를 통해 올라가면서 stage에 올라갔고, 해당 상태에서 commit 을 통해 스냅샷처럼 찍혀서 Git 에 저장됩니다.
- no modified : 스테이지에 올라가 있으나, 변경사항이 없는 상태
8. 왜 master 브랜치는 ‘가리킨다’고 표현할까
- 지금까지 잘못 알고 있던 부분이 브랜치가 커밋을 진행하면 사용하는 표현을 제대로 알지 못했었다. 그런데 이에 대해 정리한 내용을 읽어보니 ‘가리킨다’ 고 되어 있었다.
- 이러한 점은 브랜치가 물리적으로 무언가 의미하고, 포함하고 있는게 아니라 단순히 해당 지점에 대한 ‘포인터(Pointer)‘역할을 하기 때문이다.
- 좀더 디테일하게 들어가보면 Git 은 위에서 언급한 대로 커밋을 통해 해당 순간을 기록하며, 이때 필요한 모든 코드들을 포함하고 있다. 그리고 거기서 커밋하는 순간 유효한 (정확히는 해당 순간 기록된 사항들만)을 가리키는 형태인 것이다.
9. HEAD 의 의미
- 아직 완전히 이해가 되진 않지만, 가이드를 참고해보면 HEAD 는 특수한 브랜치 포인터라고 한다.
- HEAD를 옮겨 이전 브랜치로 가거나 현재 브랜치를 가리키고 있는데, git checkout $(COMMIT_ID)를 통해 이전 커밋 상태로 돌아가 보니 git log 상에서 HEAD의 위치가 바뀌는 것을 볼 수 있었다.
- 즉 현재 바라보는 시점 같은 개념으로 생각하면 될 것 같다.
- 또한 HEAD로 가리켜 지던 특정 브랜치 포인터에서 HEAD를 옮겨 버리면 Detached HEAD(분리된 헤드) 라고 불린다.
$> git log
commit 3134f8701f794b846a353af7c599546f4e940bef (HEAD -> hotfix/echo, origin/hotfix/echo)
Author: haryu <ryu.axel@gmail.com>
Date: Thu Jul 7 17:44:55 2022 +0900
FIX : echo & signal handler
1. FIX : echo argv option logic
2. FIX : on main prompt, if we use signal, handler will add 1 value to
global var.
commit 4f848ad9d3c832f5446c0a3f3e5add7fdc0e52c9 (origin/master, origin/HEAD, master)
Author: haryu <ryu.axel@gmail.com>
Date: Thu Jul 7 12:12:05 2022 +0900
fix heredoc signal handler
commit 321a0ae4a5829be598ac840bc5834469f43dfbb9
Merge: 684acd1 df7be5d
Author: Cgim <cksrb1526@naver.com>
Date: Thu Jul 7 09:28:16 2022 +0900
Merge pull request #98 from Eingerjar/fix/exitcode
FIX : exit code about heredoc(signal quit -> 1, SIGQUIT disable)
ADD : new tcsetattr for heredoc (disable SIGQUIT).
FIX : SIGINT, SIGQUIT logic change in ft_wait(now highly get right exit code from childs)
.
.
.
$> git checkout 321a0ae4
Note: switching to '321a0ae4'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 321a0ae Merge pull request #98 from Eingerjar/fix/exitcode
$> git log
commit 321a0ae4a5829be598ac840bc5834469f43dfbb9 (HEAD)
Merge: 684acd1 df7be5d
Author: Cgim <cksrb1526@naver.com>
Date: Thu Jul 7 09:28:16 2022 +0900
Merge pull request #98 from Eingerjar/fix/exitcode
FIX : exit code about heredoc(signal quit -> 1, SIGQUIT disable)
ADD : new tcsetattr for heredoc (disable SIGQUIT).
FIX : SIGINT, SIGQUIT logic change in ft_wait(now highly get right exit code from childs)
commit df7be5dd20407ca937d812e2b16d6ea3868cdf48 (origin/fix/exitcode, fix/exitcode)
Author: haryu <ryu.axel@gmail.com>
Date: Thu Jul 7 04:03:35 2022 +0900
Delete : delte sigquit handling conditions
.
.
.
$> git switch -