220324 D+66 Git Branch, 프로젝트 workflow

✷ git & github

1. Git branch

① 브랜치

: 독립적으로 어떠한 작업을 진행하기 위한 개념.

⇒ 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에 여러 작업을 동시에 진행할 수 있다.

 

‣ 브랜치 기능의 장점

• 한 소스코드에서 동시에 다양한 작업을 할 수 있게 해준다
• 각각의 브랜치에서 생긴 변화가 다른 브랜치에 영향을 주지않고 독립적으로 코딩을 진행할 수 있다.

 

→ 여럿이 동시에 작업을 할 때 다른 사람의 작업에 영향을 주고 받지 않도록

통합 브랜치에서 자신의 작업 전용 브랜치를 만들고, 각자의 브랜치에서 맡은 영역에 대한 작업 진행, 

작업이 끝난 브랜치는 통합 브랜치에 병합하여 변경사항을 적용한다.

 

⇒ 독립적으로 특정 작업을 수행하여 그 결과를 하나로 모아가게 되어 

작업 단위(브랜치)로 그 작업의 내용들이 모두 기록되어

문제 발생 시 원인이 되는 작업을 찾아내거나 그에 대한 대책을 세우기 쉬워진다.

 

 

여러 브랜치를 만든 레파지토리의 Git Graph (이미지 출처 : Git Beginner's Guide for Dummies)

• 소스코드의 한 시점과 동일한 상태를 만들고 브랜치를 넘나들며 작업을 수행할 수 있다.

→ master 혹은 main이라는 이름을 가진 통합 브랜치에 뿌리를 두고 각각의 브랜치가 갈라져 나오는 모습.

→ 나누어진 브랜치에서 각자 독립적인 작업 영역(저장수)안에서 마음대로 소스코드를 변경할 수 있고,

분리된 작업 영역(브랜치)에서 변경된 내용들은 다른 브랜치와 병합(merge), 다시 새로운 하나의 브랜치로 모을 수 있다.

 

 

‣ 브랜치 종류

• 통합 브랜치(Integration Branch)

: 배포될 소스 코드가 기록되는 브랜치

→ 깃헙 레포지토리를 생성하게 되면 기본적으로 main 브랜치가 생긴다

(기존 레포지토리의 경우에는 master로 되어 있는 경우도 있음).

→ 해당 프로젝트의 모든 기능이 정상적으로 작동하는 상태의 소스코드가 담겨있음.

 

• 피처 브랜치(Feature Branch / 토픽 브랜치)

: 기능 추가, 버그 수정과 같이 단위 작업을 위한 브랜치.

→ 통합 브랜치로부터 만들어내며 피처 브랜치에서 하나의 작업이 완료가 되면

다시 통합 브랜치에 병합하는 방식으로 진행된다.

(feature/login, feature/로그인)

 

• dev / develop(e)

: 베타 버전, 모든 개발 로그들이 쌓이는 곳.

새로운 기능(feature)들이 완성되어 merge 되는 곳

 

• release: 한 번 배포해보는 것

 

• hotfix: 급한 버그 수정

 

• master / main: 항상 최신의 안정적인 프로그램. 안전함을 보장받은 곳

 

 

2. 브랜치 명령어 모음

① 새로운 브랜치 생성

git branch 새로운 브랜치 이름

 

② 새로운 브랜치 생성 후 해당 브랜치로 전환

git switch -c 새로운 브랜치 이름

git checkout -b 새로운 브랜치 이름

 

✷ 해당 브랜치로 이동

git switch 새로운 브랜치 이름

git checkout 새로운 브랜치 이름

⇒ 옵션 없이 명령어만 사용함

 

③ 브랜치 목록 확인

git branch

 

④ 브랜치 목록과 각 브랜치의 최근 커밋 확인

git branch -v

 

⑤ 브랜치 삭제

git branch -d 삭제할 브랜치 이름

브랜치를 삭제하는 것은 레포지토리에서 완전 삭제가 아닌 감추는 개념으로,

삭제한 브랜치의 이름으로 다시 브랜치를 만들면 예전에 작업했던 내용이 그대로 나타난다.

git branch -d 브랜치명으로 로컬 브랜치를 삭제하고
git push -d origin 브랜치명으로 로컬 브랜치 삭제를 원격에 반영한다
(이 때, 반드시 -d 옵션을 붙여주어야 한다. 안붙이면 에러남)
git branch -al 명령어로 모든 브랜치 목록 확인을 해준다.

GUI로 삭제 처리 한 경우 git branch -al로 확인했을 때 삭제한 브랜치도 보이는 경우가 있는데,
이럴 때는 git fetch --all --prune 명령어로 로컬과 원격 브랜치를 동기화할 수 있다.

git branch -D 브랜치명

해당 명령어는 병합하지 않은 브랜치를 강제 삭제하는 방법이다.

 

⑥ 브랜치 전환

git switch 브랜치 이름

git checkout 브랜치 이름

 

⑦ 브랜치 병합

master 브랜치로 dev 브랜치를 병합할 때 (master ← dev)

git checkout master

git merge dev

 

⑧ 로그에 모든 브랜치를 그래프로 표현

git log --branches --graph --decorate

 

⑨ 아직 commit 하지 않은 작업을 스택에 임시로 저장

git stash

 

⑩ 커밋의 베이스를 다시 정하고 싶은 경우

git log 명령어로 커밋 이력을 확인한다.

git rebase -i [commit number]

 

⑪ 여러 개의 커밋 로그를 하나로 묶고 싶은 경우

s, squash <commit> = use commit, but meld into previous commit

squash

 

▾ first commit을 남겨두고 second와 third commit을 squash하는 예시

pick b91e257 first commit
s 0118d46 second commit
s 1f199b7 third commit

 

⑬ 커밋 여러 개의 변경 사항을 취소하고 싶은 경우

git log로 되돌려야 할 커밋을 찾는다.

방향키로 예전 커밋을 살펴보고 원하는 커밋을 찾으면 해당 커밋의 hash를 기억한다.

git revert [saved hash]

git이 해당 커밋을 되돌리는 새로운 커밋을 생성할 것이고,

에디터 창이 나타나면 새로 커밋 메시지를 입력하거나 저장하고 종료한다.

 

⑭ 최근 커밋 메시지를 수정하고 싶은 경우

git commit —amend

 

✷ merged와 rebase의 차이점

‣ merge

변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해진다.

 

‣ rebase

rebase의 원리가 바로 앞서 배웠던 fast-forward와 같다.

말 그대로 branch base를 이동시킨다는 뜻으로, 머지처럼 브랜치 통합을 목적으로 하지만,

특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능을 한다.

 

위 그림을 설명하자면, feature/login 브랜치에서 rebase 명령어를 입력하면

main의 다른 커밋에서 충돌이 없을 경우

main의 가장 최신 커밋으로 브랜치가 가리키는 곳이 변경된다.

 

 

⑮ 병합을 취소하고 이전 커밋으로 되돌아가는 명령어

git reset --hard 커밋 넘버

 

✷ 옵션별로 차이점

—soft 옵션을 쓰면 HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리키게 되고,

현재 작업 중인 working directory와 staging area는 아무런 영향을 받지 않는다.

 

—hard 옵션을 쓰면 HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리키게 되고,

그리고 staging area와 현재 작업 중인 working directory도 해당 커밋의 모습과 동일하게 변한다.

커밋을 하지 않고 git reset --hard 옵션을 사용하게 되면 작업했던 것이 전부 날아가기 때문에 주의해서 사용할 것.

 

—mixed 옵션을 쓰면 HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리키게 되고,

 staging area도 해당 커밋의 모습과 동일하게 변하지만

현재 작업 중인 working directory는 아무런 영향을 받지 않는다.

 

⑯ git cherry-pick

다른 브랜치에 있는 커밋을 선택적으로 내 브랜치에 적용시킬 때 사용하는 명령어

git cherry-pick commit_hash_1

 

 

3. 프로젝트 workflow - git의 브랜치 기능 활용 방법

① Remote에 생성한 프로젝트 Repository를 각자의 Remote Repository로 fork한 후

Local에서 작업하기 위해 git clone 명령어로 Repository를 Local로 가져오기.

 

② git checkout -b dev(git switch -c dev)명령어를 통해 dev 브랜치 생성 후

Remote Repository에도 생성한 브랜치를 반영하기 위해 git push origin dev 명령어를 사용한다.

잘 생성되었는지 확인하기 위해 git branch 명령어를 사용하고, q를 눌러 종료한다.

 

✷ HEAD: 현재 위치의 커밋(현재 작업 중인 커밋).

③ git checkout -b featuer/login(git switch -c featuer/login)명령어로 브랜치를 생성하고,

여기서 파생된 브랜치를 만들기 위해 git checkout -b feature/login-oauth(git switch -c feature/login-oauth)

명령어로 해당 이름의 브랜치를 생성하고 브랜치로 이동한다.

 

④ feature/login-oauth에 있는 코드를 feature/login 브랜치로 병합하기 위해

git checkout feature/login(git switch feature/login)명령어를 사용하여 해당 브랜치로 이동한다.

이동한 상태에서 git merge featuer/login-oauth 명령어를 입력한다.

⇒ feature/login-oauth 브랜치가 머지되기 전 feature/login 브랜치에 추가적인 커밋이 없으므로,

브랜치가 분기될 필요가 없어 자동적으로 fast-forward 방식으로 병합이 이뤄진다.

✷ fast-forward 방식

: 별도의 커밋을 생성하지 않고 어떠한 브랜치가 가리키는 커밋을 다른 브랜치가 생성한 커밋으로 바꾸는 작업.

여기서는 feature/login 브랜치가 가리키는 커밋을 feature/login-oauth가 생성한 커밋으로 바꾼다.

 

⇒ 만약 feature/login 브랜치에 별도 커밋이 있으면 merge commit 방식으로 병합된다.

     이는 각 브랜치가 줄기처럼 분기한 후 병합의 모양새를 가진다.

 

⑤ 로컬에서 작업한 내용(로컬의 변경 사항)을 Remote Repository에 업로드하기 위해

git push origin feature/login 명령어를 사용하여 해당 브랜치를 Remote Repository에 업로드한다.

 

⑥ github의 pull request 기능을 통해 간단하게 pr 내용을 입력 후 Create pull request 버튼을 클릭한다.

 

✷ 전체 프로젝트 진행 흐름

 

 

 

 

 

 

 

 

 

 

 

 

 

• Git 브랜치의 개념을 이해할 수 있다.
• Git 으로 협업하며 브랜치를 나누는 이유를 이해할 수 있다.
• Git 으로 프로젝트를 관리하며 브랜치를 생성, 전환, 병합할 수 있다.