git 버전관리, branch & merge이해 ( sourcetree )

minju:)·2024년 7월 9일

git

목록 보기

2/3

📌 Branch

: 새로 만든 커밋은 기존 커밋 다음에 시간 순으로 쌓인다. 하지만 여러명이 협업을 하면 인원수대로 갈라지게 된다. 특정 기준에서 줄기를 나누어 작업을 할 수있는 기능을 브랜치라고 하며 브랜치를 만들지 않고 모두 동일한 커밋을 기준으로 커밋을 만들려고 한다면 오류가 난다.

🏷️ branch를 만드는 규칙

main 브랜치에는 직접 커밋을 올리지 않는다. (동시 작업을 하다가 꼬일 수 있으므로)
기능 개발을 하기 전에 main 브랜치를 기준으로 새로운 브랜치를 만든다.
브랜치 이름은 feature/기능이름 형식으로 하고 한 명만 커밋을 올린다.
feature/기능이름 브랜치에서 기능 개발이 끝나면 main 브랜치에 이를 합친다.

🏷️ master, main

: git이 제공하는 기본적인 branch 이름.

첫번째 커밋을 하면 자동으로 main이라는 이름으로 브랜치가 커밋을 가르키고 새로 커밋을 할 때 마다 main 브랜치의 포인터가 최신 커밋을 가리킨다.
ex)위의 그림에서 커밋1, 커밋2까지만 진행되었다면, main branch는 커닛2를 가리킨다.
커밋2에서 새로운 branch A를 만들면 main branch와 동일하게 커밋2를 가리킨다. A branch에서 커밋을 한번 더 하면 A branch가 main branch보다 커밋 하나만큼 앞선다.
ex) main은 커밋2를 가리키고, A는 커밋3을 가르킴
main branch에서 커밋을 하나 더 하면 A branch와 master branch는 갈라지게 됨. head라고 하는 브랜치를 이용해 브랜치 사이를 넘나들 수 있다.
✔️ head branch : 현재 브랜치를 가리키는 포인터, 가장 마지막 커밋을 가리킴

📌 git branch 전략 - git flow

Master (Main)
- Production 에 출시가 가능한 브랜치
Develop
- 개발이 완료 된 최신 브랜치
- 신규 개발된 내역이 처음 합쳐지는 브랜치
Feature
- 각 기능을 개발하는 브랜치
- 기능 개발 단위로 Feature 브랜치가 생성됨
Release
- Develop 브랜치에서 생성됨
- 개발이 완료되어 출시를 위해 준비하는 브랜치
Hotfix
- Production 에 배포 된 버전에서 발생한 버그를 수정하는 브랜치

Git Flow는 명시적으로 버전관리가 필요한 이를 테면, 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크 등의 프로젝트에 적합하다. 웹 어플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하므로 여러 버전을 병렬적으로 지원할 필요가 없다. 또한 웹 어플리케이션은 하루에 몇 번이고 릴리즈될 수 있다. 이런 특성상 웹 어플리케이션 개발에 Git Flow는 다소 적합하지 않다.

📌 git branch 전략 - github flow

개발을 위해 마스터 브랜치에서 개발 브랜치를 생성합니다.
개발자는 지속적으로 개발 브랜치에 코드 변경 사항을 제출합니다.
작업이 완료되면 코드 검토를 위해 풀 요청을 제출하세요.
검토 또는 검증 중에 코드를 마스터 분기에 동기화하거나 새 제출을 생성하여 검토 또는 검증 피드백에 응답합니다.
코드 검토를 통과하고 개발 브랜치가 검증된 후 코드를 마스터 브랜치에 병합합니다.
지속적인 배포를 위해 최신 버전의 프로덕션 환경을 배포합니다.

GitHub Flow는 깃허브를 기반으로 한 간단하고 유연한 개발 워크플로우로 주요 목표는 신속한 배포와 효율적인 협업을 지원하는 것이다. Git Flow와 달리 단일 브랜치를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미이다.

📌 Merge

: 각자의 branch에서 개발이 완료 되면 main branch에 작업물을 합쳐야 한다.

🏷️빨리 감기(Fast-forward)

: main 브랜치에서 menu1 브랜치를 병합하면 커밋 3는 커밋 2를 단순하게 수정한 수정본이므로 두 상태를 합치면 따로 바뀌는 상태 없이 커밋 3이 된다. 커밋 2를 가리키던 master 브랜치가 빨리 감기를 해서 커밋 3를 가리키게 된다.
✅ [menu1] 브랜치의 모든 내용이 [master] 브랜치에 반영 되었으니 [menu1] 브랜치는 삭제 가능하다.

🏷️ 병합 커밋(Merge Commit)

: 커밋 4는 커밋 2를 기준으로 변경 되었기 때문에 커밋 3과 커밋 4는 병합 커밋이 일어난다. 해당 병합을 main 브랜치에 올리거나, menu2 브랜치에 올리는 것 둘 다 가능하지만 master 브랜치에 올린다.

🏷️ 충돌 (Conflict)

: 만약 커밋3과 커밋4가 같은 파일에 다른 수정을 한 경우 어느 쪽을 선택해야 할지 알 수 없어 충돌이 발생한다. 충돌을 피하기 위해서는 작업 디렉토리를 세세하게 분리하여 동일 디렉토리 내부에 작업하는 일이 없도록 하는 것이 좋다. 그럼에도 불구하고 충돌이 발생하는 경우에는 충돌 코드 수정 후 병합해야한다.

📌 Sourcetree

: Git 저장소를 시각적으로 관리할 수 있는 GUI 도구. 직관적으로 수행 가능

🏷️Sourcetree 사용 방법

remote 탭에서 GitHub 계정 추가
폴더에 first.md second.md 생성

🏷️ 로컬 저장소를 불러오기

add 탭에서 탐색 후 원하는 파일 경로 가져오기
history 탭에서 커밋 그래프 확인
create 탭의 역할은 새로운 레포지토리 생성(= git init)

🏷️ sourcetree로 커밋 만들고 push

폴더에 새로운 파일을 생성
sourcetree에서 commit을 눌러 tab 모양으로 바꾼 뒤 add->commit
commit을 원격 저장소에 push
❓ 원격 저장소에 빨간 느낌표가 표시된다면
❗ 설정 -> 경로 -> 편집 -> Remote Account 설정 -> 껏다 켜기

📌 Sourcetree로 branch 실습하기

소스 트리에서 브랜치 아이콘 클릭하여 feature/mypage 새 브랜치 생성하며 체크아웃
파일에서 mypage.md 파일을 생성 후 저장 (내용도 적기, 바뀐내용이 무엇인지 알 수있게)
sourcetree에서 commit
파일에서 first.md에 변화를 줌 (❗충돌 상황 발생시킬 예정 )
sourcetree에서 commit & push( origin/main에 바뀐 내용 즉시 푸시 버튼 클릭)
main으로 checkout (아직 main에는 반영 X)
feature/cart 브랜치 생성 및 체크아웃
cart.md 파일 생성&저장
first.md 수정 (❗feature/mypage 와 동시에 같은 파일을 다르게 수정한다.)
sourcetree에서 수정내용을 commit & push

📌 Sourcetree로 merge 실습하기

🏷️ main 브랜치를 기준으로 feature/mypage 브랜치 병합 : 빨리 감기

main 브랜치로 체크아웃
병합 원하는 커밋에서 마우스 오른쪽 버튼 눌러 병합 선택
빨리 감기가 가능해도 새 커밋으로 생성 체크 하지 않음
병합 후 로컬에서만 2개의 커밋이 이루어졌으므로 원격보다 2개의 커밋을 앞서 있음
main 브랜치를 push하면 원격에도 반영 됨

🏷️ feature/cart 브랜치를 기준으로 main 브랜치 병합 : 병합 커밋 - 충돌

병합 커밋을 만들 경우 충돌 가능성이 있으므로 기능 브랜치를 메인 브랜치에 바로 반영하지 않고 메인 브랜치를 기능 브랜치에 먼저 병합한 뒤 최종 병합을 하는 것이 좋다. (반대의 상황도 가능하지만 가급적 다른 팀원이 불편해 지지 않도록 본인의 작업 영역에서 해결하려는 의도)
feature/cart 브랜치로 체크아웃
병합하려는 main 브랜치의 최신 커밋에서 오른쪽 버튼 클릭 후 병합 선택
충돌 발생 팝업 확인 후 닫기
커밋하지 않은 변경 사항을 누르면 fisrt.md 파일이 스테이지에 올라가지 않은 파일로 존재 (이 파일에서 충돌이 발생했기 때문이며 해당 파일을 고치면 병합을 진행할 수 있음)
VS Code에서 원하는 버전으로 파일을 수정
소스 코드에서 충돌 해결 되었는지 확인 후 add
충돌 발생했다는 자동 영어 메세지가 커밋 메세지에 기록 되어 있음 (커밋 메세지 수정 가능)
Commit & Push
main에 반영 될 수 있도록 main으로 체크아웃
병합을 원하는 커밋 이력 우클릭 후 병합 선택
main push

📌 Pull Request

: 특정 브랜치에서 다른 브랜치로 변경 사항을 병합하도록 요청하는 것이다. 이는 코드 리뷰와 협업을 더욱 효율적으로 만들어준다. Pull Request를 생성하면 팀원들이 변경 사항을 검토하고, 댓글을 남기고, 수정 요청을 할 수 있다. 모든 검토가 완료되면 변경 사항을 병합할 수 있는 권한을 가진 사람이 병합을 진행한다.

feature/comment 브랜치 생성 및 체크아웃
comment.md 생성 & 저장
Commit & Push
GitHub에서 알림 확인
open a pull request(열려있는 풀 리퀘스트를 다른 사람들이 확인하고 검토, 내부에서 토론, 댓글 가능. 리뷰어가 수락하거나 수정 요청하거나 병합할 수도 있음)
Merge
소스트리에서 병합 완료 여부 확인하기 위해 fetch - 모든 원격 저장소에서 가져오기
(pull은 실제 코드를 내려 받지만 fetch는 그래프만 업데이트 한다.)
main 브랜치로 체크아웃 한 뒤 pull을 하면 원격지의 변화가 로컬에도 반영 된다.