Git WorkFlow

김승혁·2023년 7월 31일

Git

목록 보기

1/1

git의 가장 큰 장점은 편안히 마음껏 시도하고 바꿔볼 수 있다는 것

GitFlow Workflow – 혼자 쓸 때

commit – 새로운 node를 생성 (백업, 저장) [id] f9e53dc41490ce61b95c9be868088c07be5cdc8b
branch – 병렬적이고 독자적인 코드 수정 이력
head – 현재 작업하고 있는 위치 chechout – 다른 커밋으로 이동
push – sever(origin)에 내 branch를 업로드 pull – serve에서 다른 gitflow를 내려받아 업데이트

GitFlow Workflow – 혼자서 여러 기능을 구현해야 할 때

GitFlow Workflow – 여러 사람이 협업할 때

conflict – merge시 변경사항이 클 경우 자동으로 적용하지 못하고 error를 발생
cherry pick – 다른 커밋의 내용을 현재 위치로 가져옴
soft/mixed/hard reset – 해당 브랜치의 내용 혹은 branch tag만 가져옴

Rebase의 효과

각 커밋과 브랜치는 하나의 의미를 담는 것이 좋다.
그러나 개발이 언제나 순차적이고 매끄럽게 되지는 않는다.
이런 경우 rebase를 통해 차후 재수정할 수 있다.

참고:https://techblog.woowahan.com/2553/

GitFlow Workflow – 안정적인 소프트웨어(상품)를 외부에 배포해야 할 때

documentation – 주석 혹은 readme
code test (QA)

GitFlow Workflow – 최종 모습

hotfix는 따로 branch를 만들지 않고 바로 master에서 수정하기도 함
개발은 자유롭게, 관리는 엄격하게

참고:https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Rdkit

Rdkit git history

Rdkit 최근

git-flow를 힘들게하는 여러가지

conflict

TIP: 최신 브랜치에서 시작한 다음, master에 다른 사람이 수정하기 전에 빨리 merge한다.

code formating

저장 할 때 자동으로 코드 변환
포맷을 바꿔야 할 땐 “nit” commit을 따로 올리기

code testing

test code란?

test code workflow
1. 새로운 알고리즘(함수, 기능)을 추가한다.
2. 기존 unit test을 실행한다.
3. 새로운 알고리즘 추가의 이유가 되었던 test data를 추가한다.

전문가의 방법 – “우아한 형제들”의 예

작업을 할 때 지켜야할 서로 간의 약속.
1.작업을 시작하기 전에 JIRA 티켓을 생성합니다.
2.하나의 티켓은 되도록 하나의 커밋으로 합니다.
3.커밋 그래프는 최대한 단순하게 가져갑니다.
4.서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않습니다.
5.리뷰어에게 꼭 리뷰를 받습니다.
6.자신의 Pull Request는 스스로 merge 합니다.

Git-flow를 이렇게 하고 있어요.

1.upstream/feature-user 브랜치에서 작업 브랜치(bfm-100_login_layout)를 생성합니다.
2.작업 브랜치에서 소스코드를 수정합니다. (뚝딱뚝딱)
3.작업 브랜치에서 변경사항을 커밋합니다. git commit -m “BFM-100 로그인 화면 레이아웃 생성”
4.만약 커밋이 불필요하게 어려 개로 나뉘어져 있다면 squash를 합니다. git rebase -i HEAD~2
5.작업 브랜치를 upstream/feature-user에 rebase합니다. git pull --rebase upstream feature-user
6.작업 브랜치를 origin에 push합니다. git push origin bfm-100_login_layout
7.Github에서 bfm-100_login_layout 브랜치를 feature-user에 merge하는 Pull Request를 생성합니다.
8.같은 feature를 개발하는 동료에게 리뷰 승인을 받은 후 자신의 Pull Request를 merge합니다.
만약 혼자 feature를 개발한다면 1~2명의 동료에게 리뷰 승인을 받은 후 Pull Request를 merge합니다.

참고: https://techblog.woowahan.com/2553/