들어가며
Oh My ZSH+ iTerm2로 터미널을 더 강력하게 링크를 타고 들어가셔서 iTerm2를 설치해주세요.
해당 포스팅은 iTerm2를 기반으로 글을 작성하였습니다.
기본적인 Git 명령어
Git은 현재 내 데스크탑과 깃헙에 올라가 있는 레포지토리를 연결하는 역할을 합니다. Git을 사용해서 다른 사람이 만든 파일을 다운로드하고 내가 만든 파일을 업로드할 수 있습니다.
git으로 할 수 있는 기본적인 작업들부터 알아봅시다.
push, pull, commit이라는 명령어가 있어요. 해당 명령어를 사용해서 이러한 작업을 진행할 수 있습니다.
•
push : 현재 내 데스크탑에 있는 파일을 remote로 보냅니다.
•
pull : 현재 remote에 있는 파일을 내 데스크탑으로 보냅니다.
•
commit : 데스크탑에 있는 staged 단계 파일을 remote로 보내기 전 단계로 만듭니다.
해당 명령어를 사용해서 이런 작업을 진행해볼 수 있습니다.
팀원이 새로운 파일을 올렸을 때, 해당 branch에서 새로운 파일을 받아올 수 있습니다.
$ git pull origin develop(받아오는 브랜치 이름)
$ git pull origin main
$ git pull origin feature/login
Plain Text
복사
pull을 자주해준다면 해당 브랜치에 있는 파일과 내 데스크탑에 있는 파일의 형태가 비슷해져서 가지고 있는 파일의 상태가 달라서 파일끼리 충돌나는 문제가 적어집니다.
pull을 받은 후에 어떠한 작업을 진행하고 나서 commit을 해보려고 합니다.
그 전에 어떤 파일들이 commit되어야 하는지 한 번 봐볼게요.
gst라는 명령어는 git status 라는 명령어의 축약어로, iTerm2에서 제공해주는 축약어입니다. 기본 터미널에서는 git status라고 적어야 합니다.
해당 명령어는 파일들이 staged 단계로 넘어갔는지 not staged에 머물러 있는지 볼 수 있습니다. Changes not staged for commit이라고 쓰여져 있는 부분이 바로, 아직 staged으로 넘어가지 못한 파일들 입니다. 하지만, 해당 파일들은 commit 명령어를 쓴다고 해서 staged 단계로 넘어가지 못합니다. commit 명령어는 staged 단계에 있던 파일들을 그 다음 단계로 넘기는 일을 하기 때문이죠.
그러면, 어떻게 staged 단계로 넘어갈 수 있을까요?
add명령어를 사용해서 not staged 파일들을 staged 단계로 넘겨줄 수 있습니다.
지금 not staged에 있는 모든 파일을 올리기 위해서는 .를 사용하면 됩니다. 특정 파일만 올리고 싶다면 해당 파일의 이름을 add 명령어 뒤에 넣으면 됩니다.
$ git add .
-> 모든 파일을 staged로
$ git add ABLY-iOS/ABLY-iOS/Source/Cells/TVC/MainBottomTVC.swift
-> 원하는 파일만 staged로
Plain Text
복사
이제 staged 상태로 넘어갔기 때문에 commit 명령어를 사용해서 다음 단계로 나아갈 수 있습니다.
commit 명령어는 기본적으로 ⓵ 커밋 내용을 바로 작성하는 방법과 ⓶ vim을 생성해서 vim에 커밋 내용을 작성하는 방법으로 commit 메시지를 작성하게 됩니다.
$ git commit -m "[ADD] login 파일 추가"
-> 커밋 내용 바로 쓰기
$ git commit
-> 커밋 내용을 쓸 수 있는 vim이 생성
-> 맨 윗 칸에 쓰면 커밋 내용, 거기서 엔터쳐서 내용을 입력하면 상세 내용으로 들어감
Plain Text
복사
간단한 내용을 작성하고 싶다면 -m 옵션을 써서 바로 작성해도 되겠지만, vim에서 작성하게 되면 더 자세한 내용도 작성할 수 있게 됩니다.
만약, 커밋을 작성하다가 오타를 남기고 저장해버렸다면 수정할 수 있습니다.
$ git commit —-amend
Plain Text
복사
--amend옵션 사용해서 수정해주시면 됩니다. 하지만, 이미 push 된 커밋 메시지는 수정할 수 없습니다.
이제 commit까지 완료했으니 push해봅시다.
$ git push origin main(push할 브랜치 이름)
$ git push origin feature/login(현재 내가 자리하고 있는 브랜치 이름으로 해주세요)
Plain Text
복사
commit을 완료했어도 push명령어를 입력하지 않으면 remote인 깃허브에 올라가지 않습니다. push 까지 해주어야 다른 팀원들도 볼 수 있는 깃허브에 올라간겁니다.
push를 하지 않으면 이전에 했던 작업들이 모두 사라지나요?
깃허브도 변경되는 내용들을 저장하고 있지만, 내 데스크탑에서도 해당 내용들을 저장하고 있습니다.
깃허브에 올라가지 않았을 뿐, 데스크탑이 해당 내용을 보존하고 있습니다. 나중에라도 push를 해준다면 해당 내용이 깃허브에 올라가게 됩니다.
내 데스크탑 그리고 깃허브, 총 2개의 공간에서 변경되는 내용을 저장하고 있다고 보시면 됩니다. 그리고, 2개의 공간은 별개의 공간이기 때문에 계속해서 pull해주고 push해주지 않으면 서로 다른 내용을 저장하고 있을 수도 있습니다. 직접 동기화 시켜주지 않으면 자동으로 동기화되지 않습니다.
+ ⍺
위에서 계속해서 브랜치라는 단어를 사용했습니다.
브랜치는 이름 그대로, 나무에 있는 줄기같은 겁니다. default가 되는 브랜치에서 뻗어져 나와서 새로운 작업을 진행하고 default 브랜치로 다시 합치는 작업을 하게 됩니다.
처음 레포지토리를 생성하면 main이라고 적혀있는 부분이 바로 브랜치입니다. 협업을 하지 않으면 따로 브랜치를 나눌 필요가 없기 때문에 main에서만 작업해도 되지만, 여러 사람들과 협업을 하기 위해선 여러 브랜치가 필요합니다. main에서 여러 사람들이 각자 파일을 건드리게 되면 파일이 손상되고 되돌릴 수 없는 상태가 될 수 있기 때문이죠.
그러면, 새로운 branch를 한 번 생성해봅시다.
branch를 생성하는 방법은 간단합니다. branch라는 명령어를 사용하면 됩니다.
$ git branch develop(생성할 브랜치 이름)
Plain Text
복사
해당 명령어를 사용하면 브랜치는 생성되지만 해당 브랜치로 바로 이동하진 않았을 겁니다. 따라서, 해당 브랜치로 이동하는 명령어를 작성해주어야 합니다.
$ git checkout develop
Plain Text
복사
만약, 두 가지 작업을 한 번에 하고 싶다면 이렇게 작성하시면 됩니다.
$ git checkout -b develop
Plain Text
복사
만들어둔 모든 브랜치들을 보고 싶다면 하단에 있는 명령어를 작성하시면 됩니다.
$ git branch
Plain Text
복사
분명, 깃허브에는 있는데 내 데스크탑에는 없는 브랜치들도 있을겁니다. 위에서 말했지만 내 데스크탑과 깃허브는 다른 저장소이기 때문에 같아지기 위해서는 동기화를 시켜야 합니다.
$ git fetch --all
Plain Text
복사
fetch 명령어를 사용하면 깃허브에만 있던 브랜치들도 내 데스크탑에 존재하게 됩니다.
더이상 사용하지 않아서 브랜치를 삭제하고 싶다면, 삭제 옵션을 사용해서 지워주시면 됩니다.
$ git branch -D develop
Plain Text
복사
브랜치는 어떤 형식으로 네이밍하나요?
협업하는 팀마다 브랜치 네이밍을 하는 방식이 다 다릅니다.
어떤 브랜치 전략을 따르는지에 따라서도 방식이 달라지게 됩니다. 대부분의 팀에서 많이 따르는 Git-flow 방식 관련 글을 첨부해둘테니 참고해서 네이밍하시면 되겠습니다.
•
위에서 default 브랜치로 합치는 작업을 한다는 얘기를 했던 거 같습니다.
만약, default 브랜치에 적혀있는 내용과 새로운 브랜치에 적혀있는 내용이 다르면 무슨일이 일어날까요?
대부분 다른 두 내용을 알아서 병합시켜줍니다. 이를 merge라고 하죠.
default 브랜치와 별 탈없이 머지하는지는 다양한 방법으로 알 수 있습니다.
먼저, Pull Request를 생성하는 겁니다.
대부분의 팀에서는 default 브랜치로 머지되기 전에 Pull Request를 작성해야 합니다. 해당 브랜치가 어떤 추가적인 작업을 진행했고, 문제가 없기 때문에 default로 합쳐도 괜찮습니다 라는 걸 팀원들에게 어필하는 글이라고 봐주시면 됩니다.
Pull Request를 생성하게 되면, 해당 브랜치가 default 브랜치로 합쳐도 안전한지, 안전하지 않은지를 알려줍니다.
안전하지 않다는게 뭔가요?
안전하지 않다는건, 합쳤을 때 충돌이 발생한다는걸 의미합니다.
예를 들어서, 123.txt라는 텍스트 파일이 있다고 해봅시다. 원래 해당 텍스트 파일의 120번 라인에는 “안녕하세요”라는 단어가 적혀있었는데, 새로운 브랜치를 파서 해당 라인을 “Hello”라고 바꿨다고 해봅시다.
실제라고 하면 그정도의 변화는 깃에서 알아서 충돌없이 병합시켜줍니다.
하지만, 어떤 문제가 발생해서 깃에서 원래 버전을 사용해야할지, 새로운 버전을 사용해야할지 헷갈리게 되면 충돌을 발생시킵니다. 자신이 해당 문제를 해결할 수 없기 때문에 인간이 처리를 해줘야 하는 상황인거죠.
그러면, 인간은 어떤 방식으로 충돌을 해결해주어야 할까요?
현재 브랜치에서 default 브랜치를 pull 해줍니다.
기본적으로 pull은 병합 작업을 동반합니다. 따라서, 머지를 하다가 충돌을 일으킬겁니다.
그러면, 데스크탑에서 충돌을 해결해주고 바뀐 상태를 다시 push해주면 Pull Request에서 보였던 머지 안됨 문구가 사라질겁니다.
만약, 이런 문제가 있는 브랜치를 바로 default 브랜치로 병합시키면 팀원 모두가 당혹스러운 상황에 놓이게 될겁니다..🫤 머지 충돌을 해결하는 방법은 gitkraken를 사용해서 git confilct를 해결해봅시다. 에 작성해보았습니다.
++ ⍺
하던 작업을 임시로 저장해두고 싶을 때 사용하는 명령어가 있습니다.
// 임시 저장
$ git stash
// 임시 저장 목록보기
$ git stash list
// 했던 작업 가져오기
$ git stash apply
$ git stash apply [stash 이름]
// 임시 저장 제거하기
$ git stash drop
$ git stash drop [stash 이름]
// 임시 저장 제거 동시에 적용하기
$ git stash pop
Plain Text
복사
만약, git add를 통해서 staged로 보냈지만 다시 unstaged로 보내고 싶다면, 이 명령어를 써보세요.
$ git rm —-cached (지울파일이름) -r
Plain Text
복사
코드를 작성하다가 원하는 때로 깃 히스토리를 돌리고 싶다면, reset 명령어를 사용하시면 됩니다.
$ git reset —-hard (커밋코드)
Plain Text
복사
*커밋코드는 깃허브에 있는 history에서 확인 가능합니다.
지금 현재 unstaged에 있는 파일이 이전 커밋과 어떤 변경사항이 생겼는지 알고 싶다면 차이점을 비교하는 diff 명령어를 사용해보세요. staged에 있는 파일도 옵션을 사용해서 확인 가능합니다.
$ git diff
$ git diff --staged
Plain Text
복사
현재 데스크탑에서 연결하고 있는 remote의 주소를 지우고 다시 설정하고 싶다면 이렇게 작성해주시면 됩니다.
$ git remote remove origin
$ git remote add origin [주소]
Plain Text
복사
현재의 remote를 확인하고 싶다면 이렇게 작성해주세요.
$ git remote -v
Plain Text
복사