[CS 스터디] Git

소프트웨어에서의 형상

소프트웨어를 개발하는것은 여러 명과 협업하여 하나의 산출물을 만들고 한 번에 원하는 결과를 만들 수 없다.

=> 중간 중간 생기는 산출물이 많다.

누가, 언제, 어떻게, 왜 산출물을 추가, 수정했는지 추적하는 것이 프로젝트 관리에 있어 중요하다.

 

DVCS (Distributed Version Control System)

• 버전 관리 시스템의 분산 모델
• 프로젝트에 참여하는 모든 개발자가 전체 저장소에 대한 개인적인 로컬 저장소를 갖고 작업하는 방법
• Remote 라는 개념을 통해 다른 사람과 협업 한다.

Git

• 프로젝트를 공유하고 백업하고 관리할 수 있는 버전 관리 시스템
• 개발자가 중앙 서버에 접속하지 않은 상태에서도 개발이 가능하도록 지원
• 각 개발자들이 작업할 때, 모든 작업은 로컬에서 이루어지고 네트워크 사용은 원격 저장소로 저장할 때 한 번만 이루어진다.
• 개발할 때, 처리 속도가 빠르고 웹 상에 저장소를 둘 수 있기 때문에 언제 어디서든 협업이 가능하다.

Github

• Git에 저장된 프로젝트의 변경, 수정 사항들이 저장되는 공간을 제공하는 클라우드 서비스
• 깃이 소스코드에서 몇 행의 어떤 부분이 변경되었는지에 대한 정보와 여러 버전의 파일을 가지고 있으면 깃허브라는 웹 클라우드에 올려 언제 어디서든 편리하게 변경 내용을 올리고 다른 사람이 볼 수 있는 것
• 깃허브를 통해 소스코드의 히스토리 내역을 볼 수 있고, 로컬 프로젝트를 깃허브에 업로드할 수 있다.

왜 깃을 사용해야 하는가?

• 깃을 사용하면 프로젝트의 변경사항, 변경 이력을 알 수 있다.
• 또한 프로젝트의 상태를 이전으로 되돌릴 수 있다. 
• 즉, 여러 버전을 넘나들며 작업을 할 수 있으며, 여러 사람과 협업도 편리하다.

변경사항 더하기  : git add

• git add 명령어로 깃에 반영할 내용을 추가할 수 있다.

git add --all
git add .
git add *

• add 뒤에 붙는 -A 옵션은 모든 변경사항을 반영하겠다는 의미이다.
• 하지만 모두 add 하는 작업을 권장하지 않는다.
• .gitignore 파일로 무시해야 할 파일을 관리할 수 있지만 어떤 내용을 커밋에 포함되는지 완전히 감춰진다.
• 즉, 변경 내용을 알기 위해서 Git을 사용하는 것인데 한꺼번에 add를 해버리면 전체 add된 작업에 대한 설명을 뭉뜽그려 커밋 메시지를 작성하여 변경 내용이 명확하지 않다.

변경사항 반영하기  : git commit

• git commit 명령어로 추가한 내용을 깃에 반영할 수 있다.
• 해당 명령어를 수행하면 현재 소스코드를 깃 저장소에 저장하고 커밋한 내용은 이제 깃이 추적하여 버전 관리를 할 수 있도록 도와준다.

변경사항 확인하기  : git log

• git log 명령어로 변경사항의 기록을 확인할 수 있다.
• 해당 명령어를 이용하여 이전 단계로 되돌리거나 버전을 관리할 수 있다.
• commit 뒤에 나온 번호는 상태의 일련번호(커밋번호)로 이 번호를 통해 분기할 수 있다.

이전 상태로 되돌리기  : git reset

• git log 명령어를 통해 확인한 커밋번호의 앞 6자리를 이용해 이전 상태로 되돌아갈 수 있다.
• 로그를 아예 지워버리기 때문에 이전 상태로 돌아갔다가 다시 미래로 갈 수 없다.

이전 상태로 되돌리기  : git revert

• 로그를 덮어쓰는 것이기 때문에 이전 상태로 돌아갔다가 다시 미래로 갈 수 있다.

reset vs revert

1. test 파일을 생성 후, git add, git commit을 진행한다. -> 커밋 번호 111111
2. test2 파일을 생성 후,  git add, git commit을 진행한다. -> 커밋 번호 222222

git reset 111111 --hard

=> 로그에 111111의 커밋 상태만 남는다. 222222 상태로 갈 수 없다.

git revert 222222

=> 새로운 커밋 상태 333333을 생성한다. 이 333333상태는 111111과 동일한 상태이다.

      즉, 다시 222222 상태로 갈 수 있다.

---

stash

• 파일의 변경 내용을 일시적으로 기록해두는 영역
• 커밋하지 않은 변경 내용이나 새롭게 추가한 파일이 인덱스와 작업 트리에 남아 있는 채로 다른 브랜치로 체크아웃하면 그 변경 내용을 체크아웃한 브랜치에서 커밋할 수 있다.

---

merge

• 여러 개의 브랜치를 하나로 모을 수 있다.
• 브랜치를 나누어 병렬로 진행했던 작업을 마지막에 하나로 합쳐지는 것을 의미한다.
• 같은 파일, 같은 행에 수정을 한 2개의 브랜치를 병합하려면 충돌이 발생한다. 되도록이면 같은 파일을 다른 브랜치가 작업하게 만드는 것을 지양해야 한다.

---

rebase

• 브랜치의 base를 옮긴다.
• base의 위치를 변경해서 다른 브랜치에서 커밋한 내역을 최신으로 보고 그대로 끌어오는 식으로 합치는 것
• 히스토리를 지우기 때문에 깔끔하게 유지가 가능하지만 이로 인해 conflict나 데이터 유실이 발생할 수 있다.

---

.gitignore 파일

• 깃으로 관리하고 깃허브에 올릴 필요가 없거나 올려서는 안 되는 파일이 있다.
• ex) 데이터베이스 계정, 개인키 등이 담긴 파일
• 숨기고 싶은 파일 이름을 지정해주거나 숨기고 싶은 확장자의 모든 파일을 입력해 깃허브에 올라가는 것을 막는다.

---

💬 핫픽스 써봤나요?

💬 프로젝트 진행할 때, 머지 어떤 방식으로 진행했나요?

💬 리베이스 뭔지 아나요?

💬 사용한 깃 플로우 설명 해보세요.

---

Hotfix

• 배포된 버전에 문제가 생겼을 때 해결하기 위한 전략
• 별도로 브랜치를 생성하고 버그를 수정한다.
• 한 가지 작업만을 위해 생성되고 삭제된다.
• 코드의 안정성을 위해 긴급히 버그를 수정해야 하는 경우

https://git.jiny.dev/gitflow/hotfix.html

깃플로우>Hotfix

---

git에 대해 gamification으로 배울 수 있는 웹사이트

https://learngitbranching.js.org/?locale=ko 

Learn Git Branching