ram2 🚗

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

개발을 할 때, 추가된 기능이나 수정사항이 서로 영향을 주지 않고, 독립적으로 동시에 진행할 수 있도록 한다. 또한, 각 브랜치가 특정 작업을 진행하고, 필요한 경우 해당 작업 단위의 Rollback이 가능하기에 프로젝트 관리의 유연성을 향상시킬 수 있다.

이러한 전략은 원하는 버전 단위로 관리할 수 있도록 하여 프로젝트의 관리와 배포의 안정성을 높여준다.
Branch 전략은 다음과 같은 3가지가 있다.
1️⃣ Git flow
2️⃣ Github Flow
3️⃣ Gitlab flow

1️⃣ Git flow

브랜치 종류

1. master: 제품 출시 버전을 관리하는 메인 브랜치
2. develop: 다음 출시 버전을 위해 개발하는 브랜치
3. feature: 새로운 기능을 개발하는 브랜치
4. release: 다음 출시 버전을 준비하는 브랜치
5. hotfix: 출시된 제품의 버그를 고치기 위한 브랜치

Git Flow를 활용한 개발 진행 흐름

1. 신규 기능 개발은 develop 브랜치를 기준으로 한 feature 브랜치를 따서 작업
2. 작업이 완료된 feature 브랜치는 develop 브랜치로 병합.
   • PR을 통해 리뷰 후 병합하는 방식
3. 배포를 위한 준비는 다음 출시 버전을 위해 개발중인 develop 브랜치에서 release 브랜치를 따서 한다.
   • 만약, 해당 과정에서 버그가 발견된다면, release 브랜치에서 바로 반영
4. 테스트 후, 일정 주기로 master 브랜치로 병합하여 제품 출시
5. 배포 이후, release 브랜치에서 발견되지 못한 새로운 버그는 main 브랜치에서 hotfix 브랜치를 판 후, hotfix 브랜치에서 바로 고친 후 main으로 병합
6. hotfix 브랜치에서 고치고, main 브랜치에 병합 되었다면, 이를 develop 브랜치에도 병합

특징

• release와 hotfix 브랜치를 통해 명확한 배포 절차를 갖추고 있다.
• 다양한 종류의 브랜치를 사용한다.
• 복잡한 프로젝트나 대규모 팀에서 사용하기 적합하다.
• 복잡성과 Control을 가지고 있어 특정 기능이나 수정을 빠르게 배포해야 할 경우 등에서 유연성이 떨어짐.

2️⃣ Github Flow

브랜치 종류

• master : base가 되는 브랜치
• feature : master에 기능을 추가하기 위한 새로운 브랜치

Github Flow를 활용한 개발 진행 흐름

1. master 브랜치는 배포를 위한 소스코드를 관리하는 브랜치.
2. 만약, 신규 기능 개발이 필요하다면, master 브랜치로부터 feature 브랜치로 새로 따서 작업을 진행한다.
3. Task가 완료되면, Pull Request를 생성하여 Review를 요청하고, PR은 feature → master 브랜치이다.
4. 리뷰 완료 후, 피드백이 모두 반영되었다면, 해당 feature 브랜치를 master 브랜치로 병합한다.

특징

• 단순하며 지속적인 배포를 강조하며, master 브랜치에서 배포를 수행한다.
• 단순하며 빠른 개발 및 배포를 위해 사용된다.
• 테스트와 검증 절차를 거치지 않고 바로 master 브랜치로 Merge 되므로 위험성이 있다.

3️⃣ Gitlab flow

복잡한 Git Flow와 너무 간단한 Github Flow의 절충안

브랜치 종류

• master : 안정적인 코드가 저장되는 브랜치로 base가 되는 브랜치.
  • 전체적인 테스트 진행이 완료되어 기능에 대한 보장이 있다면, production 브랜치로 머지.
  • 만약 staging 단계가 필요하다면, pre-production 브랜치로 머지.
• feature : 각 기능이 개발되는 브랜치.
  • master 브랜치에서 파생되고 PR을 통해 다시 병합된다.
• Production : 테스트가 끝난 기능의 배포를 위한 브랜치
• Pre-Production : 배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치
  • 테스트가 정상적으로 완료되면, production 과 master 에 각각 PR(Pull Request)을 보낸다.

Gitlab Flow를 활용한 개발 진행 흐름

• 기능 개발이 필요한 경우, master 브랜치에서 feature 브랜치를 생성한다.
• feature 브랜치에서 기능 개발 완료 후, PR을 통해
  • 기능에 대한 검증 및 보장이 있다면 production 브랜치로 머지한다.
  • 기능에 대한 검증 및 보장이 필요하다면, pre-production 브랜치로 머지한다.
• pre-production 브랜치에서 테스트가 완료 되었다면, production과 master에 PR을 통해 병합한다.

특징

• 간단하고 직관적인 플로우를 제공하여 개발 프로세스를 이해하기 쉽게 만든다.
• GitLab은 내장된 CI/CD 파이프라인을 제공하므로 빌드, 테스트, 배포 등을 자동화할 수 있다.
  • 이를 통해 안정적인 배포와 빠른 피드백을 얻을 수 있습니다.
• 비교적 간단한 프로세스를 제공하기 때문에, 대규모 프로젝트에서는 협업과 관리가 어려울 수 있다.
• 특히 지속적인 배포가 강조되는 환경에서 효과적이다.

🚨 error

오랜만에 코드를 github에 올리려고 커밋을 했더니 이런 오류가 떴다.

 ! [remote rejected] master -> master (pre-receive hook declined)

remote: error: GH001: Large files detected. 
You may want to try Git Large File Storage - https://git-lfs.github.com.

내게 있어 꽤나 중요한 작업이었는데, 몇 번을 시도해도 에러는 해결되지 않았다.

🚨 가장 큰 이유는 assets파일에 비디오가 하나 있어 용량이 너무 컸기 때문에 올라가지 않았다. 

그래서, lib 폴더만 커밋하고자 했으나, 이것 또한 되지 않았다. 

이전 커밋 기록이 남아있어서 계속 같은 이유로 push가 실패했던 것이다.

🗝  SOLUSION

이때 두 가지 방법이 있다.

💻  첫 번째는 강제로 push를 하는 방법이다.

$ git push origin master -f

하지만 나같은 경우 강제 push도 되지 않았다...🥹

💻  만약 강제 push도 안되는 경우, history를 삭제하고 다시 하면 된다.

$ rm -rf .git

터미널에 위 명령어를 입력하면 이전 커밋 history를 삭제할 수 있다.

이렇게 history를 삭제하고 다시 git을 초기화하니 문제 없이 commit, push가 이루어짐을 확인할 수 있다 !!

git checkout을 하려고 했으나 이런 에러가 떠서 아무것도 하지 못하는 상황이 되었다. 

현재 vscode를 사용 중인데, 폴더 옆에 ! 이런 표시가 생겼다. 아무리 에러를 찾아보아도 에러는 보이지 않고, 빌드가 되지 않았다.

그래서 일단 git status 명령어를 사용하여 어디에서 어떤 에러가 발생했는지 확인해 보았다.

$git status

그 결과 이런 결과를 얻을 수 있었다.

아무래도 수정한 것을 제대로 저장 또는 push 하지 않은 상태에서 merge를 해서 발생한 문제인 것 같다.

이렇게 git status를 통해 에러가 난 부분을 확인할 수 있었다.

그래서 에러에 나온대로 각 파일을 하나씩 git add하여 수정된 것을 저장하였다.

잘 보일지 모르겠으나, 기존에 home.dart 파일이 문제가 있었는데, add를 하고 git status를 실행한 결과 해당 파일이 사라진 것을 확인할 수 있다.

git add {commit이 필요한 파일 경로}

(ex. $git add lib/screen/home.dart)

이렇게 git status를 통해 add가 필요한 파일을 찾고 git add를 해주었다.

문제가 되는 파일을 모두 해결하고 난 뒤 git checkout을 했더니 드디어 됐다.

git error가 발생한 경우에는 먼저 git status를 통해 꼭 먼저 확인해보는 습관을 가져야겠다.