FE가 되고싶니? 나도✨

여러 개발자가 하나의 저장소에 작업을 할 때, 협업을 좀 더 효과적으로 하기 위해 git branch 에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow 를 정의하는 것을 바로 git branch 전략이라고 한다.

그 중에서도 대표 브랜치 전략인 flow에 대해서 알아보자.

Git Flow는 소프트웨어 개발에서 Git을 사용하여 브랜치를 관리하는 대표전략 중 하나로, 팀의 협업을 효율적으로 지원한다. 이 전략은 명확한 브랜치 구조를 제공하여 개발, 배포, 유지보수를 체계적으로 관리할 수 있게 해준다. 

브랜치 종류

특징 및 장점

1. 명확한 브랜치 구조: 각 브랜치의 용도와 역할이 명확하게 정의되어 있어 협업이 용이
2. 효율적인 작업 관리: 기능 개발, 버그 수정, 배포 준비 등의 작업이 체계적으로 관리된다.
3. 릴리즈 준비 과정의 독립성: 릴리즈 준비와 기능 개발이 독립적으로 진행될 수 있어, 안정성을 높인다.
4. 버전 관리 용이: 각 릴리즈 버전이 명확하게 관리되어, 이전 버전으로의 롤백이 쉬워진다.

*릴리즈(Release) : 특정 버전의 소프트웨어를 공식적으로 배포하거나 공개하는 과정
*롤백(Rollback) : 특정 변경 사항이나 상태를 이전 버전으로 되돌리는 과정

단점

1. 복잡성: 브랜치가 많아질수록 관리가 복잡해 작은 팀이나 간단한 프로젝트에는 과도할 수 있다.
2. Git Flow의 개념을 이해하고 적용하는 데 시간이 필요다.

+여담, 또 다른 대표 브랜치 전략

GitHub Flow는 Git Flow보다 훨씬 단순하며, 빠른 배포와 지속적인 통합(CI/CD)에 초점을 맞춘 브랜치 전략이다. 이 전략은 'master' 브랜치 하나와 기능별 'feature' 브랜치를 사용하는 것이 전부다. 왜냐하면 GitHub Flow는 코드 변경 사항을 빠르게 배포하고, 팀원 간의 협업을 간소화하기 위해 설계되었기 때문

특빠른 반복 개발과 배포가 필요한 스타트업이나 소규모 팀에 적합하고, 간단한 구조 덕분에 새로운 팀원도 빠르게 적응할 수 있으며, 배포 과정의 단순화로 인해 개발에 더 집중할 수 있다.

브랜치(branch)란 무엇인가?

프로그램 소스 버전을 관리하기 위한 개념으로, 간단히 말하면 복사본이다. "Branch"라는 이름 그대로, 원본에서 가지치기해서 복사한 소스를 가지고 별도의 버전을 새로 생성하는 것.

그렇다면 머지(merge)는 뭐지?

현재 branch를 다른 branch와 병합하는 과정.

머지(merge)하는 방법

Fast-Forward merge

git merge 명령어를 사용해 브랜치를 병합할 때, 현재 브랜치가 병합할 브랜치의 직계 조상일 경우에 사용하고, 커밋 히스토리가 직선 형태로 유지되는 특징이 있다.

$ git checkout main
$ git merge feature

예를 들어, main branch에서 feature branch를 병합할 때 feature branch에서 새로운 커밋이 추가되지 않았다면 단순히 포인터를 이동한다.

✅장점

• 히스토리가 깔끔하고 이해하기 쉽다.
• 커밋 기록이 단순해서 추적이 용이하다.

⛔단점

• 여러 개발자가 동시에 작업하면서 머지(merge, 병합)을 자주할 경우 히스토리가 단조로워질 수 있다.

Three-Way Merge

두 브랜치가 서로 다른 커밋을 가진 경우, git은 세 개의 커밋을 비교하여 병합한다. (공통 조상, 현재 브랜치의 최신 커밋, 병합할 브래치의 최신커밋)

기본적으로 git이 자동으로 충돌을 해결하고, 충돌이 발생할 경우 수동으로 해결해야 한다는 특징이 있다.

✅장점

• 두 브랜치의 변경사항을 모두 반영할 수 있어, 기능이나 버그 수정이 잘 통합된다.
• 여러 개발자들이 작업한 내용을 쉽게 병합할 수 있다.

⛔단점

• 충돌이 발생할 경우, 수동으로 해결해야 하므로 추가적인 작업이 필요하다.
• 히스토리가 복잡해질 수 있다.

Squash Merge

여러 커밋을 하나의 커밋으로 합치는 방식, 주로 기능 개발이 완료된 후, 커밋 기록을 정리하고 싶을 때 사용한다.

$ git checkout main
$ git merge --squash feature
$ git commit -m "Feature implemented"

feature 브랜치의 모든 커밋이 하나의 커밋으로 압축되어 main 브랜치에 추가된다.

✅장점

• 히스토리가 깔끔하게 유지되고 기능단위로 커밋을 정리 할 수 있다.
• 필요없는 중간 커밋 제거 가능, 프로젝트 이력이 더 명확해진다.

⛔단점

• 원래의 커밋 히스토리를 잃게 되어 문제가 발생했을 때 원인을 추적하기 어려울 수 있다.
• 협업시 각 개발자의 작업 내용을 상세히 기록하지 않기 때문에 나중에 코드 리뷰가 어려워질 수 있다.

Rebase Merge

한 브랜치의 커밋을 다른 브랜치의 끝으로 이동시키는 과정이다. 주로 기능 브랜치를 메인 브랜치의 최신 상태로 업데이트할 때 사용한다.

$ git checkout feature
$ git rebase main

feature 브랜치의 커밋이 main 브랜치의 최신 커밋 뒤로 이동한다. 이 과정에서 충돌이 발생할 수 있으며, 충돌을 해결한 후 진행해야 한다.

✅장점

• 커밋 이력이 선형으로 유지, 이력 추적에 용이하다.
• 협업시 최신 변경 사항을 쉽게 반영할 수 있다.

⛔단점

• 이미 원격에 푸시된 커밋을 리베이스 할 경우 다른 개발자와 충돌이 발생될 수 있다. 원격에 푸시하기 전 주의!
• 복잡한 커밋 히스토리를 가진 경우에는 충돌 해결이 번거로울 수 있다.

‼️결론

상황에 따라 적절한 방법을 이용해 사용하면 될 듯 하다.

Fast-Forward Merge는 간단한 경우에 유용하고, Three-Way Merge는 복잡한 상황에서 강하며, Squash Merge는 히스토리를 정리하고 싶을 때 유용하고, Rebase는 커밋 이력을 선형으로 유지하며 최신 변경 사항을 반영할 때 사용한다.

HEAD : 어떤 커밋 하나를 가리킴

branch : 하나의 코드 관리 흐름

사실 branch도 HEAD처럼 어떤 커밋 하나를 가리키는 존재이다. (이것을 포인터라고 부른다.)

git에서 커밋은 이전 커밋에 대한 정보를 가지고 있다.

그래서 master(혹은 main) 포인터가 가장 최신의 커밋만 가리키고 있다고 해도 그 이전 커밋으로 하나씩 거슬러 올라갈 수 있기 때문에 어떻게 프로젝트가 변해왔는지 추적할 수 있다.

그래서 branch가 어떤 코드의 관리 흐름이라는 개념이 성립되는 것이다.

HEAD 역시 어떤 커밋을 가리키는 존재로 포인터이다.  HEAD가 가리키는 커밋의 내용대로 워킹 디렉토리의 내용물이 바뀐다. 하지만 정확하게 말하자면 HEAD는 커밋을 직접적으로 가리키지 않는다. HEAD는 branch를 가리킬 뿐이다.

프리미엄이라는 브랜치를 새로 만들고 git checkout premium으로 HEAD를 premium으로 맞춰줬다. 이 상태에서 다른 커밋을 만들면

HEAD가 가리키던 프리미엄 브랜치가 새로운 커밋을 가리킨다. 이 상태에서 마스터 브랜치로 체크아웃하면 HEAD는 다시 master로 이동한다.

그럼 HEAD 입장에선 다섯번째 커밋을 가리키는것이고 다섯번째 커밋의 내용대로 워킹 디렉토리 내용도 변하게 된다.

이렇게 쭉 커밋을 하다가 프리미엄 브랜치와 마스터 브랜치를 머지하게 되면 새로운 커밋을 만들어주는데 이 때 커밋을 머지 커밋이라고 한다.

** 커밋 아이디는 앞에 4자리 까지만 입력해줘도 괜찮다.
** HEAD  : 어떤 커밋 하나를 가리킨다. 보통 가장 최근에 한 커밋을 가리키고, 매번 더 새로운 커밋을 가리킨다.
** working directory는 HEAD가 가리키는 커밋에 다라 다르게 구성된다.
** HEAD가 최신 커밋보다 더 이전의 커밋을 가리키면 working directory의 내부도 과거 커밋의 모습대로 바뀌게 된다.
**staging area에 있던 것들은 커밋을 하더라도 그것과 상관없이 계속 남아있다.
** --hard 옵션은 별로 권장되진 않는다. 커밋 이후 워킹 디렉토리에서 했던 내용들이 다 사라지고 복구를 할 수 없기 때문이다.

커밋(commit)은 Git에서 가장 핵심적인 개념이다. 커밋은 staging area의 현 상태를 그대로 하나의 버전으로 남기는 작업, 또는 그 결과물을 가리킨다.

커밋에는 크게 다음과 같은 3가지 정보가 있다.

(1) 커밋을 한 사용자 아이디
(2) 커밋한 날짜, 시간
(3) 커밋 메시지

특정 프로젝트 디렉토리가 어떻게 변해왔는지를 한 눈에 잘 파악하기 위해서는 커밋의 이런 정보들이 아주 중요하다. 그런데 (1), (2)는 커밋을 할 때 Git에서 자동으로 기록해주지만, (3) 커밋 메시지는 커밋을 하는 사람이 매번 직접 작성하는 것이기 때문에 사람마다 그 분량이나 스타일이 제각각일 수 있다.

개인 프로젝트의 경우에는 커밋 메시지를 어떻게 작성하든 큰 상관이 없을 수 있지만, 회사에서 여러 명이 참여하는 프로젝트의 경우에는 이 커밋 메시지가 아주 중요하다. 그래서 커밋 메시지를 어떻게 작성해야하는지에 대한 규칙이 정해져있는 경우가 많은데,
그 규칙들은 회사마다 전부 다르다. 그래서 커밋 메시지를 어떻게 작성하면 좋은지에 대한 일반적인 가이드라인이 있다.

1. 커밋 메시지 작성 가이드 라인

• 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두기. (git에서 공식적으로 권장하는 사항)
• 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 말자.
• 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성해라.
• 커밋 메시지의 제목은 명령조로 작성해라.(Fix it / Fixed it / Fixes it)
• 커밋의 상세 내용에는 [①왜 커밋을 했는지 ②어떤 문제가 있었는지 ③적용한 해결책이 어떤 효과를 가져오는지] 를 적으면 좋다.
• 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 적어라.

2. 커밋할 때 알아야할 가이드라인

(1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 한다.

다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽다. 이 말은 결국 최대한 작은 단위의 변화를 기준으로 커밋을 하라는 뜻이다.
어느 정도의 수정사항을 하나의 단위로 볼 것인지는 상황에 따라 조금씩 다를 수 있고, 회사의 규칙에 따라 다를 수도 있다. 어찌 됐든 너무 많은 작업의 결과를 하나의 커밋으로 담지 않아야겠다는 생각을 하면서 커밋을 해야한다.

(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하자. 

커밋으로 보관된 특정 시점의 전체 코드는 항상 문제없이 실행되는 상태여야 한다. 이미 과거의 커밋이 되어버렸다고 우리에게 쓸모없는 커밋이 되는 건 절대 아니기 때문에 과거의 커밋이라도 ①과거 버전의 프로그램을 사용해야하거나 ②과거 커밋을 시작점으로 한 다른 방향의 별도 프로젝트를 시작하거나 ③아예 그 커밋으로 현재 프로젝트를 리셋할 수도 있다.

따라서 매 커밋의 코드들은 항상 정상 실행되는 상태의 코드여야 한다. 그렇지 않으면 나중에 그 커밋을 위와 같은 용도로 사용하려고 할 때 문제가 생길 수 있다. 그리고 협업하는 상황을 생각해봐도 내가 남긴 커밋을 동료 개발자가 실행해봤는데 에러가 나고 실행이 되지 않는다면 좀 민망할 수 있다. 그래서 커밋을 하기 전에 프로그램이 정상 실행되는지 점검하고 커밋하는 것이 좋다.

혹시 가이드라인이 없다고 할지라도 나중에 다시 봤을 때 이해하는데 어려움이 없도록, 다른 동료 개발자와 협업하는 데 방해가 되지 않도록 커밋을 남기고, 그때마다 커밋 메시지를 잘 작성하는 것이 중요하다.

$ git push
$ git pull

로컬 레포지토리와 똑같은 내용의 리모트 레포지토리를 사용하는 이유?

1. 안전성

• 개인 컴퓨터를 분실하거나 문제가 생겼을 때 복원 할 방법이 없다.
• 이 때 리모트 레포지토리의 내용을 다른 컴퓨터에서 가져오기만 하면 작성하던 내용을 다시 사용할 수 있다.

2. 협업 가능

• 리모트 레포지토리를 가운데 두고 push와 pull을 이용해 새로운 커밋을 계속 만들어 낼 수 있어 여러 개발자와 협업이 가능해진다.

원칙적으로는 자신의 리모트 레포지토리는 자신만 git push를 할 수 있는데 만약 다른 사용자도 git push를 할 수 있게 해주려면 그 사용자를 해당 리모트 레포지토리의 collaborator로 지정해야한다.

git push -u origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용
git push : 로컬 레포지토리의 내용을 리모트 레포지토리에 보내기
git pull : 리모트 레포지토리의 내용을 로컬 레포지토리로 가져오기
git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기

staged 상태

파일의 내용이 수정되고 나서 staging area에 올라와 있는 상태. (스테이징 된. stage area에 올려진)

• 새로 생성한 파일에 내용을 쓰고 git add를 해줌
• 한 번이라도 커밋에 포함 됐었던 파일이라도 내용을 수정하고 git add를 해줌

Unmodified 상태

현재 파일의 내용이 최신 커밋의 모습과 비교했을 때 바뀐게 전혀 없는 상태. (수정되지 않은, 변한게 없는) 커밋을 한 직후에 working directory 안에 모든 파일들의 이 상태이다.

Modified 상태

최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태면 그 파일은 modified(수정된) 상태이다.

• Add the file : untracked 상태의 파일을 처음으로 git add 해주면 staged 상태가 된다.
• Edit the file : 최신 커밋과 비교했을 때 차이가 없는 Unmodified 상태의 파일 내용을 수정하면 Modified 상태가 된다.
• Stage the file : Modified 상태의 파일을 git add 해주면 staged 상태가 된다.
• Remove the file : 파일을 삭제하면 당연히 git에서 더 이상 인식하지 못한다.
• Commit : 커밋을 하면 staging area에 있던 파일들이 커밋에 반영되고, 모든 파일들은 최신 커밋과 차이가 없게 되니 Unmodified 상태가 된다.

+여담

• git help
• man git-

위의 커맨드들을 사용하면 커맨드의 사용법(공식 매뉴얼)에 대해서 알 수 있다. 공식 매뉴얼 화면에서 나갈 땐 q 를 눌러 나갈 수 있다.

$ git help add
$ man git-add