[Git - ⑦] Github 연동 + push, pull + branch
[Git - ⑦] Github 연동 + push, pull + branch
[Git - ⑥] 충돌 해결 + SourceTree에서 사용 [Git - ⑥] 충돌 해결 + SourceTree에서 사용 [Git - ⑤] branch + merge, rebase [Git - ⑤] branch + merge, rebase [Git - ④] git reset, revert + SourceTree 사용 [Git - ④] git reset, revert +
soohykeee.tistory.com
Git이 다른 VCS와 다른 강점은 무엇이 있을까?
크게 Snapshot, 분산 관리가 있다.
스냅샷은 쉽게말해서 사진을 찍듯이 특정 시간, 시점에 데이터 저장 장치의 파일 시스템을 포착해 별도의 파일이나, 이미지로 저장하는 기술이다. 해당 기술과 상반되는 기술로는 델타 방식이 있다. 사진을 찍는 것 처럼 특정 시간에 데이터를 저장하게 된다면 추후에 파일이 길어지거나 변경이 많아져도 문제가 되기 쉽지않다. 하지만 델타방식을 사용한다면 앞서의 모든 수정 기록을 모두 저장하게 되므로 불필요한 정보 또한 가지게 되는 것이다.
분산 버전 관리도 Git의 강점이다. 이와 상반되는 중앙 집중식 관리는 원격 저장소에 의존적이다. 그렇기에 로컬에서의 행동 제약이 많다. 하지만 분산 버전 관리는 우리가 앞서 사용했던 것처럼 clone, pull, push를 사용하여 로컬에서 자유롭게 작업이 가능하다.
Git의 3가지 공간
파일의 상태를 위에서 보이는 것 처럼 크게 3가지로 나눌 수 있다.
쉽게 말해 Repositor에는 commit까지 완료된 상태를 말한다. Working directory는 수정 사항이 필요한 상태를 말한다. 여기서 또 나뉘는 Untracked, Tracked는 쉽게 말해서 Untracked는 이전까지 관리한 적이 없는 예를 들어 새롭게 생성된 것을 말하고, Tracked는 이전에 관리해본 적이 있는 예를 들어 수정이 된 것을 말한다. Staging area는 우리가 앞서 Git을 사용할 때 add해준 상태를 말한다. 커밋하여 Repository로 들어간 파일이 수정이 되면 다시 Working directory의 Tracked로 들어가게 된다.
Working directory
- untracked : add 된 적이 없는 파일 or ignore 된 파일
- tracked : add 된 적이 있거나, 변경내역이 있는 파일
- git add 명령어로 Staging Area 로 이동
Staging Area
- 커밋을 위한 단계
- git commit 명령어로 repository로 이동
Repository
- .git directory 라고도 불린다.
- 커밋이 된 상태를 말한다.
파일의 삭제 및 이동
파일의 삭제를 해보는 예제를 진행해보겠다.
- tigers.yaml 파일을 삭제한 뒤, git status로 살펴보고, git reset --hard로 복원
- git rm tigers.yaml 로 파일을 삭제하고, git status로 살펴보고, git reset --hard로 복원
우선 tigers.yaml 파일을 직접 삭제한 뒤, git status를 입력하게 되면 다음처럼 빨간색 글씨로 tigers.yaml이 삭제되었다고 나온다. 이 삭제한 것을 반영하기 위해서는 add와 commit을 해줘야 한다. (현재 예제는 tigers.yaml파일을 추후에도 사용해줄 것이기에 commit까지 해주지는 않을 것이다.)
우선 위의 상태에서 git add . 을 입력하게 된다면 Staging area로 넘어가게 되는 것이다. 앞서 말했듯, 굳이 commit까지는 해주지 않을 것이기에 git reset --hard 를 통해 삭제하기 전으로 돌려줄 것이다. (해당 기능은 뒤에서 다시 설명이 나온다.)
위에서 처럼 tigers.yaml 파일의 삭제 및 add 처리를 한번에 해주기 위해서 git rm tigers.yaml 을 입력해보겠다. 위에서 delete와 add를 나눠서 해주지 않고 한번에 처리하는 것을 확인할 수 있다. 이것도 reset해주자.
파일의 이동의 에제를 해보겠다.
- tigers.yaml 의 파일 명을 zzamtigers.yaml 로 변경 뒤, git status로 살펴보기
- tigers.yaml 파일명을 git mv tigers.yaml zzamtigers.yaml 로 실행 뒤 비교
tigers.yaml 파일 명을 수동으로 바꿔준 후, git status를 하게 되면 2가지 변화를 감지한다. tigers.yaml이 삭제되고, zzamtigers.yaml파일이 새로 생성된 것으로 감지한다. 하지만 해당 내용을 git add . 해주게 되면 이름이 바뀐 것이라고 인지를 하게 된다.
해당 예제도 git reset --hard 로 바뀌기 전으로 돌려주자.
git mv tigers.yaml zzamtigers.yaml 을 사용해보면, 2가지가 한번에 되는 것을 확인할 수 있다.
Working directory <--> Staging area
예를 들어, a b c와 같은 3파일을 작업한 뒤 add 해줘서, Staging area에 있다고 가정해보자. 만약 a와 b는 관련이 있는 파일이기에 같이 commit해줘도 되지만, 만약 c의 경우는 앞서 2파일과는 연관이 적기에 나중에 commit해주길 원한다면 다음 명령어를 사용해주면 된다.
git restore --staged (파일명)
해당 명령어를 사용해주게 되면, Working directory로 가게 되는 것이다.
만약 --staged 를 제외하게 된다면 working directory에서도 제거된다.
tigers.yaml, pumas.yaml, panthers.yaml 파일을 아무렇게나 수정 한 후, 위의 명령어를 사용해보는 예제를 진행하겠다.
해당 파일들의 내용을 임의대로 수정해준 후, add 해주었다. 이제 해당 파일들은 Staging area에 있는 것이다. 여기서 이번에 pumas.yaml 파일을 해당 commit에 추가해주지 않을 것이기에 다시 Working directory로 이동해주려고 한다고 해보자.
또한 변경사항도 없애주기 위해서는 git --restore pumas.yaml 을 작성해주면 해당 pumas에서의 변경사항도 사라지게 된다.
Reset의 3가지 옵션
- --soft : repository에서 staging area로 이동
- --mixed : repository에서 working directory로 이동 (default)
- --hard : 수정사항 완전히 삭제