일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- jupyter lab
- HTML
- github
- vim
- Houdini
- c# 추상 클래스
- C++
- docker
- 구조체
- 다트 언어
- c언어
- 유니티
- dart 언어
- C# delegate
- C언어 포인터
- Data Structure
- Algorithm
- Python
- gitlab
- jupyter
- Unity
- 깃
- c# winform
- c# 윈폼
- Flutter
- 플러터
- git
- 포인터
- 도커
- c#
Archives
- Today
- Total
nomad-programmer
[VCS/Git] 프로젝트 유형별 협업 흐름 본문
git을 이용한 협업은, 다르게 말하면 브랜칭 생성 규칙을 공유하는 것으로 말할 수 있다. git의 장점인 '자유롭고 무제한 브랜칭' 에 규칙을 정하는 것으로 협업의 틀이 완성되는 것이다.
브랜칭 생성 규칙의 예
요소/플랫폼 | 데스크탑 애플리케이션 | 웹 | 모바일 앱 |
특징 | 배포 후에 유지보수가 힘듦. | 배포와 개발의 구분이 없음. | 배포 이후 지속적인 업데이트 가능. |
프로젝트 마감 | 최초 배포 시 | 해당 없음 | 버전마다 |
배포 단위 | 최초 한 번. 업데이트는 패치 등으로 제공됨 | 해당 없음. 무결절성(seamless) | 버전마다 |
배포 시기 조절 가능 여부 ㉮ | 가능 | 해당 없음 | 불가능 ㉯ |
추천 Flow | git-flow | github-flow | gitlab-flow |
- ㉮: 배포 시기를 개발하는 쪽에서 완전하게 가져갈 수 있는지를 뜻한다.
- ㉯: 대부분은 앱 스토어나 마켓 등을 통해서 승인되어야 배포되므로 배포 시기를 조절하는 것이 불가능하다고 볼 수 있다.
위의 표 기준을 따라 기계적으로 결정할 수는 없지만 프로젝트가 어떤 특징이냐에 따라 어울리는 협업 흐름이 있다는 것을 알아두면 좋다.
참고하기 좋은 사이트
https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/
'VCS > Git' 카테고리의 다른 글
[VCS/Git] github-flow : 웹 애플리케이션 개발 환경에 권장 (0) | 2019.12.05 |
---|---|
[VCS/Git] git-flow : 게임이나 SI 개발 환경에 권장 (2) | 2019.12.05 |
[VCS/Git] 프로젝트를 위한 협업 준비 규칙 (0) | 2019.12.05 |
[VCS/Git] no fast-forward 전역 속성 추가 (0) | 2019.12.04 |
[VCS/Git] git rebase: 브랜치 이력을 확인하면서 병합하기 (0) | 2019.12.03 |
Comments