Git

정의

• 원격 서버(remote server)의 저장소(repository)에 로컬 소스들을 저장하며 버전을 관리 하는 시스템

원격 저장소(repository)

• 로컬파일들을 업로드 하여 보관시키는 저장소
• 프로젝트 한개당 하나를 생성하는 것이 보편적
• 경우에 따라서 한개의 원격 저장소에 여러 프로젝트를 구성하기도 한다.
• 리파지토리는 URL로 표현된다
• https://github.com/user/repository.git

원격 저장소 제공 해주는곳(원격 서버)

• GitHub
• Bitbucket
• GitLab

원격 저장소 이름

• 원격 저장소에 깃을 이용하여 프로젝트를 생성시 이름을 정해줘야한다
• 기본으로 사용되는 것이 origin
• 원격 저장소를 가지고 있는 서버 자체를 remote라고 명명한다

로컬 파일

• 사용자가 사용중인 로컬컴퓨터의 파일

작동원리

• 로컬 환경의 파일을 추적하고 있다가 사용자가 파일을 수정하면 변경을 감지, 수정 내용들중 저장 중인 원격 서버에 반영 하고 싶은 파일을 골라서 반영

깃 3가지 기본 기능

push

• 변경된 로컬 파일을 원격 저장소로 밀어 올리는 기능

pull, fetch

• 원격 저장소의 파일을 로컬 컴퓨터로 가져오는 기능

브랜치

• 새로운 기능을 추가하기 위해 생성하는 메인으로 부터 분리된 작업공간, 새롭게 생성된 브랜치와 메인은 같은 상태를 갖는다.
• 깃을 이용하여 처음 초기화시 기본적으로 master 브랜치가 생성된다.
• 작업이 완료되어 정상적으로 수행되는 브랜치는 마스터로 다시 합병 시킨다.

명령어

clone

• 원격 서버에 존재하는 저장소를 로컬 컴퓨터로 카피 하는 명령어
• 로컬 시스템에서 카피하고자 하는 폴더로 이동후에
• git clone repositoryURL 사용

pull

• 클론 후에 새로운 변경사항에 원격서버에 생기면 해당 기능을 로컬로 반영해주는 명령어
• git pull //현재 내 로컬 브랜치와 같은 이름의 리모트 서버 브랜치를 사용
• git pull origin master //origin리모트 서버의 master 브랜치를 사용

fetch

• 변경내용을 받아는 오되 로컬 컴퓨터에 반영은 하지 않는다.
• 보통 fetch로 변경 사항 확인후 pull로 반영시킨다
• git fetch

add

• 커밋전에 로컬에서 변경되어 원격 서버에 반영하고 싶은 파일을 추가하는 명령어
• git add <경로> 하면 해당 경로에 있는 모든 파일을 추가 한다
• 위를 스테이징 한다고 한다

commit

• add명령어 이후에 해당 파일들을 스테이징 한 이후에 커밋을 사용
• 커밋을 기준으로 버전을 나눈다고 한다.
• 각각의 커밋은 고유한 해쉬값을 가진다
• 이 해쉬값을 사용하여 버전별로 이동을 할수 있다고 한다.
• 커밋 할때 커밋 메시지를 작성할수있다
• add로 추가된 변경 파일을 하나의 버전으로 포장하는 작업이라고 생각 하면된다.

push

• add, commit이후 해당 변경 내용을 원격 서버에 반영하는 명령어
• 이 명령어를 사용하여야 직접적으로 저장소의 내용이 변경된다.
• git push origin master // origin 리모트 서버의 master 브랜치로 반영

git 참고

• https://rogerdudler.github.io/git-guide/index.ko.html
• https://evan-moon.github.io/2019/07/25/git-tutorial/
• https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html

GitFlow

Merge Conflict

• 원격 저장소 사용시 발생할수 있는 에러
• 동시에 같은 파일의 같은 부분에 서로 다른 수정이 이루어진 상황
• 둘중 하나만 반영, 아니면 아무것도 반영하지 않을지 선택할수있다.

브랜치를 사용하는 이유

• 위의 합병 충돌의 상황을 방지 하기위해 각자 맡은 기능별로 브랜치를 작성하여 독립된 환경에서 각자 개발

브랜치 전략

• Git사용시 어떻게 하면 브랜치를 효과적으로 관리 할수있을까하는 관점에서 세우는 전략
• 대포적으로 GitFlow가 있다

GitFlow 전략 설명

• master와 develop 브랜치를 가지고 시작하는 전략
• master로는 절대 직접 커밋을 하지 않는다.
• develop은 현재 개발을 진행하고 있는 브랜치.
• develop으로 부터 feature별로 브랜치를 생성하여 기능별 브랜치를 추가 생성하여 개발을 진행.

• 출처 https://evan-moon.github.io/2019/07/28/git-tutorial-advanced/
• 위 이미지는 파랑(master)에서 빨강(develop)을 생성하여 초록(AddTypeScript) 분홍(kakaoLogin)등의 feature 별로 브랜치를 생성하여 완료 이후 develop으로 merge시키는 프로젝트 진행을 보여주는 그림이다.
• 출처 https://evan-moon.github.io/2019/07/28/git-tutorial-advanced/
• 이후 개발완료 시점이 오면 master로부터 release를 생성 모든 develop의 내용을 반영 시킨다 realease는 배포만들 위한 브랜치 이므로 배포가 끝나면 버려진다
• 위 이미지는 realease를 생성후 develop을 merge하고 완료가 되어 master로 merge되는 흐름을 보여준다
• 출처 https://evan-moon.github.io/2019/07/28/git-tutorial-advanced/
• 증간에 Hotfix가 발생하는 경우
• 개발 도중 긴급한 버그 픽스가 이루어 져야 하는경우 develop에서 hotfix분기를 생성하면 지금 진행중인 테스트가 완전히 이루어지지 않은 기능들도 포함될수가 있어 이경우에는 master로부터 hotfix브랜치를 생성 고친후 master로 합병 시킨다
• 위 그림에서 잘 보면 hotfix가 master로 합병된이후 develop에 없는 기능인hotfix내용을 반영 시키기 위해 합병 시키는 모슴을 볼수있다.

브랜치 합병 Merge

정의

• 서로다른 두개의 브랜치를 서로 합치는 기능

명령어

Merge

• 가장 기본적인 합병, merge commit을 남긴다
• git checkout master
• git merge feature

Merge and squash

• git checkout master
• git merge –squash feature
• 일반 합병은 대상 브랜치의 모든 커밋을 그대로 타겟브랜치에 반영하지만 squash옵션을 사용하면 대상 브랜치의 모든 커밋을 하나의 커밋으로 합치고 타겟 브랜치에 합병 시킨다

Rebase

• git checkout feature
• git rebase master
• 합병 이후feature브랜치의 변경 사항들이 master의 내용인것처럼 된다 feature의 기점이 master였던것처럼된다.
• 문제점
• 다른 팀원들에게도 반영시키기 위해서는 원격 서버의 master와 로컬의 master를 강제로 병합하여야 하는 상황이 발생
• 출처 https://dzone.com/articles/merging-vs-rebasing
• 위와 같은 상황이 되면 모든 커밋 히스토리가 꼬이게 될수있다.
• 그래서 리베이스 전에 항상 squash를 사용한뒤 하는것이 좋다.

cherry pick

• git checkout master
• git cherry-pick #커밋해시넘버
• 다른 브랜치에서 어떤 하나의 커밋만 내 브랜치로 가져오는 기능
• 병합보단 해당 커밋이 내 브랜치에 커밋되는 형식으로 반영 된다

stash

• 임시로 작업 내용을 저장
• git stash // 현재 변경내용 스택에 저장
• git stash list // 스태쉬 목록을 확인
• git stash apply //가장 최근의 스태쉬를 다시 불러옴
• git stash brach-name // 스태쉬 이름을 branch-name으로 지정하고 스택에 저장
• git stash apply branch-name // 스택에 저장된 branch-name을 가져옴
• 스택은 FIFO이므로 이름 붙여 사용 하는것을 권장

Reset

• 지정한 커밋 당시로 되돌리기, 지정 커밋 이후의 모든 커밋 히스토리는 삭제됨
• git reset –hard #커밋해시코드
• hard soft mixed 3개의 옵션
• hard 지정한 커밋 이후의 히스토리 삭제, 삭제된 내용은 그대로 사라짐
• soft 지정한 커밋 이후의 히스토리 삭제 삭제된 내용들은 스테이지(add)상태로 돌아감
• mixed 지정한 커밋 이후의 히스토리 삭제, 삭제된 내용은 스테이지에 올라가지 않은 상태
• 기본은 mixed이다

revert

• 커밋을 반전, 추가 된 커밋이면 삭제, 삭제된 커밋이면 추가, 결과는 커밋으로 반영됨
• git revert #커밋해시코드
• git revert #커밋해시코드…#커밋해시코드 // 범위의 커밋을 모드 되돌림
• git revert HEAD // 현재 헤드가 위치한 커밋을 되돌린다.

GitFlow 참고

• https://ux.stories.pe.kr/183
• https://datasift.github.io/gitflow/IntroducingGitFlow.html
• https://nvie.com/posts/a-successful-git-branching-model/
• https://evan-moon.github.io/2019/07/28/git-tutorial-advanced/