프로젝트 workflow

Jelkov Ahn·2022년 1월 4일
0

GIT

목록 보기
7/7
post-thumbnail

각 브랜치 설명정리

master/main
항상 최신의 안정적인 프로그램
dev
베타버전/ 모든 개발 로그들이 쌓이는곳, 새로운 feature기능들이 완성되고 머지 되는곳
feature
기능을 추가할때마다 따는 브랜치
test
테스트용
hotfix
급한 수정을 할때 !!
release
배포할때 쓰는 테스트용 브랜치

브랜치 명령어 모음

새로운 브랜치 생성 :
$ git branch 새로운 브랜치 이름

새로운 브랜치 생성후 해당 브랜치로 전환 :
$ git switch -c 새로운 브랜치 이름 /$ git checkout -b 새로운 브랜치 이름

브랜치 목록 확인 :
$ git branch

브랜치 목록과 각 브랜치의 최근 커밋 확인 :
$ git branch -v

브랜치 삭제 :
$ git branch -d 삭제할 브랜치 이름
$ git branch -D 해당 명령어는 병합하지 않은 브랜치를 강제 삭제하는 방법입니다.

브랜치 전환:
$ git switch 브랜치 이름
$ git checkout 브랜치 이름

브랜치 병합 (master 브랜치로 dev 브랜치를 병합할 때 (master ← dev)):
1. $ git checkout master
2. $ git merge dev

로그에 모든 브랜치를 그래프로 표현

$ git log --branches --graph --decorate

아직 commit 하지 않은 작업을 스택에 임시로 저장

$ git stash

원하는 커밋만 가지고 오고 싶을때

$ git cherry-pick 42315f0 (로그 7자리만 가져온다.)

프로젝트 work flow

(1) Fork,Clone
Origin으로 fork 하고 Local로 Clone 하기
Remote : Repository --fork--> Origin : Repository --Clone--> Local : Repository

(2) git checkout-b 새로운 브랜치 이름 / Git switch -c 새로운 브랜치 이름
git checkout-b dev or git switch -c dev : dev 브랜치를 생성한고 dev 브랜치로 이동한다.

Repository에도 생성한 브런치를 반영하기 위해서는 git push origin dev 명령어를 입력해야 한다.


** Head는 현재 작업중인 커밋

(3) git branch
브랜치가 잘 생성 되었는지 확인 하기 위해서는, git branch를 사용해야 한다.
생성한 브랜치 목록과 내가 현재 있는 브랜치를 확인 할수 있다.

(4) 브랜치를 만들기
feature/기능이름 이라는 브랜치를 만들어서 작업하기
git checkout -b feature/login or git switch -c feature/login 브랜치를 생성하고 브랜치로 이동

(5) 브랜치에서 파생된 브랜치 만들기
로그인 코드를 건드리지 않고 새로운 브랜치(소셜로그인 -oauth)를 하나 더 만들어서 작업을 할때!
git checkout -b feature/login-oauth or git switch -c feature/login-oauth 브랜치를 생성하고 브랜치로 이동

(6) 소셜로그인 브랜치에서 만든 코드를 로그인 브랜치로 병합하기
merge하기 위해서는 먼저 병합이 될 브랜치로 이동하기
git checkout feature/login or git switch feature/login

(7) git merge feature/login-oauth 명령어
머지되기 전에 추가적인 커밋이 없으므로 , 브랜치가 분기될 필요가 없다.
그러므로 자동으로 fast-forward방식으로 병합이 된다.
** fast-forward 방식: 별도의 커밋을 생성하지 않고 feature/login 브랜치가 가리키는 커밋을 feature/login-oauth가 생성한 커밋으로 바꾸는 작업

(7-1) merge vs rebase?
rebase의 원리는 fast-forward와도 같습니다.

merge
변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해 집니다.

rebase
말 그대로 branch base를 이동시킨다는 뜻으로, 머지처럼 브랜치 통합을 목적으로 하지만,
특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능을 합니다.

feature/login 브랜치에서 git rebase main feature/login 명령어를 입력하면 main의 가장 최신 커밋으로 브랜치가 가리키는 곳이 변경됩니다. (main의 다른 커밋에서 충돌이 없을 경우)

만약에 정확하게 모든 커밋 이력들을 남겨야 한다면 rebase는 쓰면 안된다.

(8) Local에서 작업한 내용을 Remote Repository로 업로드
git push origin feature/login

(9) Pull request : 내가 push한 변경 사항에 대해서 다른 사람들에게 알리는 것!!

dev브랜치에 반영 요청을 함
팀원들과 코드에 대해서 리뷰를 한후에 dev브랜치로 merge 할수 있다.


소개 내용과 / Create pull request 버튼을 눌러준다.

전체 흐름 workflow


Local에서 새로운 브랜치를 생성하고 작업이 끝나면 Remote Repository 로 Push 합니다.
그리고 Project Upstream Repository에 반영(merge)될 수 있도록 Pull Request 합니다.

** 만약 작업하던 중간에 Remote upstream 에 업데이트가 생긴다면 Local 로 pull 받아주어야 합니다.

profile
끝까지 ... 가면 된다.

0개의 댓글