개발하고싶은 블로그

Git에는 작업한 것을 되돌리는 방법이 있다. (낮은 수준)Staging Area에 있는 작업을 되돌리기 (아마도..?) (높은 수준)실제 변경이 복구되는 방법 여기서는 실제 변경을 복구하는 방법에 대해서 알아보자. git에서 변경한 내용을 되돌리는 방법은 크게 2가지가 있다. git reset git revert git reset git reset은 브랜치가 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다. 즉, git reset은 마치 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것이다. 사용 방법 git reset 사용 예제 local은 로컬에만 존재하는 브랜치이고 pushed는 리모트 브랜치이다. $git reset HEAD^ 위의 명령어를 사용하면 현재위치(브랜치..

틸드(~) 연산자 만약 캐럿(^) 연산자를 사용해서 main 브랜치의 5단계 위의 부모를 참조하고 싶다면 main^^^^^ 이렇게 해야 한다. 만약 5개라면 괜찮지만 100개라면? 500개라면? 하나씩 ^을 붙여주기엔 너무 힘들다. 이럴 경우에 틸드(~) 연산자를 사용할 수 있는데, 틸드(~) 연산자는 올라가고 싶은 부모의 개수를 뒤에 붙여주면 된다. 또한 git은 branch 명령어에 -f 옵션을 이용해서 HEAD 뿐만이 아니라 브랜치도 특정 커밋으로 옮길 수 있다. 이때 상대 참조를 사용할 수 있으므로 틸드(~) 연산자를 사용해 보자. 브랜치의 위치를 특정 커밋으로 옮기기 $git branch -f main HEAD~3 위의 명령어를 사용하면 main 브랜치의 위치를 HEAD의 3개 부모 전인 커밋 ..

커밋을 체크아웃하려고 하면 커밋의 값을 알아야 하는데 커밋의 값은 너무 길고 외우기 힘들다. 그럴땐 해시가 커밋의 고유한 값임을 보여주는 만큼만 명시해주면 된다. 예를 들어, 해시값이 fed2da64c0efc5293610bdd892f82a58e8cbc5d8이고 fed2~에 해당하는 다른 커밋 해시값이 없다면 fed2만 입력해도 된다. 하지만 이렇다고 해도 어디까지 고유한지 아는것도 힘들기 때문에 커밋의 해시값을 사용하여 커밋하는 것은 힘들다. 그래서 git에는 상대 참조(Relative Ref)를 사용할 수 있다! 상대 참조는 우리가 기억할 수 있는 지점(브랜치라던가 HEAD라던가)에서부터 계산하는 방식이다. 상대 참조를 사용하는 방법은 2가지가 있다. 한번에 한 커밋 위로 움직이는 ^ 한번에 여러 커밋..

Git에서 여기저기로 옮겨다니기 HEAD 현재 체크아웃된 커밋을 가리킨다. 즉, 현재 작업중인 커밋 시점이다. 브랜치를 체크아웃하면 일반적으로 HEAD는 브랜치의 이름을 가리키고 있지만 git 명령어를 통해 이 HEAD를 변경할 수 있다. 특정 커밋을 체크아웃하면 HEAD가 해당 커밋을 가리키고 있다. (해당 커밋을 특정 브랜치가 카리고 있어도 HEAD와 그 브랜치는 서로 다르다) 1. 처음상태 2-1. 브랜치를 체크아웃 브랜치를 체크아웃 한 후 commit을 하면 HEAD는 브랜치와 같이 움직인다. $git checkout bugFix; $git commit; 2-2. 커밋을 체크아웃 특정 커밋을 체크아웃 한 후 commit을하면 특정 커밋에 브랜치가 있더라도 HEAD와 브랜치는 분리된 상태이므로 HE..

Rebase 두 브랜치를 합치는 또 다른 방법 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳에 떨궈 놓는 것이다 리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있어서 저장소의 커밋 로그와 이력이 한결 깨끗해진다. git reabase 현재 위치한 브랜치의 작업내역을 branch-name으로 복사한다 현재 bugFix와 main 브랜치가 있고 bugFix위에 위치해 있다. 이제 rebase를 이용해서 두 브랜치를 합치면 실제로는 두 기능을 따로따로 개발했지만, 마치 순서대로 개발한 것처럼 보인다 $git rebase main bugFix의 작업 내역(c3)이 복사되어(c3') main의 바로 위에 떨궈졌다. 이 상태에서 다시 main으로 이동 후 bugFix를 이동하면 이 전 merge에서..

Merge 두 개의 브랜치를 합친다 즉, 두 개의 부모를 가리키는 특별한 커밋을 만들어 낸다 두 개의 부모 한 부모의 모든 작업내역과 나머지 부모의 모든 작업, 또한 그 두 부모의 모든 부모들의 작업내역을 포함하는 것이다. bugFix와 main이란 브랜치가 있고 현재 main브랜치를 가리키고 있다(main옆에 *이 붙어있다) 이제 bugFix와 main을 합쳐보자 $git merge bugFix 두 개의 부모를 갖는 main 브랜치가 생겼다 이 상태에서 bugFix로 이동 후 main 브랜치를 합치면 어떻게 될까? $git checkout bugFix $git merge main 새로운 브랜치가 생길 것 같지만, bugFix가 main의 부모 쪽에 있었기 때문에 간단히 bugFix를 main이 붙어 있..

브랜치 특정 커밋에 대한 참조일 뿐이다 브랜치를 많이 만들어도 메모리나 디스크 공간에 부담이 되지 않기 때문에, 작업을 큰 브랜치로 만들기보다, 작은 단위로 잘게 나누는 것이 좋다 명령어 git branch 의 브랜치를 새로 생성한다 ex) git branch newImage git checkout 이동할 지점(커밋, 브랜치명)으로 현재 작업 상태를 이동한다 ex) git checkout newImage 목표 bugFix라는 새 브랜치를 만들고, 그 브랜치로 이동해 보자 $git branch bugFix $git checkout bugFix ref https://learngitbranching.js.org/?locale=ko

커밋 Git 저장소에 디렉토리에 있는 모든 파일에 대한 스냅샷을 기록하는 것 git은 가능한 한 커밋을 가볍게 유지하고자 하기때문에, 커밋할 때마다 디렉토리 전체를 복사하진 않는다. 각 커밋은 저장소의 이전 버전과 다음 버전의 변경을 저장한다. 따라서 대부분의 커밋이 그 커밋 위의 부모 커밋을 가리킨다. delta 이전 버전과 다음 버전의 변경 내역 resolving deltas 저장소를 복제(clone)하려면 모든 변경분(delta)를 풀어내야 하는데, 이 때문에 명령행 결과로 나오는 문구이다. 목표 git commit 두 번 해보기 $git commit $git commit ref https://learngitbranching.js.org/?locale=ko