Git & Github 톺아보기 (w. 명령어 정리)

🌊·2023년 4월 29일
0
post-thumbnail

오늘은 git 명령어에 대해서 톺아보는 시간을 가져보려고 합니다.
최근에 톺아보기 라는 단어가 제 눈에 많이 보였는데요
톺아보기는 구석구석 꼼꼼히 살펴보기 라는 뜻이 됩니다!

본 뜻을 찾아보면, '톺다'라는 뜻은 틈이 있는 곳마다 모조리 더듬어 뒤지면서 찾다 라는 뜻입니다.
'톺아보기'는 샅샅이 톺아 나가면서 살피다 라는 뜻을 가지고 있습니다.

Git이란 무엇인가? 🤔

  • 리누스 토발즈가 리눅스 커널 개발에 사용할 관리 도구 용도로 개발
  • 분산 버전 관리 시스템으로 지역 저장소와 원격 저장소가 존재
  • 여러 사람이 같은 코드를 수정하고 공유하며, 하나의 파일로 모든 버전을 관리할 수 있다. 또한 동시에 같은 부분을 수정했을 때 생기는 문제들을 해결할 수 있다.

git을 사용하는 가장 큰 이유는 버전관리와 협업입니다.

git을 써야만 버전관리를 할 수 있는 것은 아닙니다. 하지만 많은 개발자들이 보편적으로 git을 사용하고 있고, 다른 개발자와 협업을 하기 위해서는 많이 사용하는 것을 먼저 배우는 것이 좋겠죠?

git은 지역 저장소에서 버전 관리가 수행됩니다. 그렇기 때문에 원격 저장소나 네트워크에 문제가 있어도 작업이 가능합니다.
원격 저장소는 여러 사람들이 협업을 위해 버전이 공동으로 관리되는 곳입니다.
자신의 버전 내역을 반영하거나, 다른 개발자의 반영된 버전 내역을 가져올 때 사용합니다.

그렇다면 github는 무엇일까요?

Github는 무엇인가? 🤔

  • git 저장소 호스팅을 지원하는 웹 서비스

git을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스이기 때문에, git을 사용하는 프로젝트를 모두 github에서 관리할 수 있습니다.
gitlab처럼 다른 호스팅 서비스를 이용할 수도 있습니다.

Git 사용법 🔨

git의 여러 명령어를 통해서 git의 사용법을 알아보려고 합니다!

git init

처음 git을 사용할 때 필요한 명령어입니다. 최초 한 번만 입력하면 됩니다.

git 명령어 위주의 설명이기 때문에 github 저장소를 생성하는 작업은 스킵했습니다.

계정 정보 입력

git config --global user.email <myEmail>
git config --global user.name <myName>

수정

git config --global --edit

git status

  • git으로 관리되고 있는 파일의 상태를 확인할 수 있다.

git의 3가지 상태

modified

  • 파일을 수정하면 그 파일은 modified 상태가 된다.

staged

  • 변경된 파일을 git add 명령어를 통해서 stage area로 올리면 staged 상태가 된다.

committed

  • staged 파일을 git commit -m <message>를 통해서 해당 파일을 committed 상태로 바꿀 수 있다.
  • 여기까지 진행하고 git push가 일어나야 원격 저장소에 해당 내용이 반영된다.

untracked files

  • 아직 git이 관리하지 않는 파일
  • 보안에 위협이 되는 파일은 git으로 관리하지 않는 것을 권장

git init 명령어를 실행하고 새로운 파일을 추가하게 되면 untracked file이 추가됩니다.

git status 명령어를 통해 확인할 수 있습니다.

git add <fileName>

  • modified 상태의 파일을 staged 상태로 변경
  • 해당 파일을 stage에 올림 (staged 상태)
  • git add . 명령어를 통해서 stage에 올라가지 않은 파일 모두를 stage에 올릴 수 있다.

새로 만든 파일을 해당 명령어로 입력하게 된 경우 위와 같은 화면을 볼 수 있습니다.

이미 git에서 관리하고 있는 파일이 수정된 경우에는 modified라고 파일명 앞에 나타납니다.

git restore <fileName>

  • modified 상태의 파일을 수정 이전의 상태로 변경
  • 모든 파일을 초기화하려면 git restore . 명령어 사용

git restore --staged <fileName>

git restore --staged <fileName>
  • staged 상태의 파일을 modified 상태로 변경
  • stage에 올라간 fileNamemodified 상태로 변경
  • 새로 추가된 파일의 경우에는 untracked files로 변경 됨
  • 모든 파일을 초기화하려면 git restore --staged . 명령어 사용

git rm

git rm <fileName>
  • 원격저장소와 로컬 저장소 파일을 모두 삭제
git rm --cached <fileName>
  • 로컬 저장소의 파일은 보존하고, 원격 저장소에 있는 파일만 삭제

.gitignore

  • 해당 파일에 작성된 파일, 폴더는 git에서 관리하지 않음
  • 매번 git rm 관련 명령어를 쓰지 않아도 된다.

git commit

git commit
  • 해당 명령어만 입력하면 vim을 통해서 커밋 메시지 작성 가능

git commit -m "Commit Message"
  • 보편적으로 사용하는 git commit 명령어

git commit <file> <file2> <file3> -m "Commit Message"
  • 여러 파일을 선택적으로 커밋하고 싶을 때 사용

git commit -am "Commit Message"
  • git addgit commit 명령어를 한 번에 사용 가능
  • 반복 작업을 줄여줄 수 있다.

커밋 메시지를 길게 입력하고 싶다면

git commit -a

명령어를 사용하면 됩니다.

git log

  • 커밋의 목록을 볼 수 있음
  • 커밋의 id, 시간, 커밋 메시지를 포함
git log
git shortlog
  • 간략하게 git log 정보를 확인 가능

git log --oneline
  • git shortlog 보다는 더 많은 정보를 포함해서 확인 가능

git show <commitId>
  • 특정 <commitId>를 이용해서 수정 내용을 확인할 수 있다.

git diff

  • 모든 코드의 수정 내용을 알고 싶을 때 사용한다.

git 입장에서는 코드가 수정되면 기존 작성된 코드가 삭제되고 새로 작성된 코드가 추가되는 개념입니다.
그래서 기존의 작성된 코드가 수정됐다고 생각하지 않습니다.


git diff <fileName>
  • fileName의 수정 내용을 확인

git으로 협업하기 🤝

현재까지의 명령어는 지역 저장소에서 사용 가능합니다.
우리는 협업을 위해서는 github까지 사용해야 합니다.

원격 저장소 연결

git remote add <name> <url>
  • name이라는 이름으로 url을 연결 (nameurl 별칭을 의미한다.)
  • nameurl은 필수

git remote add origin https://github.com/iamaiden/git-practice

위와 같이 명령어를 사용할 수 있습니다.
origin이라는 name으로 url을 연결한다는 의미입니다.
이후에는 url에 대신에 name을 사용하면 됩니다.

원격 저장소에 버전 내역 반영 (git push)

git push <name> <branch>
  • git remote를 하고나면 기본적으로 master라는 브랜치가 생성 됨
  • git push --help 를 입력했을 때 대괄호([])에 나오는 명령어는 옵션
  • git push url별칭(ex. origin) url Branch(ex. master)

git push origin master

지역 저장소의 master 브랜치의 버전 내역을 원격 저장소의 master 브랜치에 반영합니다.

원격 저장소에서 내용 불러오기 (git pull)

git pull <remote> <branch>
  • 협업 시 충돌을 막기 위해서 작업 전에 git pull 명령어로 시작

git pull origin master

원격 저장소의 master 브랜치의 버전 내역을 로컬 저장소의 master 브랜치에 반영합니다.

git reset

  • 커밋을 초기화 시키고 싶을 때 사용
git reset HEAD~1
git reset --mixed HEAD~1

HEAD는 현재 커밋의 위치를 나타냅니다.
위의 명령어는 현재 커밋의 위치에서 한개의 커밋 내용을 뒤로 돌리는 의미를 가지고 있습니다.
두 명령어 모두 같은 기능을 수행합니다.

커밋 이후 해당 명령어를 사용하게 되면 파일들은 modified 상태로 변경됩니다. (committedmodified)


git reset --soft HEAD~1

--soft라는 옵션을 추가하게 되면 파일들이 staged 상태로 변경됩니다. (committedstaged)


git reset --hard <commitId>

<commitId> 이후 작성한 모든 커밋 내용을 삭제합니다.


git reset --hard HEAD~1
  • committed 상태를 수정 이전 혹은 생성 이전 상태로 변경 (committed → 기존 상태)
  • git reset HEAD~1git restore <fieName> 과정과 동일한 명령어 기능을 가지고 있다.

이미 github에 올라간 내용을 되돌리기 위해선 어떻게 해야 할까요?

git reset 명령어를 사용하게 되면 커밋 자체가 사라지기 때문에 되돌리려고 하는 내용을 다른 작업자가 알 수 없습니다.
그래서 되돌리는 내용도 표시할 수 있도록 git revert 명령어를 사용합니다.

git revert

  • 되돌리려고 하는 커밋을 그대로 유지하고, 새로운 커밋을 통해서 되돌리는 기능
  • 보통 협업할 때 revert 명령어를 주로 사용한다.
  • 되돌리려고 하는 내용을 공유하기 위해서 사용한다.
git revert HEAD
git revert <commitId>

최근 커밋을 되돌리거나, <commitId> 를 통해서 커밋을 되돌릴 수 있습니다.

revert 명령어를 취소하는 것은 커밋을 되돌리는 것과 동일합니다.

git reset --hard HEAD~1 명령어를 사용하면 됩니다.

git branch

  • 보편적으로 master 브랜치가 전체 프로젝트의 중심이 된다.
  • 신기능 등을 개발할 때 새로운 브랜치를 이용해서 신기능을 개발할 수 있다.

git branch라고 입력하게 되면 현재 존재하는 브랜치의 목록을 나타냅니다.

브랜치 생성

git branch <branch>

브랜치 삭제

git branch -d <branch>

브랜치 이동

git checkout <branch>
  • 입력한 브랜치로 작업 공간을 이동한다.

브랜치를 나눠서 사용하는 이유

신기능을 개발하다가 운영 이슈 혹은 버그가 발생하게 되면, 브랜치를 나누지 않았을 경우 개발하던 신기능을 모두 되돌려야 합니다.

하지만 브랜치를 나눠서 사용하게 되면 운영에서 사용하고 있는 브랜치를 master 브랜치에 두고, 신기능을 개발하는 브랜치를 따로 생성해서 작업하게 되면 운영 이슈가 발생했을 때 브랜치 이동을 통해서 서로 코드의 간섭을 받지 않게 됩니다.

운영 이슈를 master 브랜치에서 해결하고 다시 본인의 브랜치에서 신기능 개발을 이어갈 수 있습니다.

그렇기 때문에 항상 작업을 시작할 때는 git branch 명령어를 통해서 현재 브랜치의 위치를 확인하는 습관을 들이는 것이 좋습니다.

추가적으로 git pull origin <branch> 명령어를 이용해서 다른 작업자들이 작업한 내용을 동기화하고 작업을 진행하는 것이 좋습니다.

git merge

  • 현재 브랜치에서 다른 브랜치의 변경 내역을 가져온다.
git merge <branch>

만약 develop 브랜치에서 master 브랜치의 변경 내역을 가져오고 싶다면,
git checkout developgit merge master 순서로 명령어를 입력하면 됩니다.
merge 과정을 포기하고 싶다면 git merge --abort 명령어를 입력하면 됩니다.

git rebase

  • 현재 브랜치에 다른 브랜치의 변경 내역을 가져오면서 base를 재설정한다.
git rebase <branch>

git merge의 경우에는 현재 브랜치에 다른 브랜치의 변경 내역을 가져오면서 새로운 커밋이 발생하게 되는데, git rebase의 경우에는 현재 브랜치와 다른 브랜치의 변경 내역을 시간 순서대로 반영하고, 새로운 커밋이 발생하지 않습니다.

하지만 많은 작업자들이 사용하는 브랜치의 경우 rebase 명령어를 사용하는 것은 위험합니다.

기존 작업자들의 커밋 히스토리가 변경되는 경우에는 각 작업자들은 떄에 따라 자신의 커밋을 다시 반영하거나 재작업을 해야할 수도 있습니다.

git rebase 진행 중 confilct가 발생하는 경우, git rebase --continue 명령어를 입력하면 됩니다.

rebase 과정을 포기하고 싶다면 git rebase --abort 명령어를 입력하면 됩니다.

conflict가 발생했을 경우

git mergegit pull, git rebase 와 같은 명령어를 사용하다보면 conflict가 발생할 수 있습니다.

다른 작업자와 같은 코드를 수정하게 되서 나타나는 "충돌"입니다.

이러한 경우 우선적으로 해당 코드 내용을 수정합니다.

수정하지 않고 파일을 추가, 커밋, 푸시하게 되면 conflict가 발생한 부분은 각 브랜치에서 들어온 내용을 모두 반영하게 됩니다.

수정이 완료 됐다면 해당 파일을 addcommitpush 합니다.

git commit -am <commitMessage>
git push origin <branch>

git cherry-pick

  • 다른 브랜치의 변경 내역을 가져오고 싶은 경우에 대부분 rebase, merge 명령어를 사용한다.
  • 특정 변경 내역을 가져오고 싶을 때 cherry-pick 명령어를 사용한다.

1개의 커밋을 적용

git cherry-pick <commitId>

1개 이상의 커밋을 적용

git cherry-pick <commitId> <commitId>

범위를 이용해서 커밋을 적용

git cherry-pick <commitId>..<commitId>

앞에 입력한 <commitId> 부터 뒤에 입력한 <commitId> 이전의 모든 커밋을 적용합니다.

git stash

  • 어느 브랜치에서 수정 작업을 진행하던 중 다른 브랜치로 이동하고 싶을 때 사용한다.
  • 보통 작업을 진행하던 중 다른 브랜치로 이동하게 되면 에러가 발생하게 된다.
  • 임시 저장소를 생성해서 해당 작업 내용을 저장한 뒤 브랜치를 이동한다.

임시 저장소 생성

git stash
  • 작업 중인 내용이 임시 저장소에 저장이 되고, 현재 브랜치에는 수정 사항이 없어지게 된다.
  • 이후 git checkout 명령어를 사용해서 다른 브랜치로 이동할 수 있다.

임시 저장소 목록

git stash list
  • 저장된 내용을 목록으로 확인할 수 있다. 최근에 추가된 내용이 0번으로 추가된다.

저장 내용 반영

git stash apply
  • 저장 내용을 현재 브랜치에 반영한다.

임시 저장소 삭제

git stash drop
  • git stash apply 명령어를 사용하게 되는 경우 저장 내용은 반영하지만, 임시 저장소에 해당 내용이 삭제 되지는 않는다.

  • 저장 내용 반영과 저장소 삭제를 동시에 진행하고 싶다면, git stash pop 명령어를 사용하면 된다.

git stash 명령어를 유용하게 사용하는 경우는 브랜치를 착각했을 때입니다.

develop 브랜치에서 작업해야 되는 기능을 브랜치를 확인하지 않고 master 브랜치에서 작업했다고 생각해봅시다.

이러한 경우에는 작업한 내용이 크지 않다면, 수정 사항을 git restore 명령어를 통해서 되돌리고 브랜치를 이동할 수 있습니다.

하지만 작업 내용이 많다면 이렇게 하기 쉽지 않을 것 입니다. 이러한 경우에는

git stash
git checkout develop
git stash pop

위와 같이 명령어를 입력하게 되면 모든 수정 사항이 develop 브랜치로 이동됩니다.

git stash pop 명령어를 사용했을 때, conflict가 발생하게 될 수 있습니다. 이러한 경우에는 동일하게 수정하고 반영하면 됩니다.

마무리

하나하나의 명령어는 조금 더 자세한 설명을 찾아봐야 되겠지만, 정리한 명령어를 가지고 git을 사용하시는데는 큰 문제가 없을거라고 생각합니다!

언젠가는 git에 대해서 잘 정리해놓고 싶은 생각이 있었는데 이렇게라도 정리를 하게 되서 뿌듯합니다. 👍

출처

0개의 댓글