깃 차근차근 알아가보자~
Updated:
깃을 접하고 사용한지가 오래 되었는데 많은 블러그에 문서가 많이 있고 그걸 토대로 잘 이용했다고 생각했습니다. 잘 이용하고 있긴 한데 주로 사용하는 내용이 정리가 잘되면 후임또는 인수인계시에 추가되는 리소스를 좀 줄여줄수 있지 않을가해서 작성을 해보기로 했습니다.
브랜치 정책
일반적인 브랜치 정책이 아닌 제가 주로 쓰는 정책인데 인프라 환경에 따라 달리 가게 된다.
- master : 마지막 메이저 버전 v1.0.0
- release : 운영서버에 해당 v1.1.1
- alpha : 알파 테스트 브랜치
- develop : 개발테스트 브랜치
- feature : 기능단위 브랜치 v1.1.0
- hot fixes : 유지보수 브랜치 v1.0.1
정석적인 커밋 방법
작업순서
- 개발자는 지라를 통해 기획자가 만든 이슈를 본인의 업무로 할당
- 개발자는 업무 확인
- 브랜치 네이밍을 참고하고 최종본에서 브랜치를 생성
1. 브랜치 생성
-- 현재 운영에 반영되어 있는 브랜치를 가져옵니다.
-- 아래 명령어를 이용하면 새로운 명칭의 브랜치를 새로 생성과 동시에 브랜치 이동이 가능합니다
git checkout -b feature/xxx origin/release
git checkout -b hotfixes/xxx origin/release
2. 커밋
-- 작업한 소스를 git staging에 add합니다. (개별, 전체)
git add 파일경로/파일명(확장자 기입) => 개별
git add .(dot) => 전체
git add 파일경로/* => 일괄적용
-- 권장하는 방식 (옵션을 권장하는 이유는 staging에 올라갈때 변경된 소스를 체크하여 add여부를 결정할 수 있습니다.)
git add -p <파일>
-- 작업한 소스를 commit 합니다. ( -m 옵션이 없을 경우 commit 메세지 작성할 수 있는 vi창 생성됨 )
git commit -m "메세지"
-- 추가적으로 위 add 권장방식과 동일한 방식으로 commit 가능
git commit -v
- push 없이 여러번 commit 하고 싶은 경우 add와 commit을 반복해서 사용해주면 됩니다. (또는 commit 없이 다른 브랜치로 이동하고 싶다면 => git stash(임시저장) 명령어를 사용합니다. )
3. 커밋메세지
깃 커밋시에 해당 메세지를 남기고 Push/Pull Request 시 적용, PR 메세지는 아무거나 해도 상관없습니다
첫줄엔 작업의 내역
[JIRA 와 연동시]
JRA-34 #comment 배포전이니깐 건들지 마라
JRA-34 #time 1w 2d 4h 30m 이슈해결
JRA-34 #qa
- 협업툴과 연동된 작업시 이슈에 모든 내용이 담겨 있어서 따로 메세지를 작성하지 않아도 된다. 다만 협업툴이 없는 작업시엔 상세하게 내용을 기입해야 한다.
4. develop 브랜치로 반영
1. 작업 branch를 develop branch로 pull request
github에서 new pull reqeust하여 작업 소스를 확인한 후 develop으로 pull request합니다.
장점
- 작업한 소스를 시각적으로 보기 편함
- 충돌이 발생했을 경우 대처가 쉬움
단점
- 매번 github 홈페이지를 통해 pull request하기 때문에 시간비용이 큼
- 작업 branch를 remote에 push하여 원격 브랜치가 많아져 복잡해질 수 있음
-- git push origin feature/xxx
2. develop branch를 local repository로 내려받아 merge한 후 test진행
장점
- local repository에서 merge에 대한 test를 진행하기 때문에 충돌이 발생해도 대처가 가능
단점
- 로컬에 주요 branch가 생성되서 실수로 잘못 push를 할 수 있는 상황이 발생할 수 있음.
-- remote develop 브랜치를 local로 내려받습니다.
git checkout develop
git pull origin develop
-- local develop branch에 작업 branch를 merge 합니다.
git merge feature/xxx
-- local develop 브랜치 push (테스트 및 충돌여부 확인 후)
git push origin develop
-- local develop branch 삭제
git branch -d develop
Tip
되돌리기(Reset, Revert)
- Revert : 이력을 남기면서 수정한다. ```vim git revert 6646937a625f02b5532260b5b6c45f11f3deef83 –no-commit # –no-commit을 적지 않으면 기본적으로 revert와 동시에 revert내용이 커밋되어버린다. git add – src/main/webapp/WEB-INF/static/js/group/exam_mng.js git commit -m “Revert alert 삭제”
#여러개의 커밋내역을 revert할때, 커밋의 역순으로 진행해야한다. commit: 1->2->3, revert: 3->2->1
revert를 여러번 쓰는 방법도 있지만 아래와같이 범위로 삭제할수도있다.
git revert –no-commit HEAD~3 # HEAD부터 3개의 커밋내역을 revert, 여기서도 –no-commit을 작성해야, 한번의 커밋으로 다건의 revert내용을 커밋할수 있다.
* Reset : 이력을 지운다.
```vim
#commit을 취소하고 해당 파일들을 staged 상태로 워킹 디렉터리에 보존
git reset --soft HEAD^ #제일 최신 commit을 취소
#commit을 취소하고 해당 파일들을 unstaged 상태로 워킹 디렉터리에 보존
git reset --mixed HEAD^
git reset HEAD^ #위와 동일
git reset HEAD~2 # 마지막 2개의 commit을 취소
#commit을 취소하고 해당 파일들은 unstaged 상태로 워킹 디렉터리에서 삭제
git reset --hard HEAD^
reset의 경우 local에만 있는 commit 이나 단독으로 사용하는 branch의 경우에만 사용한다. 다른 개발자가 해당 branch를 pull 한 경우, reset을 통해 이력을 지운상태면 커밋 내역이 꼬이게 된다.
Cherry-pick
cherry-pick 이란 다른 브랜치 위에 있는 커밋을 선택적으로 내 브랜치에 적용시킬 때 사용하는 명령어이다.
-
사용하는 이유 — 커밋을 다른 브랜치에 잘못했을때 이를 뒤늦게 찾는 경우 — 요구사항이 바뀌어 필요없는 커밋이 생겼을경우 (해당커밋을 빼고 cherry-pick) — 수정사항이 생겨 두개의 브랜치에 동시 commit 해야 하는 경우 (한 브랜치에 커밋 후 다른 브랜치에 cherry-pick) — 코드 의존성 때문에 다른 사람의 커밋 중 일부를 가져와야 할 경우
-
예제 — 마스터 브랜치가 진행중(a > b > c > d) 이고 c 버전에서 feature 브랜치를 생성 작업(e > f > g)을 진행하였음. ```vim
git checkout Feature
git log –pretty=oneline
9f57292: g 76ae30ef: f b7e1921b: e
단건 f 만 커밋할 경우
git checkout master git cherry-pick 76ae30ef
복수건 커밋 f,e
git checkout master git cherry-pick 76ae30ef b7e1921b
범위 지정
git checkout master git cherry-pick 76ae30ef..b7e1921b
## 상황별 사례
회사마다 상황이 다르지만 1개 어플리케이션에 프로젝트가 진행중일수도 있고 유지보수와 동시에 프로젝트가 있을수 있습니다.
이러한 경우 어떻게 진행하였는지 사례를 들어 보았습니다.
### 유지보수만 있을때
#### 개발자 A
1. release 브랜치 기준으로 feature/function_1 생성
```vim
git checkout -b feature/function_1 origin/release
- 작업 완료 후 develop 브랜치에서 feature/function_1 브랜치 머지후 테스트 ```vim – local develop branch로 변경 git checkout develop
– 원격 develop branch와 동기화 git pull origin develop:develop
– 작업한 branch 소스 merge git merge feature/function_1
– 원격 branch에 반영 git push
3. 테스트 완료 후 alpha 브랜치에서 feature/function_1 브랜치 merge 후 QA 요청
```vim
-- local alpha branch로 변경
git checkout alpha
-- 원격 alpha branch와 동기화
git pull origin alpha:alpha
-- 작업한 branch 소스 merge
git merge feature/function_1
-- 원격 branch에 반영
git push
- QA 완료 후 feature/function_1 브랜치에서 release로 Pull Request후 배포 및 검수
개발자B
- release 브랜치 기준으로 feature/function_2 생성
git checkout -b feature/function_2 origin/release - 작업 완료 후 release 브랜치 변경점 존재시 merge 진행 — 변경점을 확인 하는 이유는 자신이 변경한 소스코드 이외의 소스는 항상 release와 동일해야 하고 미리 충돌을 확인해 충돌을 방지할수 있기 때문 ```vim – 원격 release branch와 local release branch 동기화 git pull origin release:release From https://github.com/duddn91/spring_jam f37ab9a..7a71f63 release -> release
//Already up to date. » 해당 문구 출력 시 변경점 없으니 merge 진행 x
– 최신 release 소스를 자신의 작업 branch에 merge – 해당 부분에서 conflict이 일어날 경우 해당 부분 작업자와 상의 후 merge 진행 git merge release
3. develop 브랜치에서 feature/function_1 브랜치 merge 후 테스트
```vim
git checkout develop
git pull origin develop:develop
git merge feature/function_2
git push
- 테스트 완료 후 alpha 브랜치에서 feature/function_2 브랜치 merge 후 QA 요청
git checkout alpha git pull origin alpha:alpha git merge feature/function_2 git push - QA 완료 후 feature/function_2 브랜치에서 release로 Pull Request후 배포 및 검수
프로젝트와 동시 수행
- 기본적으로 project 진행 시 코드 프리징(code Freezing)을 실행하지만 긴급 운영 건이 요청될 수 있다.
- project 검수 기간에는 알파 서버의 빌드 브랜치는 project 브랜치가 기본 브랜치이고 운영건 검수 진행 시 빌드 브랜치명만 수정해서 빌드하여 검수를 진행한다
- project 검수 기간이 아니고 긴급 운영 건이 들어올 경우 아래의 정책을 따르도록 한다.
- 개발자 A와 B는 project 진행자, 개발자 C는 긴급 운영 진행자로 설정.
개발자 A
- feature/project 브랜치 기준으로 feature/function_1 생성
git checkout -b feature/function_1 origin/feature/project - 작업 완료 후 feature/project 브랜치에 머지후 테스트
git checkout feature/project git pull origin feature/project:feature/project git merge feature/function_1 git push[주요] 알파서버에서 프로젝트 테스트시엔 브랜치면 변경해서 배포해 준다
개발자B
- feature/project 브랜치 기준으로 feature/function_2 생성
git checkout -b feature/function_2 origin/feature/project - merge 전 최신 소스코드 확인 및 merge
git pull origin feature/project:feature/project // Already up to date. >> 해당 문구 출력시 변경점이 없으니 merge 진행할 필요가 없다. git merge feature/project - 작업 후 feature/project 브랜치에 merge 후 테스트 진행
git checkout feature/project git merge feature/function_2 git push
개발자C
- release 브랜치를 기준으로 hoxfix/bug_fix 브랜치 생성 후 작업
git checkout -b hotfix/bug_fix origin/release - 작업 완료 후 alpha 브랜치에 merge하고 빌드 후 검수 요청
git checkout alpha git pull origin alpha:alpha git merge hotfix/bug_fix git push - 검수완료후 운영 배포 진행
git checkout release git pull origin release:release git merge hotfix/bug_fix git push - 운영 검수 완료 뒤 project 브랜치에 merge 진행 (project 브랜치에 merge 진행시 conflict 발생확률이 높음으로 현재 프로젝트 담당자의 도움을 받음)
git checkout feature/project git pull origin feature/project:feature/project git merge hotfix/bug_fix git push
Comments