지금도 이런 느낌이 있지만 git를 활용한 개발 과정에서 git-flow의 도입 방법을 더욱 추진한다.

"git-flow" = 분기 이름 사용 규칙

3가지 지점으로 개발 프로세스 관리

[3가지]
1. develop->개발이라기보다는 일본의 무대 디자인
2.feature->기능 단위로 구성된 지점의feature/login,feature/signup 등.
3. hotfix-> 정식으로 발표된 긴급 오류 FIX 등을 실현하는 데 사용되는 지점

git-flow의 장점 기반

필요한 최소한의 지점의 구분

CVS를 사용할 때, 지점을 개발할 때

정착용 지점(합병용, 유일)

개발용 지점(개발당 제작)

이렇게 잘라서 사용하기 때문에 아마 저것과 같은 단위일 거예요.
가장 큰 차이점을 말하자면 CVS에는 리키와 커팅 등 편리한 기능이 없기 때문이다
합병할 때 "그럼, 시작합시다!"이런 기세가 필요하겠지.

분산된 창고를 최대한 이용하다

요즘git는 분산 창고 유형의 버전 관리 도구라는 것을 잊기 쉽다.
이 특성을 효과적으로 이용하는 사용 방법으로

한 사람이 대응할 수 있는 기능은 로컬 지점에서만 개발

멀티태스킹 기능에 대해 원격 지점만 개발

이런 사용 방법을 나는 매우 좋아한다.
한 번 해 본 원격 지점을 삭제하는 것은 매우 번거롭다.
원격 창고를 더럽히지 않도록 주의하면
자연과 개발된 인적자원에 공을 들일 수 있는 것은 일석이조라고 생각한다.

git-flow 안 좋은 곳.

분기 수가 증가하면 통합 비용 증가

이것은 이미 구제불능의 일이기 때문에 나는 내가 보험에 가입하고 있으니 포기하는 것이 좋겠다고 생각한다.

git-flow 가져오기 좋은 예

제품 개발
장기적으로 개발하면git-flow를 도입하는 장점이 많다.
feature 사용 방법은 기능 단위 이외에도 UI의 개선 단계에 따라 구분할 수 있다.
git의 기초 기능을 사용하면 개발이 끝난 기능을 다른feature 지점에 가져오는 것도 간단합니다.

정적 WEB 웹 사이트 운영
특징 은 제품 개발 과 같은 측면 이 많지만 변경 점 이 있다
CSS가 엉망진창이 됐을 때는 빨리 제자리에 돌려놓고 볼 수 있어 편리하다.

git-flow 부적합한 상황

개발 목표 확정
개발 목표
한 번 발매되면 당분간 개편하지 않겠다는 등의 상황인 셈이다.
결과물을 교부하면 끝이야, 이런 프로젝트지.
이 경우 마스터 하나만 개발하는 게 좋을 것 같아요.
개발 속도가 높아지기 때문에 그 장점은 커질 것이다.

아주 작은 개발
말할 필요가 없다
버전 관리 자체도 연구해야 할 수준의 프로젝트를 도입하는 것이 아닌가.
하지만 현지 등지에서git를 간단하게 구축할 수 있다면
보험 개발 대신 마스터 하나 쓰면 되잖아.

git-flow를 가져오면 사용하고 싶은 도구

SourceTree

그 유명한 JIRA 같은 개발사 Atlassian의 도구입니다.
어쨌든 지금은 무료로 사용할 수 있지만, 언젠가는 유상이 될 것이다
별로 안 좋아하는 이유야.
이렇게 말하지만, 지금은 매우 강력한git GUI 도구입니다.
git-flow에 대응하는 UI를 제공했기 때문에 매우 추천하는 도구입니다!!
[SourceTree 다운로드 페이지]
https://www.atlassian.com/ja/software/sourcetree/overview