목차
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 브랜치를 작성해 주면 됩니다. 추후에 이제 feature 브랜치를 push 한 뒤에 main 브랜치와 merge를 요청하는 pull requests를 요청하면 됩니다. (pull requests는 github에서 하는 branch merge 작업입니다.)
- 제목과 설명을 작성한 뒤에 Create pull request 를 요청하면 됩니다.
- 원격저장소 관리자는 확인 후 merge가 가능하다면 merge 요청을 수락합니다.
- 여러 종류의 merge 방식을 선택 가능합니다.
- 제목과 설명을 작성한 뒤에 Create pull request 를 요청하면 됩니다.
- 먼저 로컬의 main 브랜치를 최신상태를 업데이트해야 합니다. 이를 위해 main 브랜치로 switch 하고 최신 변경사항을 가져옵니다.
- 그렇다면, 만약 현재 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
-
- 만약 내가 원격저장소의 main 브랜치 코드에서 나만의 feature 브랜치를 생성해 코드를 작성하고 있다고 가정해 보겠습니다. 이때 원격저장소의 main 브랜치 코드가 업데이트된다면 어떻게 대처해야 할까요?
'ETC > Git' 카테고리의 다른 글
[Git] (정리)혼자서 GitFlow를 따라 프로젝트 진행하기 (1) | 2023.12.18 |
---|---|
[Git] GitFlow (0) | 2023.12.14 |
[Git] commit 취소하기 (git revert) / commit reset하기 (git reset) (0) | 2023.12.14 |
[Git] Git commit된 파일로 복구하기 (git restore) (0) | 2023.12.13 |
[Git] Git branch / merge (0) | 2023.12.13 |