본문 바로가기
ETC/Git

[Git] GitHub 기본

by 컴돈AI 2023. 12. 14.

목차

    GitHub

    • Git은 버전관리 프로그램
      • .git 폴더가 repository입니다. (=로컬 저장소)
      • 하지만 이 폴더는 로컬 피씨에 저장되어져 있기 때문에 컴퓨터가 날라가게 되면 같이 사라져 버리게 됩니다.
      • 이러한 것을 방지하기 위해 온라인 repository가 필요합니다. GitHub
    • GitHub는 원격저장소(온라인 repository)
      • 로컬 피씨에 저장된 버전관리폴더를 온라인으로 백업하는 원격저장소입니다.
      • 온라인으로 버전관리 프로그램을 사용하면 협업도 보다 효율적으로 할 수 있습니다.

    원격 저장소 생성

    • GitHub 페이지에서 (+ 버튼 → New repository)를 통해 손쉽게 원격 저장소를 생성할 수 있습니다.
      • Repository name / Description / Public or Private / Add a README file 체크 해제 등 설정을 진행해 주고 Create repository 클릭
    • 생성된 원격 저장소의 주소는 원격 저장소 페이지 url 뒤에 .git을 붙인 것입니다.
    • git remote add 변수명 원격저장소주소를 지정해 주게 되면 추후에 원격저장소주소를 변수명으로 간단하게 대체해서 작성할 수 있습니다.
      • git remote add origin https://github.com/user/repo.git
      • 보통 origin을 변수명으로 많이 사용합니다.

    로컬저장소 → 원격저장소 (git push)

    • 작업했던 로컬저장소를 원격저장소에 저장해 보도록 하겠습니다.
    • git init을 통해 로컬 저장소에서 버전관리를 진행했던 프로젝트를 다음 명령어로 손쉽게 원격저장소로 업로드 가능합니다.
      • git push -u 원격저장소주소 올릴로컬브랜치명
      • 보통 올릴로컬브랜치명은 main인 경우가 많습니다.
      • -u는 git push 할 때 지정한 원격저장소 주소와 올릴로컬브랜치명을 git에게 기억하고 있으라고 설정해 주는 것입니다. 따라서 한 번만 위 명령어를 쳐주게 되면 다음부턴 git push만 해도 알아서 원격저장소주소의 브랜치에 업로드 되게 됩니다. 
        • git remote add 된 경우에는 git push -u origin main처럼 손쉽게 작성이 가능합니다.

    원격저장소 → 로컬저장소 (git clone)

    • 원격저장소에서 완전히 새롭게 코드를 가져오고 싶을 경우는 다음 명령어를 입력합니다.
      • git clone 저장소주소

    원격저장소 → 로컬저장소 (git pull)

    • 원격저장소를 사용하면 협업도 가능합니다. 각자 작업한 것을 원격 저장소에 push 하게 되면 손쉽게 협업이 가능합니다.
    • 하지만, 이런 경우 여러 사람이 협업하기 때문에 매번 원격저장소의 코드는 업데이트될 것입니다. 따라서 충돌문제가 빈번하게 발생하게 됩니다.
      • 예시 : 원격저장소에서 코드를 내려받은 뒤에 다른 누군가가 원격저장소에 push를 한 경우, 다시 원격저장소에 코드를 올리려고 하면 오류가 발생하게 됩니다.
    • 따라서 push를 하기 전 원격저장소의 코드를 내려받고, 내 로컬저장소의 코드와 merge 하는 과정이 필요합니다. 이러한 과정을 한 번에 처리해 주는 코드가 git pull입니다.(git fetch(최신커밋 가져오기) + git merge)
      • git pull 원격저장소주소 브랜치명
      • git push 할 때 -u를 통해 원격저장소주소와 브랜치명을 지정해 두었다면 git pull만 작성하여도 됩니다.
      • git pull에는 --rebase라는 옵션이 존재합니다. 이는 만약 pull을 할때 로컬 브랜치의 변경사항을 원격 저장소의 변경사항 위에 rebase하는 방식으로 작동합니다.
        • git pull --rebase 원격저장소주소 브랜치명
    • 하지만 이처럼 main이 되는 브랜치를 바로 수정하기보다는 자신만의 브랜치를 만들고 코드를 수정하는 경우가 많습니다. 따라서 다음과 같은 문제도 고려해 볼 수 있습니다.
      • 만약 내가 원격저장소의 main 브랜치 코드에서 나만의 feature 브랜치를 생성해 코드를 작성하고 있다고 가정해 보겠습니다. 이때  원격저장소의 main 브랜치 코드가 업데이트된다면 어떻게 대처해야 할까요?
        • 먼저 로컬의 main 브랜치를 최신상태를 업데이트해야 합니다. 이를 위해 main 브랜치로 switch 하고 최신 변경사항을 가져옵니다.
          • git switch main
            git pull origin main
        • 그럼 이제 작업 중인 feature 브랜치와 업데이트된 main 브랜치를 통합해주어야 합니다.
          • 먼저 feature 브랜치로 이동해 줍니다
            • git switch feature
          • feature 브랜치에서 main 브랜치를 git merge main을 통해 merge 시킬 수도 있지만, 이는 커밋 히스토리가 다소 복잡해질 수 있습니다.
          • 따라서 rebase 방식을 이용해서 feature 브랜치의 시작점을 main 브랜치의 최신 커밋으로 옮깁니다. (이때 충돌이 발생할 수 있으므로, 충돌을 해결하고 rebase를 계속 진행해야 합니다.)
            • git rebase main
        • 이제 이어서 다시 feature 브랜치를 작성해 주면 됩니다. 추후에 이제 feature 브랜치를 push 한 뒤에 main 브랜치와 merge를 요청하는 pull requests를 요청하면 됩니다. (pull requests는 github에서 하는 branch merge 작업입니다.)
          • 제목과 설명을 작성한 뒤에 Create pull request 를 요청하면 됩니다.
          • 원격저장소 관리자는 확인 후 merge가 가능하다면 merge 요청을 수락합니다.
            • 여러 종류의 merge 방식을 선택 가능합니다.
      • 그렇다면, 만약 현재 main -> develop -> feature 순서로 분기된 feature 브랜치에서 작업중일때, main이 업데이트 될경우 어떻게 해야할까요?
        • 이것도 위 방법과 다를것이 없습니다. 다만 그 과정이 한번더 추가된 것 뿐입니다.
        • 먼저 로컬 main 브랜치를 업데이트해줍니다.
          • git switch main
            git pull origin main
        • 중간 develop 브랜치 업데이트
          • git switch develop
            git rebase main
        • 작업 중인 feature 브랜치 업데이트
          • git switch feature
            git rebase develop