프로젝트의 버전 관리와 백업 그리고 협업을 위해서 GIT을 사용한다.
버전관리는 디버깅을 위한 것 ! !
프로젝트 GIT 관리
VS실행 - 폴더 생성 - New File - 폴더이름.txt - Source Control
- 버전 메시지를 적어 커밋(변경사항 제출)
- 처음 시작시 이메일과 이름 설정 (인증 정보)
- 터미널 (Mac 사용시 Git Bash)
git config --global user.name "name" git config --global user.email "your@mail.com"
- 터미널 (Mac 사용시 Git Bash)
git log: 버전 확인
VS 단축키
- Ctrl + J : 터미널 보기/닫기
- Ctrl + B : 왼쪽 사이트 탭 보기/닫기
Git Graph
- extentions 탭에서 git graph 설치
보기 쉽게 버전 확인 가능
Git 동작 과정
Working Directory -> Staging Area -> Repository
- Working Directory : 작업할 파일이 있는 디렉토리
- Staging Area: 커밋(Commit)을 수행할 파일들이 올라가는 영역
- Repository (.git) : Git 프로젝트의 메타 데이터와 테이터 정보가 저장되는 디렉토리
- git은 Staging Area에 있는 것만 Repository로 commit 한다.
- commit id는 지문 (내용을 기반으로 식별됨)
- main은 마지막 작업
- main에 적힌 commit id를 보고 parent의 commit id를 알 수 있음
- parent를 포함한 새로운 버전의 commit id를 해쉬값으로 생성
- 마지막 버전은 HEAD가 가르키는 곳에 기록
Pointer
HEAD -> main -> B(새로 만들어진 버전) -> A(B의 이전 버전)
- HEAD : Working Dir의 버전
- Checkout : HEAD 변경
만약 v2 커밋으로 checkout하고 새로운 커밋 e1을 만든 후, 다시 main 브랜치로 돌아가면, e1은 해당 브랜치의 히스토리에서 보이지 x.
이는 Git에서 브랜치가 특정 커밋을 가리키는 포인터처럼 동작하기 때문.
하지만 e1 커밋은 여전히 Git 내에 존재하며, 커밋 해시를 알고 있으면 언제든지 git checkout <commit_hash> 명령어로 다시 해당 커밋으로 돌아갈 수 있다.
git reflog: HEAD의 이동 기록
git checkout <commit_hash>: 해당 커밋으로 head 이동
branch
- 브랜치(Branch) : Git에서 작업 내역을 분리하여 독립적으로 작업할 수 있도록 하는 포인터
- 기본적으로 Git 프로젝트를 처음 생성하면 main 또는 master라는 기본 브랜치가 생성
- 브랜치를 생성하면, 새로운 작업 공간이 만들어져 기존 브랜치와는 별도로 작업을 진행. 기존 코드에 영향을 주지 않고 새로운 기능을 개발하거나 버그를 수정
git branch <branch_name>: 브랜치 생성
git checkout <branch_name>: 브랜치 전환
브랜치 작업 후 병합
- 브랜치에서 작업을 완료한 후, 해당 작업 내용을 원래 브랜치(main 등)에 반영하려면 병합(merge) 작업이 필요
- 병합은 현재 브랜치에 다른 브랜치의 변경 사항을 통합하는 과정
예를 들어, exp 브랜치에서 작업을 마치고 이를 main 브랜치에 병합하려면
git checkout main: main 브랜치로 전환git merge <exp>: exp 브랜치의 변경 사항을 병합
만약 같은 파일을 다른 branch에서 수정한 후 합친다면?
- 같은 파일의 서로 다른 부분을 수정한 경우:
- Git은 자동으로 병합 가능.
- 예를 들어, 한 브랜치에서는 파일의 상단을, 다른 브랜치에서는 하단을 수정했다면, Git은 이 두 변경 사항을 문제없이 병합.
- 같은 파일의 동일한 부분을 수정한 경우:
- Git은 이 경우 어떤 변경 사항을 적용해야 할지 알 수 없으므로 병합 충돌 (conflict)이 발생.
- 충돌이 발생하면 Git은 병합을 자동으로 완료하지 못하고, 사용자가 수동으로 충돌을 해결해야 함.
checkout : HEAD 변경
reset : HEAD가 가르키는 branch를 변경
GIT HUB 원격 저장소 연결
- git hub repository 생성
- https url 복사
- VS Source Control 더보기 - remote - add remote
- 복사한 url 붙여넣기
- origin(관례)으로 원격저장소 이름 정하기
- VS Source Control 더보기 - push
그럼 main브랜치에 origin이 생긴 것을 확인할 수 있다.
main/origin : remote tracking branch
- 추적 브랜치(Tracking Branch) :로컬 브랜치와 원격 브랜치가 연결된 상태를 의미
- 일반적으로, 원격 저장소에서 브랜치를 처음 가져올 때 로컬 브랜치와 원격 브랜치가 자동으로 연결
- 예를 들어, 원격 저장소에서 main 브랜치를 로컬로 가져왔다면, 로컬에 main 브랜치가 생성되고 이 브랜치는 origin/main이라는 원격 브랜치를 추적하게 됨
- Remote Tracking Branch는 원격 브랜치의 로컬 복사본.
- 예를 들어 origin/main은 원격 저장소의 main 브랜치를 로컬에서 추적하는 Remote Tracking Branch. 이 브랜치는 실제 원격 저장소의 상태를 반영하며, git fetch 또는 git pull을 통해 업데이트 됨.
위와 같은 상태는, 현재 아직 push되지 않은 버전이 존재하는 것은 확인할 수 있다.
push하면 위처럼 변경 된다.
협업 실습
- VS 새 윈도우로 열기
- Clone Repository
- git hub에서 repository url 복사 -> VS에 붙여넣기
- 저장할 폴더 생성 후 open
서로 다른 사람이 다른 파일을 생성한다면?
- left 사용자가 먼저 push 한다면 ? right 사용자는 push가 불가하다
=> fetch하여 원격 저장소와 동기화를 진행 한 후 mergy해야한다.
fetch: 다운로드 . 원격 저장소의 내용을 가져온다.pull: fetch + mergysync: pull + push
right에 pull -> push 하면 정상적으로 올라간다!
이후 left 사용자 또한 pull 하여야 push가 가능하다.
서로 다른 사람이 같은 파일을 수정 한다면?
-
common.txt 파일을 left에서 수정한 후 commit -> push
-
right 사용자는 pull 하면 같은 left와 상태가 됨
이상태에서 각각 변경한다면
-
left 사용자 push : 성공
-
right 사용자 pull : conflict
-
충돌한 코드를 수정한 후 mergy하면 커밋이 가능하다
