[Visual Studio Code]에서의 git 1의 내용까지 진행이 됬다면 이번에는 Git Graph를 설치해볼거다.
왼쪽 목록 4번째 칸에서 git graph를 검색하고 install해준다.
그러면 왼쪽 하단에 git graph가 생성되고 누르면 활성화 할 수 있다.(사진상으로는 우측 하단)
클랙해보면 버전의 ID, 수정된 파일, 버전의 commit매시지 작성자 등을 확인할 수 있다.
이어서 우리는 work2.txt, work3.txt 파일을 생성해주고 commit한다.
여기서 우리의 수정사항은 work2와 work3의 텍스트 파일을 생성하고 저장한거다. 우리는 이 모든것을 commit할 수 있지만 버전관리를 위해 work2만 따로 commit하도록 아래 사진과 같이 Stage Changes기능을 통해 work2.txt파일만 commit하고 work3.txt를 v3로 commit해보겠다. 이러한 기록은 git graph를 통해 시각적으로 확인할 수 있다.
git graph를 보면 v2위에있는 파란o와 main에 있는 파란테두리가 있다. 파란 동그라미는 HAED를 가리키고 main위에있는 파란 테두리는 현재 HEAD가 보고있는 repository를 가르킨다. 이에대한 자세한 설명은 "[Git, GitHub]의 역할 원리"에서 확인하고 개념을 익히기 바란다.
여기서 v1으로 나의 working directory를 바꾸고 싶다면 checkout을 통해 HEAD를 바꿔준다.
그러면 우리는 v2, v3를 작업하기 이전의 v1을 commit했던 상태로 돌아가게 된다. 그 결과 work2와 work3에서 했던 작업은 없어지게 된다. 다시 돌아가고 싶다면 main을 더블클릭하거나 우클릭 후 Checkout Branch를 클릭하면 원래 working directory 버전으로 돌아가게 된다.
만약 detached HEAD statef를 활용하고 싶다면 v3검은 공간에서 checkout해주면 된다. 단, 기능을 잘 모를시 사용하는 것은 추천하지 않는다.
v3검은 공간에서 checkout해준다면 새로 commit한 내용들은 main과는 별개로 생성될 것이다.
work4.txt 파일을 만들어 저장하고 test라는 commit message를 남겨 commit했다. HEAD는 test를 바라보고 main은 별개로 존재하는것을 확인할 수 있다.
여기서 checkout branch를 하게 된다면 commit했던 test는 사라지게 된다. 만약 이게 열심히 밤새 작업했던 결과물이라면 나는 너무나도 큰 좌절을 맞이할거다.
그러나 Git은 버전을 버리지 않는다. 우리가 commit id를 알고있다면 언제든지 이를 복구할 수 있다. 터미널 창을 열어 다음과 같이 입력하면 test를 불러올 수 있다.
git checkout f33496d2
내가 commit한 test의 id는 f33496d2임으로 여러분의 commit id는 다르기때문에 맞는 id를 입력해 주어야 된다.
만약 id를 찾지 못했다면 git reflog를 활용하여 사라진 id를 확인할 수 있다.
만약 Test했던 내용들이 마음에 들어 이를 유지하고 싶을 경우에는 어떻게 해야될까?
우리는 새로운 branch를 만들에 주고 HEAD가 새로운 branch를 바라보게 한다면 문제없이 그대로 개발을 이어갈 수 있다.
test 우측 검은화면에서 우클릭을 하고 Create Branch를 선택한다. 나는 test_v1이라는 이름의 branch를 생성하였고
자동으로 check out해주는 toggle을 활성화해 branch를 만들었다. 마지막 결과를 보면 HEAD는 test_v1이라는 branch를 바라보고 있는것을 확인할 수 있다. 그리고 HEAD가 main을 바라보게 check out하더라도 test는 사라지지 않는것을 확인할 수 있다.
main에서 새로운 commit을 시도하게 되면 새로운 가지가 생겨나게 된다. work5.txt 파일을 만들고 v4 메시지로 commit했다. 현재 각 branch의 상태는 다음과 같다.
main = [ work1.txt, work2.txt, work3.txt, work5.txt ]
test_v1에 있던 work4는 성공하여 삭제해서는 안되고 main으로 합쳐야 앞으로의 개발이 가능한 상황에서 우리가 할수 있는것은 merge를 활용하는 것이다. HEAD가 바로보는 것이 기준이기 때문에 HEAD가 main을 바라보고 있는 현 상황에서 test_v1과 merge해보겠다. test_v1에 우클릭하여 merge해주면 work4.txt파일이 main에 추가된 것을 확인할 수 있다.
branch를 merge해서 새로운 버전을 만들었는데 마음에 들지 않았다면 우리는 다시 되돌려야 된다.
이전에 git checkout을 통해 HEAD를 옮겼었다.
이번에는 reset을 통해서 HEAD가 바라보고있는 branch의 버전을 바꿔보자.
check out은 HEAD를 바꾼다.
reset은 HEAD가 가리키는 branch를 바꾼다.
Git에서는 git reset [commit id] 의 형태로 명령어를 작성하면 된다.
해당과정에서 2번째 사진처럼 Mixed를 Hard로 바꿔주기 바란다.
우리가 그동안 다른파일의 다른 내용들을 수정했다면 같은 파일에서 내용을 변경한다음 merge하게되면 어떻게 될까?
확인을 위해 main과 test_v1을 다시 merge하겠다. 이후 main에서 mergeTest.txt를 만들고 다음고 같이 데이터를 저장한다.
commit message는 start라고 하겠다.
start우측 빈공간에 우클릭으로 create branch를 선택하여 새로운 branch를 생성해준다.
이후 다음과 같은 과정을 거친다.
main : mergeTest.txt의 2를 m2로 변경 -> commit message "m2"입력후 commit
Open Folder를 선택하여 원하는 곳에 폴더를 생성 및 선택하고 꼭! 그 폴더안에 들어가 지정해준다. 예를들어 바탕화면에 폴더를 만들었지만 선택하지 않고 바탕화면이 선택되었다면 우리가 Git을 연동했을 때 C:\Users\User\Desktop 경로에 있는 모든 파일들이 Git으로 관리되는 참사를 볼 수 있다.
이후 창에서 마우스 우클릭을 통해 파일을 생성해주자 나는 work1.txt 파일을 생성하였다.
이후 내용을 편하게 적은 후 ctrl+s로 저장을 해주어야 된다. 저장이 잘 되었는지 확인하는 방법은 파일 우측 ○가 없어졌다면 잘 저장된 것이다.
이후 왼쪽 목록에서 3번째 아이콘을 클릭하면 Initialize Repository라는 버튼이 있다 이를 클릭하게 되면 이 파일은 Git에서 버전 관리하게 된다. 이후 Commit을 누르게 되면 내가 작업한 변경사항을 새로운 버전으로 제출하겠다는 의미로 Git에 버전 관리하게 된다.
만약 이러한 애러 매시지가 뜬다면 Cancel을 누르고 터미널을 활용하여 user.name과 user.email을 작성해주면 된다.
상단 창에서 Terminal -> New Terminal 또는 ctrl+j를 눌러주면 터미널 창을 만들 수 있다.
윈도우 초기 사용자라면 오른쪽에 powershell이라 되어있을거다 우리는 이를 Git Bash로 변경해야된다.
나의 경우 Git Bash를 Default값으로 지정해서 터미널을 열게되면 Git Bash가 열린다.
설정 방법은 Select Default Profile을 누르고 Git Bash를 선택한다.
이제 우리는 Git Bash에서 다음과 같이 적어주면 된다.
git config --global user.name "이름"
git config --global user.email "이메일@gmail.com"
이를 통해 유저 이름과 이메일을 등록하였다. 이제 윗 내용을 다시 시도하면 문제없이 진행될 것이다.
버전관리를 하지 않았다면 우리는 버그가 난 곳이 어딘지 모든 코드를 읽으며 찾아내야 한다. 작은 프로젝트라면 충분히 가능하지만 대규모 프로젝트의 경우 너무나도 많은 시간을 투자하게 된다.
2000만줄의 코드를 읽으며 버그를 찾는것과 A3버전 수정된 부분에서 버그를 찾는 것은 너무도 큰 차이가 난다.
이러한 버전관리는 효율적인 개발에 필수 요소라고 할 수 있다.
우리 Git에서 관리하는 project folder에서는 다음과 같은 절차를 통해 버전관리가 이루어진다.
working directory에서 작업한 것을 우리는 add하게 되는데 git add [파일명, 확장자명] / git add . 을 활용하여 stage area로 보내게 된다. stage area는 index, cache라고도 불린다.
여기서 commit하게되면 우리는 했던 작업을 .git 즉 repository로 올리게되며 버전관리를 하게 된다.
이렇게 repository로 올라가면서 고유의 id가 생성되는데 commit message, 파일의 이름, 파일의 내용, 부모의 commit id(존재할 시), 유저 이메일, 유저 이름을 해쉬알고리즘을 통해 유일무이한 id를 만들게 된다. 이를 고유한 식별자 commit id라고 한다. 이 id는 main에 저장된다. main은 마지막 작업자를 기록한다. 원초적으로 다가가면 마지막 버전은 HEAD가 가리키는 곳에 저장된다. 많은 repository중 HEAD가 main을 가르키고 있어 마지막 작업(버전)이 main에 기록되는 것이다.
처음 commit 한건이 A이고 두 번째 커밋한 것이 A2라고 한다면 A는 A2의 parent이다. HEAD는 main을 가리키고 마지막 버전 A2의 commit id는 main에 저장될 것이다. 이후 또 commit해 A3를 만들게 된다면 main에는 A3의 commit id가 나타날 것이다.
여기서 만약 checkout을 통해 HEAD가 가리키는 곳을 바꾸게 된다면 우리는 이전에 했던 작업으로 돌아갈 수 있다.
HEAD는 working driectory가 어느 버전과 같은지를 나타낸다. 아래 처럼 HEAD가 A를 바라보게 하면 그 동안 작업했던 A2와 A3는 사라지게 된다. 다시 working directory의 버전을 돌리고 싶으면 HEAD가 main을 보도록 checkout 또는, checkout branch 해주면 된다.
여기서 만약 우리가 A3로 checkout 하게된다면 HEAD는 A3를 바라보게 될거고 여기서 commit을 하게 된다면 해로운 A4가 생기게 된다. A4는 main과는 상관없이 자기의 길을 가게 된다. 가장 무서운 점은 HEAD가 main을 바라보는 순간 A4는 사라지게 된다.
HEAD가 A3를 바라보고 작업한 뒤 commit하는 순간 A4는 사라질 수 있는 작업이 되는거다.
내가 5시간의 작업을 통해 만든 결과물이 한순간에 사라진다면 얼마나 슬플까?
하지만 Git은 모든것을 기억한 우리가 보기에는 없어졌지만 commit id만 알고있다면 우리는 chackout을 통해 다시 A4를 확인할 수 있다.
이러한 작용을 모르고 쓰면 내가 한 모든 작업을 날리는 사고지만 알고쓴다면 기능이다.
무언가를 테스트해봐야 될 때 이러한 기능을 쓸 수 있다. 이것을 detached HEAD state라고 한다. 실험이 실패했을 때 우리는 git checkout main을 통해 아무런 문제없이 모든 상황을 되돌려 놓을 수 있다. 개발자들은 이렇게 리스크없이 실험을 할 수 있다.
그런데 만약 실험한 기능이 정상적으로 작동되고 계획했던 모든것이 이루어 졌다면, 저A4버전을 포기할 수 없다.
이런경우 새로운 branch(repository)를 생성해주면 A4버전을 유지할 수 있다.
다음과 같은 상황에서 HEAD가 test라는 이름을 가진 branch(repository)를 바라보게 한다면 원래 Git의 흐름대로 개발을 이어나갈 수 있다. 그리고 main으로 checkout해도 A4는 사라지지 않는다.
작업자는 HEAD를 main을 보게 하고 새로운 버전 A5를 만들었다고 하자 그러면 우리는 2가지의 갈래길을 보게된다.
이러한 구조가 이거지면 마치 나뭇가지모양처럼 발전하게 되는데 이러한 기능을 하는 것을 나뭇가지의 영문을 사용해 'branch'라고 부른다.
A3에 main.txt가 있었고 A4는 test.txt를 추가로 만든 버전이라고 하자.
A5는 work.txt를 추가로 만든 버전이라면 우리는 A5에 test.txt라는 파일을 가져와야 버전이 업그레이드 될 것이다.
이러한 작업을 Merge라고 한다. A5작업에 A4를 merge하게 된다면 A5를 기준으로 없던 작업들이 추가될 것이다.
A6의 perant는 A5와 A4가 된다.
만약 다른파일이 아닌 같은 파일인 경우에는 어떻게 될까?
다시 A3의 시점으로 돌아가보자 A3에서 main.txt파일에 1, 2, 3, 4라는 값이 있다면 A3에서 한 번은 3을 C3로 변경하였고
한 번은 2를 B2로 작업했다고 하자. 그 결과 각각 B버전과 C버전이 만들어진 상태다.
여기서 각자 한 번의 작업을 진행해 4를 B4와 C4로 수정하였다고 한다면, 이 두 작업을 merge할 수 있을까?
결론은 가능하다.
만약 앞에가 어떤상황인지 모른다면 어떻게 될까?
1의 내용은 양쪽이 동일해 그대로 1로 들어갈거고 나머지 2, 3, 4는 어느쪽에서 수정이 이루어졌는지 알수없다.
이 경우 수정이 되지 않은 1만 받아들이고 나머지는 합칠 수 없다. 다시 말하면 '충돌'이 일어났다.
이것을 [ Conflict ]라고 한다.
알고쓰면 기술이고 모르면 사고라고 한다. 충돌 즉 conflict가 나는 이유를 알면 Git에게 고마워해야 된다.
반대로 이유를 모른다면 우리는 Git이 원망스러울 수 밖에 없다.
Git을 만든 사람들은 여기서 획기적인 생각을 한다. 바로 origin을 찾아가서 확인을 하고 3자대면을 하게 된다.
즉 B2와 C2가 갖고있는 main.txt의 조상을 찾아가 비교대조하는데 그 조상을 'base'라고 한다.
base를 기준으로 봤을 때 변경사항은 다음고 같다.
1은 수정없이 그대로 있었다.
2는 B2로 수정되었다.
3은 C3로 수정되었다.
4는 B4와 C4로 수정되었다.
한 쪽만 수정된 정보는 수정사항을 그대로 가져오지만 양쪽 모두 수정된 정보는 컴퓨터가 임의로 처리할 수 없어
사람에게 수정을 맡기게 된다. 컴퓨터는 병합하면 안되는 것을 병하지 않음으로 충돌을 방지한다. 이는 최고의 기능이다.
최종적으로 이러한 형태를 갖게되며 ?안에 들어갈 것은 사용자가 정의해 주면 된다.
그러면 문제없이 merge할 수 있다.
내가 B2와 C2를 병합해 버전 D를 만들어 냈는데 뭔가 마음에 들지 않는 부분이 생겨서 다시 돌이켜야 된다면 어떻게 해야될까? 우리는 이전에 HEAD가 바라보는 것을 바꾸기 위해 check out을 사용했다. 내가 보고있는 branch를 바꾸기 위해서는 reset을 사용해야된다.
check out은 HEAD를 바꾼다.
reset은 HEAD가 가리키는 branch를 바꾼다.
reset을 통해 HEAD가 바라보고 있는 main이 B2를 바라보게 만들면 Git에서 D는 보이지 않고 다시 분리된 상태로 돌아가게 된다. 우리가 보는 화면에서 D는 표시되지 않지만 commit id만 알고있다면 git checkout [commit id] 명령어를 통해 복구할 수 있다. 이를 활용해 우리는 작업을 언제든지 되돌릴 수 있고 다양한 실험을 할 수 있다.
추가적으로 test라는 이름을 가진 branch도 A, B, B2, C어디든 이동할 수 있다.
ex) git checkout fd86se9
ex) git reset fd86se9
fd86se9는 commit id의 예시이다.
이제 우리가 만든 프로젝트를 백업하기 위해 우리는 웹호스팅을 활용하는데 이를 GitHub통해 한다.
GitHub의 원격저장소(repository)를 이용해 프로젝트를 업로드하면 로컬저장소에서 관리하던 것을 원격저장소에서
