Git 강의 정리 및 리뷰

  • 2022/06/05
  • 7-minute read

원본 영상 - Git으로 만드는 전설의 레시피 - Udemy

Table of Contents

Git ?

  • 버전을 편하게 관리하게 도와주는 도구
  • ex) 과제_최종, 과제_진짜최종, 과제_진짜진짜최종 …
  • 위와 같은 여러 개의 파일을 생서하는 문제 등을 해결하기 위한 도구
  • 모든 버전의 파일을 기록해두고, 변화한 내용을 확인할 수 있고, 언제든 돌아갈 수 있는 기능을 제공
  • 대표적으로 개발자의 코드를 지속적으로 수정 및 관리를 위해서 주로 사용
  • 개발자의 필수 도구 중 하나
  • Git의 장점
    • 최종 과정까지의 중간 히스토리를 볼 수 있음
    • 이전 버전으로 돌아갈 수 있음
    • 여러 개발자가 협업할 수 있는 환경을 만들 수 있음 (개발한 내용을 합칠 수 있음)
  • 버전 관리 및 협업을 가능하게 해주는 도구
  • GitHub $\rightarrow$ Git으로 저장된 내역을 원격으로 관리하고 저장하는 공간을 제공하는 서비스
  • Git이 없다는 것은 Save 기능이 없는 게임을 하는 것과 같음

Git 설치

  • Git을 제대로 사용하고 배우기 위해 필요한 내용
  1. Git 설치하기
  2. Visual Studio Code 설치하기
  3. GitHub 계정 만들기

Git 사용

  1. Git 테스트를 위한 폴더 생성
  2. 해당 폴더에서 terminal 열기 (Windows라면 Git Bash 사용 권장)
  3. git init 명령어 입력하기 $\rightarrow$ Git local 저장소 생성(.git 폴더 생성), 기본 이름은 master or main Git init result
  4. VS Code로 해당 폴더를 열어서, 새로운 파일 README.md파일 생성하기 (내용은 아무거나 상관 없음)
  5. terminal에서 git add README.md를 입력해서, 해당 파일을 관리
    • git add <<FILENAME>> $\rightarrow$ 특정 파일을 git이 관리하도록 추가하는 명령어 Git add result
  6. terminal에서 git commit -m "비빔밥 레시피 1번 밥 짓기 추가"를 입력해서, 해당 버전을 저장
    • git commit -m "Message" $\rightarrow$ 현재까지의 변경 사항을 저장 (해당 내용을 확인할 수 있는 문구를 Message 부분에 입력해서 함께 저장) Git commit result
  7. terminal에서 git log --oneline을 입력해서, 저장된 기록을 확인
    • git log --oneline $\rightarrow$ 현재까지의 변경 사항을 확인 Git log result
  8. README.md파일에 다른 내용을 추가하고 5 ~ 7의 과정을 응용하여 새로운 내용을 저장해본다.
  • commit은 여러 개의 변화를 한 번에 저장하고 관리할 수 있으므로, commit message는 아주 잘 관리해서 올리는 것이 중요!

GitHub에 올리기

  1. GitHub에서 저장소 만들기 (우측 상단 +, New Repository 선택)
    • Repository 이름 설정, 설명 내용 추가, Public or Private 설정
    • Add .gitignore $\rightarrow$ 특정 파일을 Git이 관리하지 않도록 하는 설정 파일을 미리 생성할지 여부 지정
    • Choose a license $\rightarrow$ 오픈 소스를 생성했다면, 이에 대한 라이센스 지정
  2. 생성되면 뜨는 가이드 중 ...or push an existing repository from the command line 부분 따라하기
    • git remote add origin <<URL>>
      • remote는 원격 저장소 (github 등)을 의미
      • remote add는 원격 저장소를 추가한다는 의미
      • 추가하는 원격 저장소의 이름을 origin으로 하겠다는 의미 (다른 것으로 변경 가능)
      • URL부분은 추가할 원격 저장소의 주소를 적어줄 것
    • git branch -M main
      • branch는 git 저장소의 branch (갈래)를 의미 (뒤에서 설명)
      • branch -M <<name>>은 현재 branch의 이름을 name으로 바꾼다는 의미
    • git push -u origin main
      • push는 로컬 저장소의 내용을 원격 저장소로 보내는 명령어
      • origin main은 origin 원격 저장소에 main이라는 branch로 보내겠다는 의미
      • -u 옵션은 로컬 저장소를 원격 저장소에 연결하기 위한 명령어 (최초 1회만 필요)
  3. terminal에서 git remote -v를 입력하면, 추가된 원격 저장소를 모두 볼 수 있음

GitHub에서 받아오기

  • 원격 저장소와 로컬 저장소를 동기화할 때 사용
  • 일반적으로 여러 명이 원격 저장소에 데이터를 업로드하는 경우, 내 저장소에도 동기화를 시키기 위해 사용
  1. README.md 파일을 github repository에서 직접 수정 (연필 버튼 클릭)
  2. 로컬 저장소의 terminal에서 git pull을 입력
    • git pull은 원격 저장소의 변경 사항을 확인하고 이를 받아오는 기능
    • git fetch는 원격 저장소의 변경 사항을 확인만 하는 기능 (받아오지는 않음)

Branch 추가하기

  • 개발자가 개발 중에 하나의 Branch만 사용한다면, 최종본에 버그가 생기면 과거로 돌아와야만 하는 문제가 생김
  • 하지만 main branch는 일반적으로 기능이 검증되고, 확실한 내용만 있기를 바라는 경우가 많음
  • 따라서, 새로운 branch를 생성하여 수정을 하는 것이 바람직함 (평행 우주를 생성하는 것)
  • 수정을 하다가 기능이 정상적으로 수행한다면 다시 합쳐줄 수 있음
  • terminal에서 git branch bibimbap 명령어를 입력하여 새로운 branch를 생성할 수 있음
  • terminal에서 git switch bibimbap 명령어를 입력하여 다른 branch로 이동할 수 있음
  • 작업 중인 branch에서의 내용은 다른 branch에서는 영향을 받지 않음!
  • 따라서, 새로운 branch에서 실험적인 내용 등을 수행해볼 수 있음

Merge 하기

  • 새로운 Branch에서 충분히 검증이 되고, 확인이 되었다면, 다시 main Branch에 합쳐줄 수 있음
  1. bibimbap branch에서 README.md 파일을 수정하고, add 및 commit한다.
  2. 기반이 되는 branch (main)으로 돌아간다. git switch main
  3. 합치려는 branch를 merge한다. git merge bibimbap

신중하게 Merge하기

  • 일반적으로 로컬에서 merge하는 경우는 자주 없음
  • 철저한 검증이 필요한데, 이 때 사용하는 것이 Pull Request
  • 로컬 저장소에서 새로운 branch로 진행 후, Pull Request를 날리는 것이 일반적
  • 오픈 소스에 대한 기여 및 코드 리뷰를 위해서 꼭 원격 저장소에 올려서 Pull Request해주는 것이 중요
  1. bibimbap branch로 변경 git switch bibimbap
  2. README.md파일 수정 및 add 및 commit 진행
  3. 원격 저장소에 올리기 git push --set-upstream origin bibimbap
  4. GitHub에 들어가서 올라간 내용을 확인하고, Pull Request 선택
  5. Pull Request를 통해 서로 코드에 대한 코멘트 및 의견을 남길 수 있음

덮어쓰기

  • commit 한 이후, 새롭게 commit하는 대신, Amend를 통해 수정할 수 있음
  • README.md파일 수정 및 add 및 commit 진행
  • 추가적인 수정을 한 후, 새롭게 commit하는 대신 git commit --amend 명령어를 통해 기존 commit을 수정할 수 있음
  • 동일하게 git push를 통해 제대로 commit이 한 번만 되어서 올라갔는지 확인

쥐도 새도 모르게 되돌리기

  • reset 명령어를 이용하여, 초기화를 할 수 있음
  • 우선 실험적인 내용을 README.md파일에 추가하고, add 및 commit을 진행
  • git log --oneline을 통해 각 commit의 고유 번호를 확인 (commit message 앞에 있는 알파벳과 영어로 된 7자리 번호)
  • git reset abcd123과 같이 번호를 입력하여, 특정 commit으로 돌아가기 가능
  • Unstaged changes after reset이라는 문구를 확인할 수 있음
    • 리셋 이후의 변화가 스테이지 되지 않았다???
    • 이전 commit으로 돌아는 왔지만, 변경 사항은 그대로 남기고 돌아왔기 때문
    • git reset의 추가 옵션 중, 기본 옵션은 --mixed 옵션
    • --mixed 옵션은 변경 사항은 그대로 남긴 상태로, commit의 이력만 reset
    • --hard 옵션은 변경 사항도 그대로 삭제하고, commit의 이력도 삭제
    • 명령어들에 많은 옵션이 있으므로, 사용에 필요한 내용을 확인하고 사용하는 것이 좋다.
  • reset 명령은 흔적도 남기지 않고 돌아가므로, 다시 복구할 수 있는 방법이 없다는 단점도 존재

흔적을 남기고 되돌리기

  • 특정 변경 사항만을 없애고 싶을 때 revert를 사용할 수 있음
  • 여러 개의 commit 기록 중, 특정 부분의 변경 사항만 삭제
  • commit의 일련번호를 확인하고, git revert abcd123과 같이 입력해서 돌아갈 수 있음
  • 돌아가는 기록 자체가 새로운 commit으로 남기 때문에, reset보다 revert를 훨씬 자주 사용

잠깐 변경 사항 남겨두기

  • 다른 branch로 변경하기 전, 변경 사항을 미리 저장해두는 기능
  • commit할 정도는 아니고, 지우자니 안될 것 같은 상황에 사용
  • 새로운 branch를 생성하는 것 대신, 여러 가지를 테스트할 때도 유용하게 사용할 수 있음
  • 단순히 git stash 명령어만을 이용해도 저장할 수 있음 (하지만 설명 부분이 부실)
  • git stash push -m "Messages" 명령어로 사용할 수 있음
  • add해놓지 않아도, 기존 이후의 변경 사항을 모두 저장
  • Saved working directory and index state On bibimbap과 같은 문구가 출력되며 내용이 저장됨
  • stash라는 공간으로 옮겨지는 것
  • git stash list를 통해 저장된 내용을 확인할 수 있음
  • 이 때 출력되는 stash@{0}과 같은 부분을 기억해두었다가
  • git stash show stash@{0} -p로 입력하면, 더 상세한 변경 사항도 확인할 수 있음
  • 여러 개의 실험적인 내용을 stash에 저장해둘 수 있음
  • 여러 개 저장 시, 가장 마지막에 저장한 것이 0번에 저장됨
  • git stash apply를 통해 가장 최근에 저장한 내용을 복구할 수 있음
  • git stash apply stash@{2}와 같이 입력해서, 특정 저장 내용도 복구할 수 있음

다른 branch의 변경 사항 가져오기

  • 특정한 branch에서 commit한 변경 사항 중 다른 branch에도 적용하고 싶은 내용이 있을 때 사용
  • cherry-pick 명령어를 통해서 특정 commit의 변경 사항을 다른 branch에도 적용
  • 변경하고 싶은 commit의 일련번호를 확인
  • 적용하고 싶은 branch로 변경 후 git cherry-pick abcd123으로 특정 commit을 적용
  • 충돌이 발생한다면 아래와 같은 내용이 출력
  • error: could not apply abcd123... message
  • hint: after resolving the conflicts, mark the corrected paths
  • hint: with 'git add <paths>' or 'git rm <paths>'
  • hint: and commit the result with 'git commit'
  • 충돌 해결 (겹치는 부분 제거 or 둘다 적용 등) 진행
  • 충돌 후 add 및 git cherry-pick --continue를 통해 다시 merge 및 commit message도 변경할 수 있음

오픈 소스에 기여하기

  1. fork하기 (일반적으로 쓰기 권한이 없으므로, 저장소를 내 저장소로 가져와서 작업하기 위함)
  2. 로컬 저장소로 clone 해오기 (git clone <<Fork한 GitHub 주소>>)
  3. 새로운 branch를 만들어서 작업을 진행
  4. fork한 저장소에 다시 업로드 후, Pull Request 날리기

추가 내용

  • Git은 누가…?
    • Git을 만든 사람은 리누스 토르발즈
    • 바로 LINUX를 만든 사람!
    • 나무위키에 찾아보면 아주 소프트웨어 관리가 맘에 안들어서 분노한 나머지… 2주만에 만들어냈다고 한다… 대단…
  • Git은 CLI만 있나요..?
    • Git을 꼭 터미널로 사용할 필요는 없음
    • GUI에서 사용하려면 SourceTree가 대표적으로 사용
    • GUI가 시각적으로 보기엔 더 좋음!
    • CLI만을 지원하는 경우도 있으므로, CLI도 알아두어야 함!
  • commit message 잘 적는 방법?
    • 일반적인 약속들이 있음
    • 한 단위의 commit은 한 commit에 작성하기
    • 한 commit에 2개 이상의 작업을 넣지 않기
    • commit의 성격에 따라 특징 표시해두기
    • 참고 - Udacity Git Commit Message Style Guide
      • 제목에 포함되는 Type
        • feat : 새로운 특징 추가
        • fix : 버그 수정
        • docs : 문서 업데이트 시
        • style : 포매팅, 세미콜론 빼먹음 등의 코드 외적인 변화
        • refactor : 코드 리팩토링 시
        • test : 테스트를 추가하거나, 테스트의 변경 사항이 있을 시
        • chore : 빌드 태스크 업데이트 및 패키지 매니저 수정 등
      • Subject
        • 50글자 넘지 않기
        • 대문자로 시작하고 마침표는 없이!
        • 과거 시제를 사용하지 않고, 명령형으로 사용
      • 이 외의 내용도 사이트에서 확인할 수 있음!
    • 좋은 예시 - angular repository
    • GitMoji 사용하기
    • commit message 앞에서 GitMoji를 이용하여 더 재밌게 표현할 수도 있음!
    • 중요한 것은 일관된 약속이 있다는 것이 중요!

Review

  • 모르는 내용이 한 두개 더 있어서 들을만 했던 것 같다.
  • 가장 알찼던 것은 commit message를 어떤 식으로 잘 작성하면 되는지에 대한 내용이었다.
  • 회사 내부적으로 어떤 규칙을 정할지를 또 논의해서 진행해봐야 할 것 같다.

comments