깃허브 ... 어려운 깃 허브 ...
GIT BASH를 다운받는다...
GIT 명령어
commit
-Git 저장소에 디렉토리에 있는 모든 파일에 대한 스냅샷을 기록하는 것
-매우 가볍고 커밋 사이의 전환도 매우 빠르다는 것
branch
하나의 커밋과 그 부모 커밋들을 포함하는 작업 내역
git branch [브랜치 이름]
checkout
생성한 브랜치로 가려면
git checkout [브랜치 이름]
merge
Git의 합치기(merge)는 두 개의 부모(parent)를 가리키는 특별한 커밋을 만들어 낸다. 두개의 부모가 있는 커밋이라는 것은 "한 부모의 모든 작업내역과 나머지 부모의 모든 작업, 그리고 그 두 부모의 모든 부모들의 작업내역을 포함한다"라는 의미가 있다.
브랜치가 두 개 있고 각 브랜치에 독립된 커밋이 있다. (이 저장소에 지금까지 작업한 내역이 나뉘어 담겨 있다는 얘기)
두 브랜치를 merge해보기
bugFix 브랜치를 main 브랜치에 merge
git checkout bugFixl git merge main 을 하면
모든 커밋의 색이 같아졌고, 이는 두 브랜치가 모두 저장소의 모든 작업 내역을 포함하고 있다는 뜻이 된다.
git 리베이스(Rebase)
-브랜치끼리의 작업을 접목하는 두번째 방법
-기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳에 떨궈 놓는 것이다.
-리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있다.
-리베이스를 쓰면 저장소의 커밋 로그와 이력이 한결 깨끗해진다.
bugFix 브랜치의 작업 내용이 master의 바로 위에 깔끔한 한 줄의 커밋으로 보이
C3 커밋은 어딘가에 아직 남아있고(그림에서 흐려짐), C3'는 main 위에 올려 놓은 복사본이다.
여기서 문제!
master가 아직 그대로라는 점!
그래서git rebase bugFix를 하면
main이 bugFix의 부모쪽에 있었기 때문에, 단순히 그 브랜치를 더 앞쪽의 커밋을 가리키게 이동하는 것이 전부!!
HEAD
현재 체크아웃된 커밋을 가리킨다 = 현재 작업중인 커밋
HEAD는 항상 작업트리의 가장 최근 커밋을 가리킨다. 작업트리에 변화를 주는 git 명령어들은 대부분 HEAD를 변경하는것으로 시작한다.
일반적으로 HEAD는 브랜치의 이름을 가리킨다. 커밋을 하게 되면, bugFix의 상태가 바뀌고 이 변경은 HEAD를 통해서 확인이 가능하다.
보이지 않던 HEAD를 커밋전, 후에 드러낼 것
git checkout c1; git checkout main ; git commit; git checkout c2
HEAD 분리하기
HEAD를 분리한다는 것은 HEAD를 브랜치 대신 커밋에 붙이는 것을 의미한다.
HEAD -> main -> C1
git checkout c1을 하면
HEAD -> C1
상대 참조(Relative Ref)
Git에서 여기저기 이동할 때 커밋의 해시를 사용하는 방법은 조금 귀찮다. 실제로 Git을 사용할 때는 터미널화면 옆에 예쁘장하게 커밋트리가 보이지 않기 때문이다. 매번 해시를 확인하려고 git log 명령어를 쳐야한다.
나아가서, 실제 Git에서는 해시들이 훨씬 더 길다. 예를 들어 fed2da64c0efc5293610bdd892f82a58e8cbc5d8라는 커밋 해시가 있다. 전부 다 쓰기 번거로우니 해시가 커밋의 고유한 값임을 보여줄 수 있을 만큼만 명시해주면 된다. 위의 긴 문자열 대신앞의 4글자인 fed2만 입력해도 된다는 뜻이다.
상대 참조로 우리가 기억할 만한 지점(브랜치 라던가 HEAD라던가)에서 출발해서 이동하여 다른 지점에 도달해 작업을 할 수 있다.
방법
1. 한번에 한 커밋 위로 움직이는 ^
ex)
main^는 "main의 부모"와 같은 의미 입니다.
main^^ 는 "main의 조부모(부모의 부모)"를 의미합니다
2. 한번에 여러 커밋 위로 올라가는 ~
돌아가고 싶은 커밋의 갯수를 ~뒤의 숫자로 명시해 줍시다.
브랜치 강제로 옮기기
상대 참조를 사용하는 가장 일반적인 방법은 브랜치를 옮길 때이다. -f 옵션을 이용해서 브랜치를 특정 커밋에 직접적으로 재지정 할 수 있습니다
ex)
git branch -f main HEAD~3
git branch -f main Head~3
상대 참조를 통해 C1을 간결한 방법으로 참조할 수 있었고 브랜치 강제(-f)를 통해 브랜치를 저 위치로 빠르게 옮길 수 있었다.
Git에서 작업 되돌리기
Git에는 작업한 것을 되돌리는 여러가지 방법이 있다. 변경내역을 되돌리는 것도 커밋과 마찬가지로 낮은 수준의 일(개별 파일이나 묶음을 스테이징 하는 것)과 높은 수준의 일(실제 변경이 복구되는 방법)이 있는데, 여기서는 후자에 집중한다.
Git에서 변경한 내용을 되돌리는 방법은 크게 두가지가 있다. 하나는 git reset을 쓰는거고, 다른 하나는 git revert를 사용하는 것이다.
1. Git 리셋(reset) 방법
git reset은 브랜치로 하여금 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다."히스토리를 고쳐쓴다" 즉, git reset은 마치 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것이다.
사용법: git reset [어디까지]
2.Git 리버트(revert)
각자의 컴퓨터에서 작업하는 로컬 브랜치의 경우 리셋(reset)을 잘 쓸 수 있지만, "히스토리를 고쳐쓴다"는 점 때문에 다른 사람이 작업하는 리모트 브랜치에는 쓸 수 없다.
변경분을 되돌리고, 이 되돌린 내용을 다른 사람들과 공유하기 위해서는, git revert를 써야한다.
사용법: git revert HEAD
