🔎 버전관리
시작 명령
git init ..git 이라는 디렉토리가 생기며 이 폴더에서 버전들이 기록된다.
버전생성
git add : 파일을 새로 생성하면 깃에게 관리할 파일이 생겼음을 알려줘야 하는데 add를 통해 staging area로 올리면 자동으로 관리상태(track)이 된다.
git commit : staging area에 있는 파일로 저장소에 새로운 버전을 생성한다.
git add .를 사용하고 싶다면 추적하지 않을 파일까지 모두 track상태로 전환이 된다.
이럴 때는git commit -am을 사용해서 track 상태의 파일만 커밋해 줄 수 있다.
버전 이름 수정
git commit --amend
무엇이 바뀌었는지 확인하기
git diff : 수정된 내용에 대해 확인할 수 있다.
git log -p : 버전 내역과 수정 사항들을 함께 보여준다.
시간여행
git checkout <commitID> : 이 커밋 아이디가 생성했던 버전으로 돌아간다.
checkout으로 버전 이동을 하고 git log를 통해 커밋 내역을 확인해보면, 현재 버전을 가르키고 있는 HEAD의 위치가 변경되고, 그 변경된 커밋이 가장 최근 커밋으로 바뀌어 있을 것이다.
git checkout master : 다시 최신상태로 돌아간다.
삭제
reset은 경계에 대해 잘 이해해야 한다.
어떤 커밋아이디로 리셋한다는 것은 그 버전을 삭제하겠다는 것이 아니라 그 버전이 되겠다 이다.
git reset [mode]
- hard : 수정하던 것 까지 없앰
- soft : 수정하던 것은 살림
삭제없이 되돌리기
git revert
기존의 커밋 내역을 그대로 유지하면서 전달한 커밋 아이디의 버전까지 변경된 사항들을 없앤 버전을 새로 생성하는 것.
- 삭제의 경우 커밋아이디를 전달하면 그 커밋아이디의 버전이 된다. 따라서 한번에 여러 커밋을 건너뛰어 과거로 돌아갈 수 있다.
- 되돌리기의 경우 커밋아이디를 전달하면 그 커밋의 수정된 사항들을 없애서 새로운 버전을 생성해낸다.
- 새로운 버전을 생성한것이므로 커밋내역은 유지가 된다.
- 버전을 삭제하지 않는다는 장점이 있지만, 한번에 여러 과거를 건너뛰면 수정 사항이 무엇인지 순차적으로 파악이 되지 않으므로 꼭 역순으로 차례차례 revert를 해줄 수 밖에 없다.
🔎 병합
브랜치와 로그
git branch명령으로 새 브랜치를 생성할 수 있으며 git log 로 커밋내역을 볼 수 있다.
이 때 브랜치와 병합과정들을 한눈에 보기 위해선
git log --all --graph --oneline을 입력한다.
매번 로그를 보기 위해서 저 긴 문장을 입력하기 귀찮으므로 단축키를 생성해줄 수 있다.
git config —global alias.l log --all --graph --oneline위 코드를 입력하면 git l 만으로 그래프까지 생성되는 로그를 확인할 수 있다.
HEAD
head가 가르키는 것이 브랜치면 최종적으로는 그 브랜치가 가르키는 버전을 가르키는 것이다.
반면 헤드가 브랜치가 아닌 커밋을 직접 카르킬 수도 있다. 이처럼 HEAD가 브랜치로 부터 떨어져있는 상태를 detached 상태라고 한다.
충돌 발생
충돌이 발생하고 파일을 열어보면 === 구분자가 생성되어 있을 것이다.
구분자부터 <<<< HEAD 까지는 HEAD가 가르키고 있는 브랜치의 수정사항.
구분자부터 <<<< new_branch 까지는 new_brance의 수정사항.
이 두가지 수정사항에 충돌이 발생했다는 것이다.
그럼 이제 충돌사항을 해결한 코드를 작성해주고 저장한 다음 다시 git add 를 해줌으로써 충돌 사항이 해결되었음을 git에게 알려준다.
그 후 커밋은 메시지 작성없이 git commit 만 입력하면 된다.
🔎 백업
회사에서 작업하던 것을 원격 저장소에 백업하고 집에가서 나머지 작업을 위해 데스크탑에 복원을 한다. 이를 위해 git과 github을 사용할 수 있다.
원격저장소는 Github말고도 bitbucket, Gitlab 등이 있다.
원격저장소와 연결
연결방법은 http와 ssh가 있다. ssh가 보안적으로 더 우세하지만 배울 것이 많으므로 비교적 배울것이 적은 http로 진행한다.
깃헙에 생성한 빈 저장소의 주소를 복사한 뒤
git remote add origin [주소] 를 cmd에 입력한다.
이때 origin은 주소를 모두 입력하기 힘들기에 별칭으로 설정해준 것이라서 다르게 작성할 수 있지만, 관습적으로 원격저장소는 origin을 쓰기로 한다.
그리고 작업해놨던 파일과 내용들을 push하면 첫 업로드가 완료되는 것이다.
push
remote후 git push 를 입력하면 git push —set-updtream origin master를 입력하라고 뜬다. 입력해준다. 이는 기본적으로 연결할 원격저장소를 셋팅하는 것으로 반복적으로 push를 할 때 마다 git push origin master를 git push만으로 가능케한다.
원격저장소에 push가 가능하도록 아이디와 비밀번호를 입력해준다.
clone
git clone [주소] : 주소의 마지막 즉, 저장소이름을 이름으로 가진 폴더가 생성되고 그 안에 저장소의 파일들이 복원된다.
pull
git pull : 원격저장소의 master브랜치에 최종 push된 내용을 끌어온다.
🔎 협업
원격저장소도 로컬저장소와 마찬가지로 HEAD와 master을 필수로 가진다.
로그그래프로 확인해보면 origin/HEAD, origin/master 로 표시된다.
로컬의 브랜치가 깃헙의 마스터의 브랜치보다 앞서있다면 git push 가 필요하다.
로컬의 브랜치가 깃헙의 마스터 브랜치보다 뒤쳐져 있다면 git pull 이 필요하다.
fetch
pull과 비슷하지만 다르다.
pull은 앞에서 말했듯 로컬의 브랜치가 깃헙의 마스터 브랜치보다 뒤쳐져있다면 로컬의 브랜치를 앞선 브랜치에 병합한다.
fetch는 단순히 원격저장소에서 마스터브랜치의 버전을 가져오지만 로컬의 브랜치는 여전히 뒤쳐져 있도록 두는 것이다.
fetch는 병합 전 확인하는 용도로 사용된다.
🔎 체리픽과 리베이스
체리픽
다른 브랜치의 버전 중 하나를 마스터에 이어 붙이고 싶을 때 사용한다.
git cherry-pick [버전번호]
리베이스
base 란 두 브랜치가 공통으로 가진 버전을 말한다.
rebase 는 말 그대로 한 브랜치의 베이스를 재 설정해주는 것이다.
단, 리베이스는 새로운 버전을 생성하는 것이 아니라 버전을 잘라서 붙이는 역할이기에 원격저장소에 push 되기 전에 수행해야 한다. 그렇지 않으면
