Git remote fetch/pull, Git push 명령



Git remote fetch



- 아래는 제 개인 Git 계정의 리모트 저장소 이다.



- 리모트 저장소의 모든 자원을 "git clone" 명령을 통해 로컬 저장소로 가져온다.



- 리모트 저장소에 index2.html 파일을 추가한다.


P.S: 생성한 index2.html 파일의 Commit index5717f9...18a 와 같다.



- 리모트 저장소(origin) 확인 후 "git fetch" 명령을 통해 로컬 저장소 와 리모트 저장소 의 상의한 브랜치 내역을 가져온다.(로컬 저장소에는 리모트 저장소와 달리 index2.html 파일에 내한 내역은 존재하지 않는다.)



P.S: 또한, 아래 7f70cbc Commit index는 현재 리모트 저장소의 최종 Commit index인 5717f9...18a 의 parent index로 존재한다.



- "git remote fetch" 명령 수행 후 모든 영역(Working, Staging, Repository)에는 해당 파일에 대한 업데이트 내역이 존재하지 않는것을 확인할 수 있다.


하지만 실제 Git 저장소(.git/objects) 내부에는 아래 결과와 같이 index2.html 파일의 Commit index인 57/17f9...5ee4 Blob 파일존재하는것을 확인할 수 있다.




- 해당 Blob 파일을 확인하면, 아래와 같이 index2.html 파일에 대한 내역이라는것을 다시한번 확인할 수 있다.




- "git merge" 명령을 통해 위에서 "fetch" 된 모든 내역을 해당 로컬 Branch merge 시키면, 이전 내역과 달리 모든 영역(Working, Staging, Repository)에는 현재 리모트 저장소의 업데이트 내역이 전부 반영 되어 있을 것이다.







Git remote pull


- "git remote pull" 명령은 이전 "fetch" 명령과는 달리 모든 영역(Working, Staging, Repository)에 리모트 저장소의 업데이트 내역이 존재하는것을 확인할 수 있다.(즉, "marge" 기능 까지 한번에 수행하게 된다.)







Git push


1. Workiing 영역에 index3.html 파일 생성 후 아래와 같이 모든 단계를 수행한다.


2. 리모트 저장소의 지정된 Branch 로컬 저장소의 업데이트된 모든 내역을 Push 한다.



- 아래는 로컬 저장소로 부터 Push 리모트 저장소 내역이다.





참고:





Git reset 명령 테스트




Git reset --soft 옵션


1. Working 영역에 파일 생성 및 Staging 상태로 변경.


2. 파일을 저장소에 확정(Commit) 지으며, 최종 Commit 히스토리를 확인한 결과 "37c9a0478....5ee5" 가 출력된다.


3. "git reset --soft" 명령을 통해 생성된 저장소 내역을 초기화 시킨다.



- 아래 결과를 통해 "git reset --soft" 옵션에 대한 다음과 같은 특징을 알 수 있다.


1. Working 영역에는 반영되지 않는다.


2. "git ls-files -s" 결과에서와 같이 출력된 Staging 리스트 상에서 File1 파일을 확인할 수 있다.


3. "git log" 명령을 통해 최종 Commit 히스토리를 확인한 결과 위에서 출력한 Staging 리스트와 다르다는것을 알 수 있다.


4. 최종 HEAD 정보를 확인해보아도 같은 결과를 나타내며, 해당 파일을 Commit 대상으로 바라보고 있다.



- 정리하면, --soft 옵션은 Working 영역과 Staging 영역에 반영되지 않으며, Repository 영역에만 반영된다.








Git reset --mixed 옵션


- 아래 결과를 통해 "git reset --mixed" 옵션에 대한 다음과 같은 특징을 알 수 있다.


1. Working 영역에는 반영되지 않는다.


2. "git ls-files -s" 결과에서와 같이 출력된 Staging 리스트 상에서 File1 파일을 확인할 수 없다즉, Staging 영역에 반영되었다는것을 말한다.


3. "git log" 명령을 통해 최종 Commit 히스토리를 확인한 결과 위에서 출력한 Staging 리스트와 동일하다.


4. Staging 영역에 반영되었으므로, 파일은 현재 Untacked 상태를 나타낸다.



- 정리하면, --mixed 옵션은 Working 영역에 반영되지 않으며, Staging  Repository 영역에만 반영된다.








Git reset --hard 옵션


- 아래 결과를 통해 "git reset --hard" 옵션에 대한 다음과 같은 특징을 알 수 있다.


1. Working 영역에 반영된다.(파일이 존재하지 않는다.)


2. "git ls-files -s" 결과에서와 같이 출력된 Staging 리스트 상에서 File1 파일을 확인할 수 없다. 즉, Staging 영역에 반영되었다는것을 말한다.


3. "git log" 명령을 통해 최종 Commit 히스토리를 확인한 결과 위에서 출력한 Staging 리스트와 동일하다.


4. 파일 자체가 Working 영역에 존재하지 않으므로, 당연히 현재 상태 또한 존재하지 않는다.



- 정리하면, --hard 옵션은 모든 영역(Working, Staging, Repository)에 반영된다.





기본적인 Git 명령어



기본적인 Git 명령 정리 문서







Git 저장소 만들기



방법 1. "git init" 명령을 통해 해당 로컬 저장소(~/github)를 Working 영역으로 초기화 시킨다.(초기화된 Working 영역에는 ~/.git 라는 저장소 디렉토리가 생성된다.)


방법 2. "git clone remote https://github.com/mohwa/mohwa.github.io.git(리모트 저장소 URL) 명령을 통해 해당 리모트 저장소의 모든 자원을 로컬 저장소(~/github) 아래에 가져온다.(말그대로 또 다른 dummy를 생성하는 것이다.)




- "git clone" 명령은 아래와 같은 문법으로도 사용 가능하다.


git clone https://github.com/mohwa/mohwa.github.io.git aliasName(별칭)



1. Working 영역에 파일을 생성 후 파일의 현재 상태를 확인한다.(Working 영역안의 모든 자원은  "git add" 명령 수행 이전에는 모두 "Untracked" 상태를 유지하고 있는 것을 볼 수 있다.)


- 하지만 아래와 같이 "git hash-object" 명령을 수행하면, Untacked 상태임에도 불구하고, 해당 자원과 매칭된 Hash 문자열(03f128...3e9)이 미리 생성되어 있는것을 확인할 수 있다.


하지만, Hash 문자열이 미리 생성되어 있을 뿐, 실제 Tacking 되고 있는 파일과 같이 Git 저장소 내부(~/git/object) 에는 존재하지 않는다.



1. "git add" 명령을 통해 파일을 Staging 상태로 변경한다.


2. Staging 여부를 확인하기 위해 "git hash-object" 명령을 통해 해당 파일의 Hash 문자열(03f128...3e9)을 알아낸다.


3. 위에서 알아낸 파일의 Hash 문자열을 근거로 Git 저장소 내부를 확인해 본 결과 해당 위치(~/github/.git/objects/03/f128...1773e9)에 Blob 형식의 파일이 저장되어 있는 것을 확인할 수 있다.


- 또한, "git ls-files -s" 명령을 통해 현재 Staging 되고 있는 자원들의 목록을 확인할 수도 있다.









파일 변경내역 확인하기 1


1. Working 영역에 파일을 생성 후 Staging 상태로 만든다.


2. 파일 내용을 "modify File"로 변경 후 현재 Staging 여부를 확인하면, Unstaging 상태로 변경된 것을 확인할 수 있다.



- "git diff" 명령을 통해 위에서 작업한 파일들의 상태를 비교할 수 있다.(Unstaged 와 Staged 간 비교)



- 정리하면, 현재 Staging 된 파일의 Hash명은 "4de7ff....949" 이며, 파일 내용 변경 후Hash명은 "21cb98....e19" 라는 것을 알 수 있다.(간단히 말해, 현재 Staging 된 자원들의 목록에서 "21cb98...e19" Hash명은 찾아 볼 수 없다.)


즉, 내용이 변경된 파일은 아직 "Staging" 상태가 아닌 "Unstaged" 상태 라는 것을 확인할 수 있다.









파일 변경내역 확인하기 2



1. 현재 Staging 상태의 자원들을 출력한다.


2. Working 영역에 파일을 생성하며, 해당 파일을 Staging 상태로 변경한다.


3. "git diff --staged" 명령을 통해 현재 Staged 된 자원들과 Commit 된 자원들을 비교할 수 있다.


4. 확인 결과 최종 Commit 된 자원은 아래 index 00000..4de7ff4 와 같이 출력하고 있으며, 현재 Staging 된 자원인 File2 와 비교되는 것을 알 수 있다.



1. 파일을 Commit 단계 까지 진행시킨다.


2. 위와 마찬가지로 "git diff --staged" 명령을 통해 현재 Staged 된 파일과 Commit 된 파일을 비교하면 아무것도 출력되지 않는 것을 볼 수 있다.(이유는 현재 생성된 모든 파일이 commit 상태로 변경되었기 때문이다.)









수정하고 저장소에 저장


1. 그 동안 지속적으로 확인한 바와같이 "git commit" 명령은 현재 Staging 된 자원을 저장소에 확정시키는 역활을 수행한다.



- 위 명령과 다르게 "git commit -a -m" 명령은 변경된 파일에 대해 "git add" 명령을 생략 가능하게 해준다.









파일 삭제하기


1. "git rm" 명령을 통해 현재 Staging 되고 있는 파일을 Unstaging 상태로 변경한다.(해당 Tracking 상태는 유지하고고 있는 것을 볼 수 있다.)









파일 이름 변경


1. "git mv" 명령을 통해 파일명을 변경 시킨다.


2. 하지만 Git는 아래 결과와 같이 파일명 변경되어도, 내용이 변경되기 까지는 같은 Hash Point(94634...ceb50)를 가리키게 된다.









Commit 히스토리 조회


1. 모든 Commit 히스토리를 출력한다.


2. 모든 Commit 히스토리를 한줄로 출력한다.


3 모든 Commit 히스토리 상위 하나만 출력한다.(-num(상위 n개))




- 아래는 Commit 명령에 대한 상세 내역이다.








히스토리 수정



- 아래는 "git commit --amend" 명령 후 실행되는 편집기 화면이며, 이것을 통해 수정된다.


P.S: "git commit --amend -m "commit comment" 명령을 통해서도 수정 가능하다.









수정된 파일 되돌리기


1. 파일의 내용을 "modify File1" 로 수정한다.


2. "git checkout" 명령을 통해 수정된 파일의 내용을 되돌린다.(단, 한번 되돌리면 다신 복구가 불가능하다는 단점이 존재한다.)


3. 내용 확인 후 이전 상태로 되돌아간것을 확인할 수 있다.









리모트 저장소 확인


1. 리모트 저장소를 로컬로 가져오면,  origin이라는 리모트 저장소가 자동으로 등록된다.


2. "git remote show" 명령을 통해 리모트 저장소에 대한 상세 내역을 확인할 수 있다.









리모트 저장소 추가 / 이름 변경 / 제거


- 추가



- 변경



- 삭제









태그


1. 태그 생성


- 특정 Commit 히스토리에 임의의 Tag를 지정(생성)한다.



2. 태그 내역 확인 및 삭제







- Git 기본계념과 사용법 그리고 어플리케이션:


prev 1 2 3 4 5 6 ··· 56 next