Git

Git은 소스 코드 버전 관리 시스템 나중에 현업 개발자로 실무에 투입되어 깃랩(GitLab) 또는 깃허브(GitHub)를 사용하게 되는 경우 커밋 메시지를 자세하게 (누가봐도 어떤 파일에 대한 커밋인지 알 수 있도록) 적는 것이 중요하다.

Git이란 우리가 작업하는 파일의 모든 변화를 기록하는 시스템이다. 여기서 모든 것이란 누가 언제 어떤 파일 어떤 부분을 어떻게 했는가이다.

버전 관리 시스템 종류

1. 클라이언트 - 서버 모델

하나의 중앙 서버에서 여러 클라이언트들이 각자 필요한 데이터만 가져와 작업하고 다시 중앙으로 통합

2. 분산 모델

하나의 중앙 서버 존재, 그러나 여러 클라이언트(개발자)들이 각자의 컴퓨터에 복사본을 가지고 와서 작업 후 저장

→ 차이점은 클라이언트-서버모델 중앙 서버가 사라지면 모두 사라짐 그러나 분산모델은 각 개발자들이 코드를 가지고 있기 때문에 중앙서버가 사라져도 코드 손실의 위험이 적다.

💡Git을 사용하는 이유

1. 파일의 버전관리
소프트웨어에는 버전관리가 필요하다. 꼭 클라이언트 요청이 없더라도, 버전별로 이전 버전의 기능을 다시 가져올 수도 있고 누군가 잘못된 코드를 섞으면 복원해야될 때가 있다. 이럴때 필요한 것이 버전관리를 위한 툴, Git이다.

2. 다른 개발자와 협업
보통 여러명의 개발자와 협업을 하는데 개발자들이 각각 맡은 파트를 가져가서 작업하고 합치기 때문에 실시간으로 작업내역을 공유할 수 있는 원격 저장소가 필요하다. 이때 필요한 것이 협업을 위한 저장소 Github이다.

git의 장점

1. 협업하는 개발자들끼리 소스코드를 주고 받을 필요가 없음
2. 같은 파일을 여러명이 동시에 병렬 개발 가능
3. 변동 과정을 체계적으로 관리할 수 있음(업데이트 히스토리 확인, 이전 버전 백업)
4. 중앙 서버 데이터 유실 쉽게 복구 가능

Git 운영법(GitFlow)

브랜칭 모델을 적용하여 고수준으로 저장소를 관리하기 위한 브랜칭 기법

프로젝트를 진행하며 발생하는 많은 branch를 관리할 수 있도록 해주는 규칙 및 전략이다. 기본 전략이기 때문에 프로젝트 상황에 맞게 커스텀해서 사용하면 된다.

사용이유

1. feature branch를 이용하기 때문에 기능 개발의 책임 소재를 명확히 할 수 있다.
2. 개발 버전과 제품 버전을 개별 관리할 수 있다.
3. Pull Request를 이용하기 때문에 쉽게 코드 리뷰를 할 수 있다.
4. feature branch와 hotfix branch의 commit message를 취합하게 되면, 이전 버전과 변경점 쉽게 파악 가능하다.

5가지 종류의 브랜치

• main : 제품으로 출시될 수 있는 브랜치
• dev : 다음 출시 버전을 개발하는 브랜치
• feature : 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

여기서 main과 dev는 중심이 되는 브랜치이다.

브랜치란?

Fork

내 개인 레퍼지토리 저장공간에 다른 레퍼지토리를 가지고 와서 작업, 사용법이 까다로움, fork를 해온 순간 내 레퍼지토리와 실제 레퍼지토리의 버전을 동기화

branch

나뭇가지, 나무에서 여러 갈래로 뻗은 줄기
하나의 배포중인 서비스 ← 나무
그리고 branch라고 하는 것은 특정 기능을 개발하거나 버그를 수정하거나 할 때 또 하나의 길을 만들어내는 것

branch 병합

병합은 2가지 종류가 있다.

1. fast-forward 방식
   빨기 감기 방식이다. 병합하려는 브런치의 현재 상태로 그대로 같은 위치로 이동하는 것이다.
   

2. non-fast-forward 방식
   merge하려는 브런치와는 별개로 다른 버전을 만들어 새로운 병합본을 만든다.
   

git reset(커밋 취소하기)

아직 원격 저장소에 push하기 전이라면 reset을 사용할 수 있다. 작업을 하고 add or commit을 했는데 취소해야 하는 상황이 생길 수 있다. 그 때 되돌리기 원하는 만큼 옵션을 지정하여 git reset 명령어를 사용하여 되돌릴 수 있다.

• git reset --hard
  돌아가려는 커밋 이후의 모든 내용을 지워 버린다. staging area와 working directory 모두 돌아가려는 커밋과 동일해진다. hard 옵션을 사용하면 돌아간 커밋 이후의 변경 이력은 모두 삭제합니다.

97f1e31 -> d678197 -> 12741e5 차례로 커밋을 했습니다.
이 때 마지막 커밋 12741e5을 취소하고 싶습니다. 이 때는 git reset --hard <COMMIT_ID> 명령어로 HEAD가 이전 커밋(d678197)을 가리키도록 합니다.

위처럼 실행할 경우 2, 3번 커밋 반영 내용은 모두 사라집니다. 물론 코드도 날라간다.

• git reset --soft
  돌아가려는 커밋으로 되돌아가고, HEAD가 돌아가려는 커밋을 새롭게 가리키게 됩니다. staging area와 working directory는 아무런 변화도 없다. 변경 이력은 모두 삭제하지만 변경 내용은 남아있습니다. 그러나 stage 되어있습니다.

add명령어 필요없이 바로 commit 진행 가능합니다.

• git reset --mixed
  변경 이력은 모두 삭제하지만 변경 내용은 남아있습니다.

위처럼 실행할 경우 이력은 날아가나 unStage 상태로 코드는 남아있습니다. 코드를 반영하려면 add 명령어로 stage에 반영하고 commit 합니다.

커밋과 푸쉬 작업중에 에러현상이 벌어졌을 경우(충돌)의 경우 해당 상태의 커밋이나 스테이징을 취소하거나 수정하기 위해 사용합니다.

git revert(커밋 내용 되돌리기)

이미 원격 저장소에 push한 상태라면 reset은 사용할 수 없고 revert를 사용해야 한다. git reset은 HEAD 위치를 바꿔버려서, 로컬 저장소의 상태를 커밋 이전 상태로 강제 변경해버립니다. 하지만 커밋을 협업중인 원격 저장소에 push해버린 경우, 로컬 저장소에서 커밋을 취소해버리면 원격 저장소와 상태가 틀어져버립니다. 특히 원격 저장소에서 force push를 금지하는 경우, 로컬 저장소의 변경사항을 push할 수 없게 되어버립니다. 이런 경우에는 git revert로 특정 커밋의 내용을 되돌리는 커밋을 하는 방법을 사용해야합니다.

97f1e31 -> d678197 -> 12741e5 차례로 커밋을 했습니다.
12741e5를 취소해서 커밋을 되돌려야할 경우

git log 찍고, 커밋이 다음의 commit1>2>3의 순서로 발생했다고 해보자.
오른쪽에 뜨는 것이 git hash이다.

내가 돌아가려는 커밋이 commit1이면, commit3를 먼저 revert하고 이후 commit2를 revert하는 방식으로 순차적으로 진행해야 한다.

이후 commit을 하면 끝이다.

git commit -amend(커밋 덮어쓰기)

커밋의 내용을 덮어쓸 때는 git commit의 amend 옵션을 사용합니다. 수정할 내용을 스테이징에 반영하고 다음 명령어를 실행해줍니다.

메시지 옵션을 사용하지 않으면 커밋 메시지 작성을 위한 에디터가 실행되고, 메시지를 작성 후 저장해줍니다.

amend의 옵션의 경우 스테이징에 추가된 내용을 반영해주는 동시에 커밋 메시지도 변경해줍니다. 따라서 변경할 내용이 없을 때도 커밋메시지를 변경하고 싶을 때 자주 사용합니다.