나의 현 상황은 git을 다루며 repository로 관리가 된다는 사실을 깨닫고 git을 이용하고 있었다.
하지만, branch를 사용하면서 git에 대해 헷갈리기 시작했다.
왜 헷갈리냐면, 로컬 repository의 특정 브랜치로가서 원격 repo의 내역을 pull했지만 반영이 안되고 있었다.
(develop ,feature/group, feature/member) 이렇게 브랜치를 파논 상태였다.
내가 생각한 논리대로 흘러가지 않아서 혼동이 온 상태이다.
내가 원하는 건 develop 브랜치에 upstream의 develop 내역을 가져오는 것이다.
빙글님께서 develop을 내꺼, 오리님꺼와 express.js에 코드를 추가 후 merge해주셨기에 새로운 develop을 가져오려고 했다.
$ git checkout develop
# develop 브랜치로 이동
$ git pull upstream develop
# 원격 repository의 develop 브랜치를 로컬에 가져옴.
그러고, develop 브랜치를 확인하면 원격 저장소의 내역이 업데이트 되어있지 않다..
한번 이게 왜 나타나는지 반드시 찾을 꺼다.
FETCH_HEAD 브랜치에 원격 repository 내역이 저장되는 것을 알 수 있다.
왜 그런걸까?
git의 repository 파일 저장 원리
git의 로컬 repository에 파일을 관리하는 방법을 알려주는 블로그이다.
git은 로컬 repo, 원격 repo가 있으며,
로컬 repo에서 관리를 하고 원격 repo에 push하기 때문에
로컬 repository를 관리하는 방법에 대해 알아보자.
모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나눈다.
Tracked 파일은 또 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 상태 중 하나이다.
그리고 나머지 파일은 모두 Untracked 파일이다.
간단히 말하면, Tracked 파일은 git이 알고 있는 파일
Untracked 파일은 git이 모르고 있는 파일 (새로 생성한 파일)
마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서 어떤 파일을 수정하면 Git은 그 파일을 Modified 상태로 인식한다. 실제로 커밋을 하기 위해서는 이 수정한 파일을 Staged 상태로 만들고, Staged 상태의 파일을 커밋한다.
git add 명령은 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용한다
따라서, 새로 생성한 파일 & 수정한 파일이 있으면 git add 명령으로 commit 가능한 파일로 만들어 줘야한다.
그럼 git의 repository에 파일을 저장할 때는 특정한 파일형태가 있음을 알 수 있다. (일정한 git의 규칙)
git status / repository의 상태를 알려줌
아래 명령으로 git의 repository와 로컬 디렉토리의 파일을 비교해
repository와 로컬 디렉토리와 파일들이 다른지를 알려준다.
만약 다르면, repository에 업로드해주는 작업이 필요하다고 알려준다.
$ git status
# git에게 읽혀진 파일 형태를 보여줌.
옵션 인자 -s 를 추가하면 파일 상태를 짤막하게 확인할 수 있다.
$ git status -s
# repo의 파일상태를 짤막하게 확인해볼 수 있다.
git push
아래 명령으로 지정한 원격 저장소에 로컬 저장소 코드내역을 업로드 할 수 있다.
대체로 아래 명령으로 organization 원격 저장소에 push를 한다. - 충돌이 발생하는 지점을 확인하기 위함이다.
$ git push origin {브랜치 명}
그치만, 로컬과 자신만의 원격 repo를 가지고 개발을 할 때는
원격 repo의 내역을 로컬 저장소의 소스코드 내역으로 덮어쓰고 싶은 경우가 있다.
그럴 때 -f 를 추가해 덮어 쓸 수 있다.
공동 개발에서 덮어쓰면, 개발이 엉망진창이 될 수 있다. - 서로가 사용하는 모듈과 함수가 다르기 때문이다.
그렇기에 git은 충돌방지가 구현되어 있어, 충돌이 일어나지 않아야 업로드하게 설계되어 있다.
$ git push -f origin {브랜치 명}
git stash
아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어이다. 이를 통해 아직 완료하지 않은 일을 commit하지 않고 나중에 다시 꺼내와 마무리할 수 있다.
특정 브랜치에서 파일을 수정하고 있는데, 다른 브랜치에 가야되는 상황이 있다고 생각해보자.
그럼, 이 상태에서 다른 브랜치로 넘어갈 수 있겠나?
작업 중인 걸 저장도 하지 않고 넘어가면 날아가버리는 게 정상이다.
그래서 작업 중인 걸 중단하고 다른 브랜치로 넘어가기 위해선
두가지 방법이 있다.
1. 작업 중인 파일을 commit하고 다른 브랜치로 넘어간다.
2. 작업 중인 파일을 잠시 두고 다른 브랜치로 넘어간다.
1번과 같은 상황은 수정 중인 파일을 저장하고 commit 하고 다른 브랜치로 넘어간다.
우리는 2번과 같은 상황에서 git stash 명령으로
간단하게 해결 할 수 있다.
$ git stash
# 작업 중인 파일을 임시로 저장 해둔다.
다시 작업을 하기 위해 브랜치로 돌아왔을 때
$ git stash apply --index 명령으로
원래 작업하던 파일의 상태로 돌아갈 수 있다.
이 부분을 정리하면서 새롭게 알게 된 사실은
브랜치를 바꾼다는 건
워킹 디렉토리를 바꾸기에 기존에 작업 중인 것을 저장을 해둬야
작업 내역이 사라지지 않는다.
git의 분산관리 시스템 원리이고 이해하고 받아드려야 한다 ㅋㅋ..ㅋㅋ
'🌤 프로젝트 > UMC 2기: 동네' 카테고리의 다른 글
[팀 프로젝트] AWS EC2 배포를 수행하다 - 팀원들이 나에게 양보해준 뜻깊은 기회 (0) | 2022.08.09 |
---|---|
[팀 프로젝트] 프로젝트하면서 Git과 친해지기 - 4 (git pull로 원격저장소 브랜치 가져오기) (0) | 2022.08.04 |
[팀 프로젝트] 프로젝트하면서 Git과 친해지기 - 2 (Git은 repository로 소통한다.) (0) | 2022.08.03 |
[팀 프로젝트] 프로젝트하면서 Git과 친해지기 - 1 fork repository 최신화하기 & swagger 적용 (0) | 2022.08.01 |
[팀 프로젝트] 동네 백엔드 대면 회의 - 2차 (API 목록 구성) (0) | 2022.07.31 |