[Git] git이 뭘까!

do_large·2021년 3월 9일

git

Git

목록 보기

1/4

Git이란?

Git은 소스코드를효과적으로 관리하기 위해 개발된 분산형 버전관리 시스템이다!!
Git에서는 소스 코드가 변경된 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 되돌아갈 수도 있다.

Git 저장소

깃 저장소는 파일이나 폴더를 저장해놓는 곳인데,
파일을 변경 이력별로 구분해서 저장할 수 있다!

원격 저장소
파일이 원격 저장소 전용 서버에서 관리되며 여러사람이 함께 공유하기 위한 저장소
로컬 저장소
내 PC에 파일이 저장되는 개인 전용 저장소

작업트리와 인덱스

작업트리
폴더!
인덱스
커밋을 실행하기 전의 저장소와 작업트리 사이에 존재하는 공간이다.
인덱스에 등록되지 않은 파일은 커밋이 안된다.

정리

커밋 작업은 작업트리에 있는 변경내용을 인덱스에 파일 상태를 기록(스테이징) 한다. 즉, 저장소에 변경내용을 기록하기 위해서는 기록하고자 하는 모든 변경사항들이 인덱스에 존재해야 한다!!!

인덱스가 존재하기때문에 저장소에 커밋하고 싶은 파일과 하지 않은 파일을 구분해서 관리할 수 있다!

push

로컬 저장소의 데이터를 원격 저장소로 밀어넣기

pull

원격 저장소의 데이터를 로컬 저장소에 가져와 병합하기

만약 로컬 저장소에 원격 저장소의 모든 변경사항이 반영되어 있는 상태에서, 원격저장소에 새로운 변경사항이 생긴다면 원격저장소의 변경사항을 pull 해서 로컬 저장소에 가장 최신의 상태를 병합할 수 있다.

그런데,

이런 식으로 로컬저장소도 일정 시점에서부터 변경되고, 원격 저장소도 일정 시점부터 변경이 된다면,

충돌이 발생하기때문에 충돌을 수동으로 해결한 뒤 직접 commit을 해주어야 한다!

fetch

원격 저장소의 데이터를 로컬에 가져오기만 하기

pull을 실행하면 원격저장소의 내용을 가져와 자동으로 병합작업을 실행한다.

반면, fetch를 실행하면, 원격저장소의 최신이력을 확인할 수 있는데, 이름없는 브랜치로 로컬에 가져오게 된다! 이 브랜치는 'FETCH_HEAD'라는 이름으로 확인할 수 있다.

만약 원격저장소의 내용을 로컬저장소에 통합하고 싶은 경우에는 'FETCH_HEAD'브랜치를 merge하거나 다시 pull을 실행하면 된다!(fetch + merge == pull)

merge

변경 이력을 통합하기

내가 pull해온 저장소가 최신 버전이 아닐 경우,
내 push요청이 거부된다.

이런 경우 merge라는 작업을 통해 최신버전의 변경사항을 내 저장소에도 갱신해야한다.

그런데 merge를 통해 변경된 부분을 자동으로 병합할 수 없는경우도 있다.
원격 저장소와 로컬 저장소 양쪽에서 파일의 동일한 부분을 변경한 경우에는 두 파일 중 어느쪽을 저장할건지 자동으로 판단할 수 없기때문에 충돌이 발생한다.

충돌이 발생한 부분은

>>>>>>>>>>>>>>>>>>>>

<<<<<<<<<<<<<<<<<<<<

로 감싸져 있고

===== 로 구분된 윗 부분이 로컬 저장소,
아랫 부분이 원격 저장소의 변경 내용이라는 점!

그래서 충돌 부분을 수정한 다음에 다시 커밋을 수행하면 된다!

브랜치

브랜치란?

여러사람이 동일한 소스코드를 기반으로 서로 다른작업을 할 때는 각각 서로 다른버전의 코드를 만들게 된다.

이럴때 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 브랜치이다!

각자 독립적인 작업 영역에서 마음대로 소스코드를 변경하고, 분리된 작업영역에서 변경된 내용은 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있다!

그리고 브랜치는 다른 브랜치와 merge함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있다.

블로그에 있는 그림인데 브랜치를 너무 잘 표현한 그림이라서 가져와 봤다.

메인 브랜치에서 자신의 작업 전용 브랜치를 만든다.
각자 작업을 진행한 뒤, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치 변경사항을 적용한다.
다른 사람의 작업에 영향을 받지 않고, 독립적으로 특정 작업을 수행한 뒤 그 결과를 하나로 모아 나가게 된다.

: 이렇게 작업을 진행하게 되면, 브랜치로 그 작업의 기록을 중간중간에 남기게 되므로 문제가 발생했을때 원인이 되는 작업을 찾기가 쉬워진다.

master 브랜치

저장소를 처음 만들때의 default 브랜치임
다른 새로운 브랜치를 만들어 작업하지 않는 이상 모든 작업은 master 브랜치에서 이루어 진다.

브랜치 만들기

통합 브랜치(integration branch)

언제든지 배포할 수 있는 버전을 만들 수 있어야 하는 브랜치이다.
늘 안정적인 상태를 유지하는 것이 중요하다. 소스코드의 모든 기능이 정상적으로 동작하는 상태여야 한다.

보통 default 브랜치인 master브랜치를 통합 브랜치로 사용한다.

만약 버그를 수정하거나 새로운 기능을 추가해야 한다면 토픽 브랜치를 만들어서 사용하면 된다.

토픽 브랜치(topic branch, feature branch)

기능 추가나 버그 수정과 같은 단위 작업을 위한 브랜치이다.
토픽 브랜치는 보통 통합 브랜치로 부터 만들어 내며, 토픽 브랜치에서 특정 작업이 완료되면 다시 통합 브랜치에 병합하는 방식으로 진행된다.

브랜치 전환하기

Git에서는 항상 작업할 브랜치를 미리 선택해야 한다.

git checkout <branch>

checkout 명령에 -b 옵션을 넣으면 브랜치 작성 & 체크아웃이 한번에 가능
git checkout -b <branch>

위의 명령어를 실행하면 작업하고자 하는 브랜치로 전환할 수 있다.

브랜치를 전환하면 해당 브랜치 안에 있는 마지막 커밋 내용이 작업 트리에 펼쳐진다.

HEAD

현재 사용중인 브랜치의 선두 부분을 나타내는 이름이다.
기본적으로는 master의 선두 부분을 나타내는데, HEAD를 이동하면 사용하는 브랜치가 변경된다.

stash

커밋하지 않은 변경내용이나, 새롭게 추가한 파일이 인덱스와 작업트리에 남아 있는 채로 다른 브랜치로 checkout 하면, 그 변경내용은 기존 브랜치가 아닌 전환된 브랜치에서 커밋 할 수 있다.

단, 커밋 가능한 변경내용 중에 전환된 브랜치에도 한차례 변경이 되어있는 경우에는 체크아웃에 실패할 수 있다!!!!!!!!!!! 이 경우에는 이전 브랜치에서 커밋하지 않은 변경내용을 커밋하거나, stash를 이용해 일시적으로 변경내용을 다른 곳에 저장하여 충돌을 피하게 한 뒤 체크아웃을 해야한다.

stash란 파일의 변경내용을 일시적으로 기록해두는 영역인데, 이 stash에 저장된 변경내용은 나중에 다시 불러와 원래의 브랜치나 다른 브랜치에 커밋할 수 있다.

브랜치 통합하기

작업이 완료된 토픽 브랜치는 최종적으로 통합 브랜치에 병합된다.

브랜치 통합에는 merge와 rebase를 사용하는 두가지 종류가 있다.
이 두가지 중 어느것을 사용하느냐에 따라 통합 후의 브랜치의 이력이 크게 달라진다.

merge와 rebase를 비교하면서 이해하는것은 블로그에 그림과 같이 자세히 설명이 나와있기때문에 블로그 글을 읽고 이해하는게 더 나을것같으니 들어가서 차근차근 읽어보세요!

두 방식의 차이점을 보면
merge는 변경 내용의 이력이 모두 남아있기때문에 이력이 복잡해진다는 특징이 있고,
rebase는 이력은 단순해지지만, 원래의 커밋 이력이 변경된다. 정확한 이력을 남기고자 할때는 사용하면 안된다!

A successful Git branching model 칼럼 : Git의 브랜치 운용 모델

메인 브랜치
master 브랜치와 develop 브랜치를 보통 메인 브랜치로 사용한다.
- master 브랜치는 배포가능한 상태만을 관리함.
- develop 브랜치는 통합 브랜치의 역할을 하며, 보통 이 브랜치를 기반으로 개발을 진행한다.
피쳐 브랜치(feature branch)
- 토픽 브랜치의 역할을 담당한다.
- 새로운 기능 개발 및 버그 수정이 필요할 때 develop 브랜치로부터 분기해서 작업한다.
릴리즈 브랜치
- 버그를 수정하거나 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작하는지 확인한다.
- 릴리즈를 위한 최종적인 버그 수정 등의 개발을 수행한다.
핫픽스 브랜치
- 배포한 버전에 긴급하게 수정해야 할 필요가 있을 경우 사용하는 브랜치
- 이 브랜치는 이미 배포한 소스코드에 큰 버그가 있는 경우 develop 브랜치를 거쳐 수정과 배포를 하게 되면 시간이 많이 소요되고 안정성을 보장하기도 어렵기때문에, 바로 배포가능한 master 브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정하고 바로 master 브랜치에 병합해서 이를 배포한다.