깃허브 심화 가이드

1. git undoing

 

git의 작업단계 3가지

 

1) working directory

 

현재 작업 공간에서 수정한 파일 내용을 이전 commit 상태로 되돌림

 

- git restore

 

 

2) staging area

 

staging area에 반영된 파일은 working directory에 되돌림

 

- git rm --cached

- git restore --staged

 

 

3) repository

 

commit을 완료한 파일을 staging area로 되돌림

 

- git commit --amend

 

 

2. git restore {파일 이름}

 

working directory에서 수정한 파일을 수정 전(직전 commit)으로 되돌리기

 

이미 git에 의해 버전관리가 되고 있는 파일만 가능함(staging area에 올라가 commit이 된적이 있었던 것만)

 

git restore로 되돌리면 해당 내용은 복원 불가능함

 

 

 

 

commit으로 3번 올려서 ver3까지 관리되고 있던 a.txt

 

4번째 수정으로 ver4까지 했는데... add는 하지 않았음(staging area로 올라가지 않았음)

 

이때 git restore a.txt로 ver3으로 되돌린다

 

add로 staging area로 올리기 전의 수정버전을 이전 버전으로 되돌리는 것이 git restore

 

 

2-1) 예시

 

git init으로 최초 저장소 초기화

 

touch test.md로 테스트 파일 생성

 

git add test.md

 

git commit test.md -m "~" 

 

add, commit 수행

 

파일을 수정해보고, git restore test.md를 수행하면.. 진짜로 수정한 내용이 사라짐

 

 

 

3. staging area 작업 단계를 되돌리는 방법

 

staging area에 반영된 파일을 working directory에 되돌림(unstage)

 

root commit이 없는 경우 : git rm --cached {파일이름}

 

위와 같이 commit이 없는 경우에 되돌리는 명령어

 

(예시)

 

git init 초기화하고

 

touch test.md로 파일 생성

 

파일을 수정 후 git add test.md

 

git status로 현재 상태 확인

 

 

 

현재 test.md가 staging area에 있고, git rm --cached (파일명)으로 unstage할 수 있다고 친절하게 나와있음

 

 

 

untracking 된 것을 확이한다

 

 

root commit이 있는 경우 : git restore --staged {파일 이름}

 

git 저장소에 한 개 이상의 commit을 수행한 경우

 

 

(예시)

 

git 저장소 초기화 >>git init

 

test.md 파일 생성 >>touch test.md

 

git add test.md

 

git commit test.md

 

파일 수정 후 git add test.md

 

 

 

아까는 git rm --cached로 되돌리라고 나와있는데, 이번에는 git restore --staged로 되돌릴 수 있다고 나와있음

 

 

git restore --staged test.md로 되돌아 간 것을 확인

 

 

4. git commit --amend

 

커밋 완료한 파일을 staging area로 되돌리기

 

상황 별로 두 가지 기능으로 나뉜다.

 

staging area에 새로 올라온 내용이 없으면, 직전 커밋의 메시지만 수정함

 

 

(예시)

 

git init

 

touch test.md

 

파일 수정, git add

 

git commit

 

git commit --amend 

 

 

 

위에 message가 직전 commit 메시지이고, 이걸 수정하기 위해 i 버튼 누르고

 

지운다음에 변경

 

 

 

esc누르고 편집모드 탈출

 

:wq 치고 엔터

 

git reflog로 상태 확인

 

 

staging area에 새로 올라온 내용이 있다면, 직전 커밋을 덮어쓴다

 

staging area에 새로 올라온 내용이 있다면, 파일의 수정사항이 존재한다

 

그래서 파일 커밋 자체를 덮어 씌운다는 느낌

 

(예시)

 

git init

 

touch test.md

 

파일 수정 후 git add

 

git commit

 

다시 파일 수정 후에 git add로 staging 에 올림

 

 

 

다시 git commit --amend

 

(git commit --amend하기 전에)

 

 

(git commit --amend하고 나서 message를 수정)

 

 

근데 두 경우가 솔직히 큰 차이가 있나..?

 

 

5. git reset

 

시계를 마치 과거로 돌리는 듯한 행위

 

프로젝트를 특정 커밋 버전 상태로 되돌린다

 

특정 커밋으로 되돌아가면, 해당 커밋 이후에 쌓았던 커밋들은 전부 사라진다

 

--soft : 해당 커밋으로 되돌아가고, 되돌아간 커밋 이후 파일은 staging area로 되돌리기

 

--mixed: 기본값, 되돌아간 커밋 이후 파일은 working directory로 되돌리기

 

--hard : 되돌아간 커밋 이후 파일은 working directory에서 모두 삭제함

 

실습파일로 직접 확인해봐야할듯..vscode아니면 보기가 어렵

 

 

 

6. git reflog

 

과거 커밋 내역을 모두 조회

 

reset하기 전 내용도 조회가능함

 

--hard로 삭제했다고 하더라도, git reflog로 조회한, 이전의 내용으로 reset하면 복구 가능하다는데..?

 

여기에 id가 남아있다면, reset이 가능한가봐

 

 

7. git revert (취소하고자 하는 id)

 

과거를 없던 일로 만드는 행위

 

이전 커밋을 취소한다는 새로운 커밋을 생성함

 

reset은 이전 커밋을 삭제하고, 되돌아가지만

 

revert는 이전 커밋들을 모두 남겨준다

 

git revert 5se2bf4라고 하면 5se2bf4라는 commit id 1개를 취소한다고 하는 새로운 커밋을 생성

 

revert는 깃허브를 이용해 협업할때 커밋 내역의 차이로 인한 충돌 방지

 

 

실제로 1.txt를 만든 커밋을 취소한다고 했더니, 1.txt가 없어지고... 취소했다는 커밋이 1개 더 늘어나있음

 

 

8. git branch & git switch

 

독립 공간 branch를 형성

 

원본 master에 대해 안전

 

하나의 작업은 하나의 브랜치로 나누어 진행, 체계적인 개발이 가능

 

git은 브랜치를 만드는 속도가 굉장히 빠르며, 적은 용량을 소모하므로 적극적으로 권장

 

<조회>

 

git brach #로컬 저장소의 브랜치 목록

 

git branch -r #원격 저장소의 브랜치 목록

 

<생성>

 

git branch {브랜치 이름} #새로운 브랜치 생성

 

git branch {브랜치 이름} {커밋 id} #특정 커밋 기준으로 브랜치를 생성함

 

<삭제>

 

git branch -d {브랜치 이름} #merge된 branch만 삭제가능?

 

git branch -D {브랜치 이름} #강제로 삭제함

 

<이동>

 

git switch {브랜치 이름} #다른 브랜치로 이동함

 

git switch -c {브랜치 이름} #브랜치를 새로 생성하고 이동함

 

git switch -c {브랜치 이름} {커밋 id} #특정 커밋 기준으로 브랜치를 생성하고 이동

 

switch하기 전에 해당 브랜치의 변경 사항을 반드시 커밋해야함

 

다른 브랜치에서 파일을 만들고, 커밋 하지 않은 상태에서 switch를 하면, 브랜치를 이동했음에도 불구하고 해당 파일이 그대로 남아있다

 

 

9. HEAD

 

HEAD는 현재 브랜치를 가리키고, 각 브랜치는 자신의 최신 커밋을 가리키므로, 결국 HEAD가 현재 브랜치의 최신 커밋을 가리킴

 

git log 로 현재 HEAD가 어떤 브랜치를 가리키는지 확인 가능함

 

git switch는 현재 브랜치에서 다른 브랜치로 HEAD를 이동시킨다

 

 

 

이 상태에서 commit을 하면...

 

 

switch로 head를 이동시키고..

 

 

여기서 다시 commit하면..

 

만약 한번 더 commit을 한다면...

 

 

시간 내서 실습 써보면 좋겠는데

 

그럴지는 모르겠다

 

10. git merge {합칠 브랜치 이름}

 

병합하기 전에, 브랜치를 합치고자 하는, 메인 브랜치로 switch해야함

 

그러니까 main에서 git merge hotfix 이렇게 실행하면, main에 hotfix를 넣어주는 느낌..

 

근데 뭐가 어떤 merge인지는 딱히 신경 안써도 되는듯?

 

명령어는 모두 (master에서..) $git merge hotfix로 동일하거든

 

10-1) fast-forward

 

앞에 있는 main branch를 뒤로 가지고와서 빨리감기하듯이? 병합시키는

 

 

 

(예시)

 

 

 

 

 

10-2) 3-way merge

 

갈림길이 있을때, 공통 조상을 이용해서 merge하는

 

10-3) merge conflict

 

두 브랜치에서 같은 부분을 수정할때, git이 어느 브랜치의 내용으로 작성해야하는지 판단하지 못해 충돌이 발생할때, 이를 해결하며 병합함

 

보통은 같은 파일의 같은 부분을 수정했을 때 자주 발생

 

충돌이 발생할때는 작성자가 직접 해결해야한다고함..??

 

 

위와 같은 경우는 자연스럽게 a,b가 수정된 상태로 합쳐지는데

 

 

 

이렇게 다른 branch에서 a,a가 수정되었을때, merge하려고 하면, 뭘 기준으로 합쳐야할지 모르겠어서 conflict일어남

 

 

 

11. git workflow

 

branch와 원격 저장소를 이용해 협업

 

원격저장소 소유권이 있으면 shared repository model

 

원격저장소 소유권이 없으면 Fork & Pull model

 

 

12. shared repository model

 

원격 저장소가 자신의 소유이거나 collaborator

 

배포를 위한 branch는 master brach이고 여기서 개발하는 것은 아니다.

 

기능별로 브랜치를 따로 만들어서 개발

 

Pull request를 사용하여 팀원 간 변경 내용에 대한 소통을 진행함

 

13. Fork & Pull model 

 

오픈 소스 프로젝트 같이 자신의 소유가 아닌 원격 저장소인경우

 

원본 원격 저장소를 그대로 내 원격 저장소에 복제하고(Fork)

 

기능 완성 후에 복제한 내 원격 저장소에 push하면

 

이후 pull request를 통해 원본 저장소에 반영

 

14. branch전략

 

git 전략, github 전략, gitlab 전략 등등

 

그러나 팀 고유의 branch 전략이 존재할 수 있음