3일차 복습정리
2024년 2월 6일 화요일
오후 7:26
Git Branch
Git의 branch란 원래 코드와 관계없이 코드를 복사해서 독립적으로 개발 할 수 있게 해주는 역할을 하는 것.
일반적으로
Git 브랜치는 커밋 사이를 가볍게 이동할 수 있는 포인트 같은 것으로
Git은 처음 init로 초기화하면 master브랜치를 생성한다.
이와 같이 자동으로 가장 마지막 커밋을 가리키게 된다.
브랜치 생성 명령어
Git branch <브랜치 명>으로 생성한다.(브랜치의 작업공간을 할당한다)
만약 브랜치를 생성하게 되면 기본적으로
이런 구조를 하고 있으며
Git log를 통해 확인 할 수 있다.
Head라는 것은 지금 작업하는 로컬 브랜치를 의미한다 지금은 아직 master에서 작업중이라
Master를 가르키고 있는 것을 알 수 있다.
또한 git log --decorate옵션을 사용하여 브랜치가 어떤 커밋을 가리키는 지도 확인 할 수 있다.
작업하는 브랜치 이동 명령어
Git checkout <브랜치명>
Git switch <브랜치명>
(git switch -c <브랜치명> :-c옵션을 사용하여 없는 브랜치를 생성하고 변경도 가능하다)
Switch는 checkout에서 분리된 기능으로
Checkout의 변경 기능을 switch로 만들었고 checkout의 복원 기능을 restore기능으로 만들었다.
- git restore 명령어를 통해 작업중인 파일 중 기본 마지막 커밋상태로 되돌릴 수 있다.
또한 branch이동 후 작업을 하게 되면
이렇게 작업 후 commit을 하면 testing의 시점은 더 뒤로 가고 head는 현재 작업중인 test를 따라 이동하게 된다.
Git switch master를 하게 되면
이렇게 head는 작업하는 곳으로 이동하게 되서 서로 별도의 시점을 가지게 된다.
브랜치를 이동하면 워킹 디렉토리의 파일이 변경된다.
이전에 작업했떤 브랜치로 이동하면 워킹 디렉토리 파일은 그 브랜치에서 가장 마지막으로 했떤 작업 내용으로 변경된다. (파일변경에 문제가 생기면 이동명령을 수행하지 않는다. 또한 master로 이동해서 commit을 하게되면
이와 같이 두개의 시점이 갈라지게 되며
git log --oneline --decorate --graph --all
위 명령으로 히스토리를 출력하면
어디서 갈라졌는 지 확인도 가능하다.
비해 Git은 순식간이다. 게다가 커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터(Merge Base) 합쳐야 하는지 안다.
이런 특징은 개발자들이 수시로 브랜치를 만들어 사용하게 한다.
브랜치 삭제
Git branch -d <브랜치명>을 통해 브랜치를 삭제할 수 있다.
Git branch --delete <브랜치명>
이와 같이 브랜치를 삭제할 수 있다.
브랜치에서는 본인의 로그내용만 확인이 가능하지만
Git log 명령어 옵션중 --all을 하게되면
이렇게 master내용 밖에 없던 로그가
이와 같이 다른 브랜치의 로그까지 확인 가능하다.
또한 깃허브와 연결 시
깃허브에 설정된 브랜치 값도 확인을 할 수 있는데
리모트 저장소인 깃허브의 브랜치를 확인하는 명령어는
Git branch -r를 사용하면 아래와 같이
이렇게 원격지의 브랜치 이름을 빨강색으로 표시해주며
Git branch -a를 이용해여 현재 깃으로 관리되는 파일의 리모트 저장소와 로컬저장소의 모든 브랜치를 아래와 같이
보여준다.
또한 원격지에서 생성된 브랜치는 git push -d 옵션으로 원격지의 브랜치만 삭제도 가능하며 git
브랜치에서 서로 다른 브랜치의 내용을 합치는 명령어
Git merge <브랜치 명>
현재 있는 브랜치에 명령어에 작성한 브랜치의 내용을 가져오는 것.
위와 같이 master에서 새로 생긴 hotfix라는 브랜치가 존재하는 데
$ git checkout master
$ git merge hotfix
위 명령어로 master로 이동 후 hotfix의 내용을 가져오게 되면
fast-forward라고 뜨면서 master의 시점을 hotfix의 커밋 시점까지 이동시킨다.
그저 동일한 커밋을 가리키도록 이동시키고 이때 내용을 가져오는 것처럼 보인다.
위와 같이 이렇게 시점 자체가 이동되는 것
하지만 위와 같이
서로 별개로 진행되는 브랜치가 존재하면 나중에 iss53브랜치가 master에 마지하게 되면 hotfix와 iss53을 합치게 되는 것이다.
이렇게 시점만 다른 것이 아닌 서로 별개로 진행되었던 파일을 마지하면
위의 c2라는 시점에 c4의 마스터와 c5의 iss533이 c2라는 시점에 합쳐지는 것이다.
결국 원래 마스터의 위치로 가서 hotfix와 iss53이 합쳐지는 것처럼 보이게 되는 동작이다.
만약 hotfix와 iss53이 같은 부분을 수정하게 되면
이와 같이 auto-merging이란 코드가 나오면서
자동으로 merge를 하지 못하고 새커밋이 생기지 않으며 충돌한 곳을 개발자가 해결하지 않는한 마지를 진행할 수 없다.
이와 같이 unmerged로 파일의 위치를 알려주며
이 파일을 개발자가 해당 부분을 수동으로 해결해줘야된다.
만약 저 파일로 들어가면 파일이 이와 같이 있게 되는 데 이때
필요한 내용을 변경 후에 새로 저장해주면 충돌이 해결된다.
Merge는 모든 내용이 합쳐지는 방식이기 때문에 필요한 파일만 따로
합치거나 가져오고 싶은 경우에는
Git checkout -p <브랜치명> <파일이름>
이런 구조로 명령어를 사용할 수 있다.


Path방식은 위와 같이 staged에만 올라가 있으며 commit을 따로 해줘야된다.
Git의 장점 중 하나는 commit으로 시점을 잡아놓으면 그 시점으로 이동이 가능하다는 점이다.
Commit한 시점으로 이동하는 명령어
Git reset --hard <시점명>
여기서 시점 명은
Git log --oneline으로 확인하면 각 커밋의 시점을
이와 같이 각 메시지 왼쪽에 존재하고 있다. 저 16진수를 시점에 넣어주면 그 시점으로 파일 내용이 리셋된다.
Hard를 이용하게 되면
위와 같이 원래 있던 내용이 전부 날라간다.
그렇기 때문에 되롤리면 로그 자체도 날라가서 다시 원래 이동하기 전 시점으론 이동이 불가능하다.
- -hard옵션을 사용하면 완전히 내용이랑 로그 둘다 삭제가 된다.
- -soft : 변경사항은 그대로이며 로그만 삭제한다.
Soft는 일반적으로 로그를 잘못 기입해서 로그를 재작성 할 때 사용한다.
Git reset --mix :>>index를 현재 head가 가리키는 스냅샷으로 대기할 수 있다.
현재 파일들을 가장 최근 커밋으로 되돌리는 역할을 하고 add를 해놓은 파일들도 전부 staged에서 내린다.
Reset관련
https://git-scm.com/book/ko/v2/Git-도구-Reset-명확히-알고-가기
위 사이트를 참조
Git revert
작업했던 내용들을 이전 시점대로 되돌려주지만 로그는 그대로 남기고 돌아간다.
Revert는 기록 자체는 유지되는 너무 먼 시점으로 가면 오류가 날 수도 있다.