Git 이점에 대해 Araboza

 Git에 대해 알면 편하고 모르면 답답하기에.. C언어에서 포인터를 알면 포인터의 강력한 마법같은 힘을 얻는 것과 같이

git또한 알면 협업을 보다 편하게 할 수 있다. git을 통해 얻을 수 있는 이점을 상황별로 정리하면 다음과 같다.

아무래도 이해는 GUI환경이기 때문에 소스트리 기준으로 설명합니다.

---

1. 카톡으로 협업 내역을 주거니 받거니 하는 경우

-> 보통 한 사람이 총대매고 서로의 작업 내역을 병합함. 근데 간혹 병합중에 내용을 빼먹을 위험이 있다. 또한 프로젝트 설정같이 눈에 잘 안보이는 것은 작업한 사람이 말하지 않는 이상 빼먹고 나중에 프로젝트 실행에 오류가 나는 원인이 된다.

-> git은 병합 내역이 어디서 이루어졌는지 확인 가능하다. 충돌이 나면 어디서 충돌이 났는지 알 수 있음.

---

(충돌 예시)

 HAED는 내꺼(<<<<<<부터 =====까지), HEAD가 아닌건 남의 내용(=====부터 >>>>>>까지).

충돌난 곳을 찾아다니며 수정하므로 빼먹을 수가 없음. (빼먹으면 신택스 문제로 컴파일이 안되므로)

아니면 충돌 발생시에 내 버전으로만 충돌해결이나(Mine), 다른 사람의 버전으로만 충돌해결(Theirs) 할 수 있다.

Mark Resolved는 해결했다고 표시하는 기능인데, 이 기능은 충돌을 해결하지 않아도 해결했다고 마크를 찍어버리는 기능이 될 수도 있기에

이 기능을 선택한다면 반드시 코드상에서 직접 충돌을 해결 후 완료되었을 때 적용해야합니다.

---

2. 프로젝트를 실험적으로 바꾸고 있는 상황. 갑자기 어느 부분에서 탁 막혀서 이전 작업 내역으로 돌아가고 싶을 때, Ctrl+Z를 연타해서 되돌아 가는 경우

-> 실행취소 기능을 사람이 기억하고 있어야함. 하루 안에 바꾸면 다행인데, 어제 작업한 특정 시점에 돌아가고 싶을 때는 실행취소로 못 돌아감. 또한 여러 소스를 수정한 경우 Ctrl+Z를 각 파일마다 적용해야하므로 실행취소를 통한 방법은 상당한 위험성을 갖고 있음

-> git에서 commit을 통해 스냅샷을 찍어놓으면 특정 시점으로 돌아가는 것이 가능함. 또는 실험적인 내용을 master에 적용하지 않고 싶다면 브랜치를 새로 만들어서 브랜치를 checkout해 이용가능. checkout을 하면 로컬 내 소스가 브랜치의 스냅샷에 따라 바뀌는 신기한 경험을 할 수 있음.

---

(commit 시점으로 돌아가는 예시)

왼쪽) 돌아가고 싶은 시점의 commit 선택. Reset Current branch to this commit 선택

오른쪽) 왼쪽에서 넘어온 화면. 세 가지 모드를 통해 변경 가능.

(Hard는 작업 내역 다 버리고 돌아가는 시점으로 초기화 하는거임.. 사용에 주의하도록 합니다. 보통은 Mixed로 사용함)

---

(checkout을 통해 브랜치간 이동 예시)

master브랜치에서 -> jaekeun 브랜치로 이동함. (마우스 더블클릭)

브랜치 이동이 안될 때가 있는데 이유는 작업 변경사항을 commit한 후에 브랜치간 이동(checkout)이 가능하도록 되있기 때문

만약 해당 프로젝트를 켜놓고 있었다면, (여기서는 Visual Studio)

다음과 같은 창이 뜬다. 당황하지 않고 모두 예를 눌러 jaekeun 브랜치의 내역을 로드한다.

(프로젝트 내용이 변경되는 신기한 경험을 하면서 이 때부터 버전관리가 편해지기 시작한다.)

---

3. A가 작업내역을 공유했지만 추가된 작업이 무슨 역할인지 A를 제외하고 다 모름, A에게 매번 물어보는 귀찮은 상황. A도 근데 이틀만 지나도 뭐했는지 모를때가 많음.

-> 협업이 어렵다고 생각되는 가장 어려운 예. 협업을 하다보면 다른 사람이 어디서 어떤 작업했는지 모름. 이건 왜 넣었고 무슨 역할인지 말해주기전까지 절대 모르기 때문에 물어보는 것도 귀찮고 자기 능력껏 해석함. -> 곧 버그가 발생하거나 다른 사람이 작업한 내용에 대해 관심갖지 않음. 왜? 뭔지 잘 모르니까 그 사람이 작업한 거는 내 일이 아니라고 생각함.

-> git은 변경된 곳이 어딘지 log가 남고 commit에 코멘트를 남길 수 있기 때문에 협업시 팀을 생각해 commit할 때 상세히 적어놓았다면, (예를들어 작업 내역은 이전과 비교해 어떤게 추가됬고 왜 이 기능을 추가했는지 등) 다른 사람에게 일일이 말하지 않아도 되기 때문에 어느정도 의사소통 문제가 해소됨. 또한 log를 통해 실제 어떤 부분이 수정됬는지 알 수  있다.

---

(log 예시)

commit의 코멘트 내역에서 작업 내역은 무엇인지 밝히고 있다.

(일일이 팀원에게 말하지 않아도됨. 카톡으로 수정했어요 하고 일주일뒤 어떤거 수정했는지 메시지 찾기 않해도됨)

파일별 변동사항이 로그로 확인 된다. 초록색이 update된 내용. 옆에보면 + 기호가 붙어서 '아 이게 이번에 추가할려고 한거구나'라고 알수 있음.

반대로 어떤 내용이 사라졌는지 분홍색 블락을 통해 확인 가능. 여기엔 반대로 - 기호가 붙어있다.

---