도움 되는 사이트
git flow 의 목적
체계적인 분업
작업 하면서 변경 사항 추적
배포(main) 버전[release]과 패치노트 작성
개발 버전( develop) 의 등 명시적인 구조 표현이 가능한
동시 작업 형상 관리 프로세스
git flow 세팅하기 전 흐름 이해
git flow는
main branch는 배포(공식 공개) 버전으로 주로 사용됨
develop branch는 개발하면서 공유 될 수 있는 버전
feature {작업명}
개인이 관리.. 또는 임시로 사용하는 repo
필요할 때 분기로 만들거나 삭제
시작하기
git flow init
- git flow init
선택된 폴더에 git flow 세팅함
git 없어도 되긴 한다
- 이름이 [master] 로 되는 것이 단점…( git init 도 master )
default 를 [main] 으로 쓰고 싶으면 github 에서 만든 다음 clone 하는게 가장 간단하다
clone 한 게 아닐 경우 origin 설정해줘야한다
branch 이름은 기본값을 사용함
git flow feature start {작업명}
dev branch에서 git flow feature start {작업명} 을 해서
가상의 feature/{작업명} branch를 만든다
일반적으로 수행하는 git commit 과정을 거치면 된다
이름이 작업명이기 때문에, 작업 단위 , 이슈 단위로 작업하면 좋고
develop branch 에서 새로운 feature 를 만드는 건
자유롭기 때문에 만들고 싶은대로 만들면 된다 ( 어짜피 rocal repo )
하지만 팀 단위 작업이고 dev가 업데이트 되는 것들을 고려한다면
feature 브런치를 오래 열고 있는 것은 좋지 않다
git flow feature finish {작업명}
작업이 끝난 branch 는 dev로 merge 된다
말 그대로 merge 기 때문에 dev가 수정됬으면 merge 병합을 하게 됨
없으면 그대로 자동 merge 된다
organizations 에서 작업할 경우
우선 organizations 목적은 repo 의 공동 소유와 수정에 있다
나머지는 개인 repo와 유사하다
release 할 때나 hotfix 외에는
team repo 받아서 작업해서 push 하면 안된다
팀 작업인 경우
작업 영역을 분배하는 골격을 만든다?
공통적으로 사용할 수 있는 폴더들을 만든다
css/
scss/
js/
images/
images/logo/
public/규칙 정하기
main repo의 경우 release commit 과 pullrequest 커밋만 남기도록 한다
모든 수정은 fork 한 repo 에서 pull request 하는 것으로 main repo에 반영시킨다
그 외 팀 내부적인 규칙을 만든다
develop 에서 하는 것
저장 또는 pull request 를 위한 git push (origin) (develop)
보통 하나의 feature 가 끝날 때나 이슈가 끝날 때… 저장소에 저장하고 싶을 때 올릴 수 있을 것 같다
pull request 단위가 개인 repo 의 develop 이기 때문에
보내기 위해선 git push 로 develop 에 보내긴 해야한다
작업을 저장하기 위해서도 올리는데
feature가 rocal에만 저장되는 듯 하기 때문에…
저장하고자 하는 단위를 develop 에 넣을 수도 있을 것임
feature 자체를 저장을 목적으로 remote? origin 에 올릴 수도 있을 것 같긴 하다
어짜피 저장해도 git flow를 따라가면 지워질 것 같은데..
작업 끝날 때 해당 feature 를 github 들어가서 브런치를 지워줘야 한다
삭제 할 수 있다
삭제할 때 Restore 할 수 있다
pull request 하기
최신 team/repo fetch&merge 하기
develop에 작업했던 feature 들을 가지고는 있는데
다른 사람들이 작업한 pull request 가 먼저 team/repo 에 merge 됬다면
해당 내용을 작업한 내용과 fetch&merge 한다
git conflict (충돌 해결 )
협업을 위해 작업할 구역을 나눴다면 충돌하는 작업이 일어나는 은 없거나 적어야한다
백엔드의 경우 js 파일 모듈 단위로
프론트의 경우 시멘틱 태그 단위로 작업하면 만날 일은 거의 없다
그리고 <head> 담당한테 필요한 import를 요구하는 식으로 하면 되지 않을까?
뭐 이렇게 하면 굳이 최신 fetch 작업 없이 merge 올려도 작업은 될 것 같은데…
근데 그걸 github가 알아먹느냐가 문제겠네
git full request 순서
일단 … 보기 좋은 건 지금까지 작업한 develop을 push 하고
upstream 에서 develop 을 fetch&merge 또는 pull 한 다음
push 해서 하는게 좋을까?
굳이 올리지 않아도 된다 그리고
어짜피 fetch& merge 하면서 conflict 하면서 제어할 수 있게 되고
conflict 가 감당이 안될 만큼 feature를 open한 상태로 길게 가져가는 건 좋지 않다
git push (origin) (develop)
여기서 git push 하면 default 는 git push (remote: origin) { 현재 branch 이름}
이고 전달 되는 건
현재 커서가 있는 로컬 branch > push 로 가르킨 remote 브런치다
만약 쌩뚱맞은 push가 하고 싶으면
git push (remote.git url) (branch name) 으로 하면 되지 않을까
fork한 git hub 에서 pull request
위에 작업을 모두 마치고 fork한 web github repo의 pull request 들어가면 New pull request 를 할 수 있다
pull requests 컨벤션 지키기
organizations/repo/develop ◀️ user/fork-repo/develop
일단 작성되어있는 이슈에 대한 표시를 한다
표시 방식은 : 이슈 트래킹 #number 표시
중간에 : 넣는 거 아니다 ( 그냥 #만 써도 연결 되긴 한다 )
Syntax 대로 써야지 close 되든 뭘 하든 되는 것으로 보임 : 참조 링크
| Linked issue | Syntax | Example |
|---|---|---|
| Issue in the same repository | KEYWORD #ISSUE-NUMBER | Closes #10 |
| Issue in a different repository | KEYWORD OWNER/REPOSITORY#ISSUE-NUMBER | Fixes octo-org/octo-repo#100 |
| Multiple issues | Use full syntax for each issue | Resolves #10, resolves #123, resolves octo-org/octo-repo#100 |
fix (fix, fixes, fixed) #number #number #number
close (close, closes, closed) #number #number #number
resolve(resolve, resolves, resolved) #number #number #number
평가된 리뷰대로 수정해서 team repo에 merge 될 때까지 push를 한다
한 번 open된 pull request는 close 될 때 까지 pull request에서 push 된 걸 추적한다?
확실하지 않다
release 하기
release 태그 생성
release 의 작성 목적은
버전 관리와 release note에 있다
팀 repo에 release 는 팀 레포를 clone 해서 release 하려는 delelop 의 최신 commit으로 pull 한 이후 teamrepo 를 release한다
git flow release start [tagname]
git flow release finish [tagname]
git flow release 과정에서 commit을 3개? 작성한다고 하는데
작성 안된 commit이 나오면 그 곳에는 release note 를 작성 하면되나..?
markdown 문법으로 쓰면 되고 미리 작성해서 붙여넣어도 된다
release 반영하기
finish 를 하면 develop 으로 branch 가 들어와 있다
git push origin develop
git switch main
git push origin main
git push —tags
tag 컨벤션
롤이 좋은 예시
v 1.2.3
1 버전 2번째 정기 업데이트 3번쨰 업데이트?
시즌 패치나 버전 패치 .조금 큰 패치나 정기 업데이트.자잘한 패치
git commit 컨벤션
Conventional Commits
ref: https://www.conventionalcommits.org/ko/v1.0.0/
- commit의 제목은 commit을 설명하는 하나의 구나 절로 완성
- 제목과 내용은 한 줄 띄워 ( 비워서 ) 분리할 것.
- 해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함.
- importanceofcapitalize Importance of Capitalize
- prefix 꼭 달기
feat: 기능 개발 관련
fix: 오류 개선 혹은 버그 패치
docs: 문서화 작업
test: test 관련
conf: 환경설정 관련
build: 빌드 관련
ci: Continuous Integration 관련
BREAKING CHANGE : 아주 큰 변경점? 전부 대문자로 쓰는 건 꼭 보라는 의미
trailing comma
수정할 때 불필요한 내용까지 수정됬다고 표시되지 않게 하는 방식
const test = {
a : a,
b : b,
c : c,
}root의 Readme.md 컨벤션
# 제목
## Installation
설치 방법
## How to Start : 시작 방법
간단한 사용 방법, 명령어 조작키 , 시작키 등
## Skills & Stacks : 사용한 스킬, 스택
- javascript
- python
## 오픈소스의 경우 Contribute 작성
오픈소스 기여 방법을 명시해야한다
## References : 참조된 링크