매일기록

Git branch에 대해 더욱 깊숙히 알아보자.

git을 쓰는 이유는 사실 브랜치 때문이라 봐도 무방할 것 같다. 동일 코드를 여러 사용자가 이용할 때 버전 관리를 용이하게 하는 것이 바로 브랜치이다.

git에서 항상 작업할 브랜치를 미리 선택해야 한다. 처음에 git을 설치하게 되면 master 브랜치가 선택되어 있다. 기존 브랜치가아닌 다른 브랜치에서 작업하고 싶다면 체크아웃(checkout) 명령어를 실행하여 원하는 브랜치로 전환할 수 있다. 체크아웃을 실행하면 우선 브랜치 안에 있는 마지막 커밋 내용이 작업 트리에 펼쳐진다. 브랜치가 전환되었으므로 이후에 실행한 커밋은 전환한 브랜치에 추가된다.

위의 이미지에서 HEAD가 보이는데 HEAD란 현재 사용중인 브랜치의 선두 부분을 나타내는 이름이다. HEAD를 이동하면 사용하는 브랜치가 변경된다.

stash

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

체크아웃할 때 전환할 브랜치에 변경 사항이 있을 경우 체크아웃에 실패하게 된다. 이 경우 전환 전 브랜치에서 커밋하지 않은 내용을 커밋하거나 stash를 이용해 일시적으로 변경 내용을 다른 곳에 저장하여 충돌을 피하게 한 뒤 체크아웃을 해야한다.

stash란, 파일의 변경 내용을 일시적으로 기록해두는 영역이다. stash를 사용하여 작업 트리와 인덱스 내에서 아직 커밋하지 않은 변경을 일시적으로 저장해 둘 수 있다. 이 stash에 저장된 변경 내용은 나중에 다시 불러와 원래의 브랜치나 다른 브랜치에 커밋할 수 있다.

브랜치 통합하기

작업이 완료된 토픽 브랜치는 최종적으로 통합 브랜치에 병합된다. 브랜치 통합은 merge와 rebase를 사용하는 2가지 종류가 있다. 둘의 결과는 다르니 잘 알아보자

merge

여러개의 브랜치를 하나로 모을 수 있다.

아래 그림과 같이 master 브랜치에서 분기하는 bugfix라는 브랜치가 있다고 가정하자.

bugfix 브랜치를 master브랜치로 병합할 때 master브랜치가 수정사항이 없다면 merge를 통해 손쉽게 병합이 가능하다. bugfix의 이력은 master의 이력을 모두 포함하고 있기 때문에 master의 HEAD가 bugfix의 HEAD로 이동하는 것이다. 이를 fast-forward라고 한다.

그러나 bugfix를 분기한 이후에 master 브랜치에서 수정이 있었을 경우 두 브랜치의 변경 내용을 통합할 필요가 있다.

따라서 양쪽의 변경을 가져온 merge commit을 실행하게 된다.

병합 실행시에 fast-forward 병합이 가능한 경우라도 non fast-forward병합 옵션을 지정하여 아래 그림과 같이 만들어 낼 수도 있다.

rebase

위와 같은 상황이 있다고 가정하자.

rebase를 적용하면 아래와 같이 master 브랜치의 뒤에 이어 붙여진다.

이때 이어붙여진 커밋 버전은 master의 HEAD와 충돌여부가 있기 때문에 이 부분을 수정해야한다.

rebase를 적용하면 master의 HEAD는 그대로 유지이기 때문에 bugfix와 HEAD 위치를 동일하게 맞추기 위해 merge를 진행한다.(fast-forward)

성공적인 Git 브랜칭 모델

이 운용 모델에서는 크게 나눠 4가지 종류의 브랜치를 이용하여 개발을 진행합니다.

• 메인 브랜치(Main branch)
• 피처 브랜치(Feature branch) 또는 토픽 브랜치(Topic branch)
• 릴리스 브랜치(Release branch)
• 핫픽스 브랜치(Hotfix branch)

메인 브랜치

master와 develop 브랜치를 대체로 메인으로 사용한다.

master: 배포 가능한 상태만을 관리 커밋할 때 태그를 사용하여 배포 번호 기록

develop: 통합 브랜치의 역할을 하며 평소 이 브랜치를 기반으로 개발

피처 브랜치

토픽 브랜치를 담당한다.

새로운 기능 개발 및 버그 수정이 필요할 때 develop 브랜치로부터 분기한다.피처 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에 원격으로 관리하지 않는다. 개발이 완료되면 develop 브랜치로 병합하여 다른 사람과 공유한다.

릴리즈 브랜치

버그를 수정하거나 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작하는지 확인한다. 관례적으로 브랜치 이름 앞에 release-를 붙인다. 배포 가능한 상태가 되면 master로 병합하며 커밋에 릴리즈 번호 태그를 추가한다. 릴리즈 브랜치에서 버그 픽스를 할 경우 디벨롭 브랜치에도 병합을 해줘야한다.

핫픽스 브랜치

배포한 버전에 긴급하게 수정해야할 필요가 있을 경우 master브랜치에서 분기하는 브랜치이다. 관례적으로 브랜치 이름 앞에 hotfix-를 붙인다. 

배포가 된 것에서 예상치 못한 버그가 일어났을 때 신속하게 변경해 주는 브랜치이다. 작업 완료 후 디벨롭 브랜치에도 병합해줘야한다.

출처: https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html

이미 출처에서 잘 설명해주고 있지만, 나 스스로도 공부할 겸 포스팅을 진행한다.

개발을 팀단위로 할 때 다른 개발자들과 하나의 소프트웨어를 개발한다. 누군가는 버그픽스, 누군가는 새로운 기능 추가를 한다.

이렇듯 서로 다른 목적의 개발을 한 프로젝트에서 진행하기 때문에 각각 서로 다른 버전의 코드가 만들어 진다.

이럴때 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어주는 기능이 브랜치다. 각자 독립된 로컬 레포지토리에서 소스코드를 변경하고 이후에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어낼 수 있다.

아래 그림을 보자. 여러 명이서 동시에 작업을 할 때의 흐름을 알 수 있다. 각자 맡은 작업의 브랜치를 생성해서 해당 작업을 마친 후 master 브랜치에 머지함으로서 소프트웨어의 완성도를 높일 수 있다. 또한, 브랜치 기록은 남으므로 어떤 시점이 문제인지, 복원도 가능하다.

작업에 따라 자유롭게 브랜치 생성이 가능하지만, 더욱 효과적으로 관리하려면 같이 일하는 작업자와 어떠한 방식으로 브랜치를 만들고 통합할 것인지 정해두는 것이 좋다.

우리가 만들 수 있는 브랜치의 종류는 다음과 같다.

통합 브랜치(Integration Branch)

언제든지 배포할 수 있는 버전을 만들 수 있어야하는 브랜치이다. 안정적인 상태를 유지하는 것이 중요하다. 일반적으로 master 브랜치가 통합 브랜치이다.

토픽 브랜치(Topic Branch)

기능 추가나 버그 수정과 같은 단위 작업을 위한 브랜치이다. 여러 개의 작업을 동시에 진행할 때 그 수만큼 토픽 브랜치를 생성할 수 있다.

토픽 브랜치는 통합 브랜치로부터 만들어지며 작업이 완료되면 통합 브랜치에 병합하는 방식으로 진행된다. 피처 브랜치(feature branch)라고도 불린다.

내가 pull 한 뒤 다른 사람이 동일 저장소에 push할 경우 그 이후의 나의 push는 거절된다. 버전의 분기점이 되기 때문이다.

이때 2가지 경우가 있다.

1. 내가 건드린 파일이 다른 사람이 수정한 파일과 의존성이 없는 경우
2. 내가 건드린 파일이 다른 사람이 수정한 파일과 의존성이 있는 경우

1번의 상황에선 자동 merge가 가능하다. merge를 할 경우 내 로컬 레포지토리에 다른 사람의 수정 작업이 병합된다.

2번의 경우가 문제가 된다. 충돌이라하는 부분이다.

깃에서 충돌 부분을 표시해주는데 

위와 같이 표시해주며 ===== 윗부분이 로컬저장소, 아랫 부분이 원격 저장소의 변경 내용이다.

표시된 부분을 원하는 버전으로 고쳐주고 다시 커밋을 수행하면 된다.

출처: https://backlog.com/git-tutorial/kr/intro/intro5_2.html

gitignore란 무엇이냐하면

git add를 할 때 제외하고 싶은 파일 명 패턴을 입력하는 것이다.

만약 딥러닝 프로젝트를 한다 치면 데이터 셋들이 있는데 이를 전부 레포지토리로 옮길 순 없다. 파일 용량 제한 때문에...

그러니까 .git이 있는 곳에서 뭐... 대충

*.png
*.jpg
*.h5

등을 적으면 원하는 파일들만 업로드가 가능하다.

깃헙은 형상관리 툴 중 하나로 본인의 코드를 관리하기 적합한 툴이다.

이 포스트에서는 깃헙 사용 방법과 개인플젝이나, 포트폴리오를 만들 때 주로 쓰는 커맨드를 담아봤다.

깃헙 로그인을 하면 다음과 같은 화면이 나온다. 깃헙에서 대체로 프로젝트는 레포지토리 단위로 담긴다.

레포지토리를 생성하기 위해 좌상단의 new 버튼을 눌러보자.

빨간 별이 붙어있는 것이 필수입력사항인 것은 누구나 알 수 있다.

public은 구글 검색했을 때 나오고 Private는 안나오는데 내가 알기론 유료이다.

1. ReadMe - 레포지토리에대한 설명을 적을 수 있는 .md 파일로 마크다운 파일이다. 

2. .gitignore - 나중에 add를 할 때 알겠지만 gitignore에 담긴 확장자나 폴더등은 add할 때 무시된다.

3. license - 라이센스는 이 레포지토리 내의 소스코드의 권한을 말한다. 라이센스는 MIT, Apache 등 여러가지가 있으며, 상업적 사용가능, 불가능 등 여러가지가 있기 때문에 자세히 알아보고 사용해야한다.

이제 레포지토리 이름을 설정하고 Create repository를 눌러보자

아래와 같은 화면이 나온다. 초심자라면 뭐 어쩌란거지.. 라고 생각할 수 있는데 터미널에서 타이핑하라는 것이다.

맥이나 리눅스는 터미널이 있는데 윈도우는 git desktop에서 하는걸 추천한다.

https://desktop.github.com/

한줄한줄 읽어보자.

1. echo "# test" >> README.md - echo는 일단 리눅스 명령어인데 README.md라는 파일에 # test를 입력한다는 의미이다. 즉 리드미 파일 생성

git init - 깃 이니셜라이징으로 .git이 생성된다. 알겠지만 파일 앞에 .이 붙으면 숨김파일이다. 

git add README.md - 리드미 파일을 스테이지로 올린다.

git commit -m "first commit" - 스테이지에 있는 데이터를 로컬 레포지토리로 올린다. 이때 메시지(태그)를 first commit으로 넣는다.

git branch -M main - 브랜치는 main 브랜치로 설정

git remote add origin https://github.com/dmsehf804/test.git - 로컬 레포지토리를 원격 레포지토리인 저 주소와 연결한다.

git push -u origin main - main 브랜치로 로컬 레포지토리에있는 데이터를 원격 레포지토리로 푸시(upload)한다.

스테이지니 로컬레포지토리니 설명이 부족해서 이미지를 가져왔다. 추가 질문은 댓글로...

기본적으로 깃의 추적은 변경된 파일만을 추적한다. 변경하지 않은 파일은 굳이 수정해서 올릴 필요가 없기 때문이다.

요약하자면

1. git이 이니셜된 폴더 내에서 프로젝트를 생성하고 개발

2. 수정된 파일이 있으면 git add 를 이용하여 스테이지에 올림

3. 스테이지에 있는 데이터를 메시지를 붙여 commit (로컬저장소)

4. 로컬저장소에 있는 데이터를 push와 함께 원격저장소로 전송

이 밖에도 남의 github 코드를 가져오려면 git clone이 있고 현재 로컬 코드와 원격 코드의 버전이 맞지 않을 경우 git pull을 통해 동기화를 하는 커맨드도 존재한다.