[TIL #2] git flow 연습

0. 깃헙에서 new repository 생성 후 git clone 하기

1. git flow 명령을 통해서 시작. 처음 시작 할 때는
git flow init

• init 하면 메시지가 뜨는데 사용자가 보게 될 릴리즈 커밋들이 존재하게 될 브랜치 이름은 [main] 엔터. 따로 이름 지을려면 이름 지으면 되는데 제공되는 이름 사용
• [develop] 엔터
• 프리픽스도 다 엔터, 만약 안 채워져있으면 이름 적으면 됨
• git branch를 치면 develop 브랜치로 자동으로 가있는 것을 확인 할 수 있음.

2. 새 기능(feature) 시작하기!
git flow feature start {기능명}

새 기능의 개발은 ‘develop’ 브랜치에서 시작함.

• 입력하면 feature/{기능명} 이렇게 피쳐 슬래시가 붙게 됨.
• 작업 파일 생성 touch
• vi 로 열어서 for 문을 사용하여 hello를 15번 print 함(예시)

  for _ in range(15):
      print('hello')

• git add
• git commit
  • feat: Create fizzbuzz.py
• 커밋 한번 했으니까 다시 vi 로 열어서 수정 작업을 또 함.

  for i in range(1, 15+1):
  		if i%3==0:
         print('fizz')
      else:
         print(i)

• 수정했으니 다시 git status 체크하고
• git add
• git commit
  • feat: Print fizz if i is times of 3
• 그리고 또다시 vi 로 열어서 수정 작업

for i in range(1, 15+1):
		if i%3==0:
       print('fizz')
    elif i%5==0:
       print('buzz')
    else:
       print(i)

• git status 확인하고
• git add
• git commit
  • feat: Print buzz if i is times of 5

여기까지 작업한 후 릴리즈 까지 해보기

3. 기능 완료(작업 닫기)
git flow feature finish {기능명}

• feature 브랜치에서 작업했던 파일을 develop로 넘길 수 있음
• git status 를 해서 확인.

브랜치 작업 시, status 조회했을 때 불완전한 파일들이 있으면 안됨(커밋 안되는 등) 정리를 해놓고 브랜치를 병합하든지, 삭제하든지 해야함.

feature가 develop 브랜치로 머지 되었고, feature가 local 상에서 삭제되었다, 현재 나는 develop 브랜치에 있을 것이다.

• git branch 해서 보면 feature 브랜치가 사라지고 나는 develop 브랜치에 있는것 확인.

기능 개발을 시작하고 끝내는 한사이클을 git flow feature start , git flow feature finish로 해본 것임

4. 릴리즈 스타트
git flow release start {버전 네이밍}

위 과정처럼 피쳐 브랜치를 열고 닫고 하면서 기능 개발이 이루어졌다고 가정하고, 기능을 릴리즈 하겠다고 생각이 들때 릴리즈 스타트 하는 명령

• 버전 네이밍
  • 릴리즈 할때는 버전 네이밍이 중요함 버전을 뛰어넘거나 잘못 선택하면 안 됨.
  • 수정 범위가 크다, 작다로 버전 네이밍을 바꿀 수 있음
  • v.0.0.0 보통 네이밍은 버전을 세 자리로 둠 Major, Minor, Patch

• git flow release start v0.0.1 이라고 입력 후, develop 브랜치에서 릴리즈 브랜치를 시작하게 되면.
• 근데 과정 안에서 릴리즈 할 일은 없을 것임..많은 테스트가 일어나긴 하지만.. 바로 닫아준다.

5. 릴리즈 피니시
git flow release finish {버전 네이밍}

git flow release finish v0.0.1

• 그럼 총 세 번의 vi 창이 뜸(어떤 OS는 두번 뜨기도 함)

  • 첫 번째, vi창은 main 브랜치에 들어가는 것. merge commit 이 뜸 ‘into main’
    • merge commit은 많이 쓸필요 없음 입력 안하고 바로 저장하고 나가도 괜찮음
  • 두 번째,이 merge commit 에 대한 label이 뜰 텐데 이것을 release note 라고 함. 해당 버전에서 어떠한 일이 일어났는지 노트를 쓰는게 이 부분임. ‘Write a message for tag’ 태그는 사용자가 쓰게 될 버전에 대한. 버전, 커밋에 대한 설명 즉 라벨임. 간단하게 작성함.

    **implement fizz, buzz**
    
    Print fizz if i is times of 3
    Print fizz if i is times of 5
    otherwise, print i itself.

  • 세 번째, 똑같은 버전의 코드를 develop에 넣어주는 마지막 merge commit
    • merge commit은 그냥 저장하고 나감
  
  

• 이제 git branch 하면 release 브랜치 없어지고, main과 develop만 있을 것

6. push 하기 (develop, main, tag)

git push -u origin develop

git push origin main

git push --tags

릴리즈의 끝, Push 하기

• develop에서도 한번 push, main에서도 한번 push, 버전 tag도 push 함.
• 현재 깃헙에서 작업하고 있는 레퍼지토리를 확인하면 브랜치가 main 밖에 없을 것임.
• local에서 처음생긴 develop이라는 브랜치를 push 할 것인데 그냥 push하면 안되고 -u (upstream push) 해야 함. 프로젝트 당 첫 develop 브랜치에서 한번만 하면 됨
• git push -u origin develop remote 상의 develop 브랜치는 처음 만드는 거니까, upstream set 한다. 즉, local develop이랑, remote develop 이랑 같은 것이라고 알려주는 것.
  
• git switch main 해서 메인으로 이동하고, git push origin main 해서 main도 push 해줌.
• tag 도 push 해줌 git tag 해서 태그 확인 하고 git push --tags
  • 어떤 특정 커밋에다가 라벨링하고 싶을때 (특정한 설명 부가 하고 싶을 때)
  • 태그는 특정 커밋에 종속되는데 주로 main commit 임.

이 것이 한 싸이클.

다른 기능들은 또 develop 브랜치 에서 기능 개발을 하고 개발 작업물이 쌓이면 또 릴리즈 하고 메인으로 넣어주고. 이 절차대로 계속 진행하게 됨

🤨 회고
확실히 한 싸이클을 경험해보니 git flow 전략을 이해하기 수월했다. 협업 프로젝트 시에도 유용하게 사용할수 있을 것 같다.