| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
Tags
- vim
- 도커
- Houdini
- 구조체
- jupyter
- 다트 언어
- C언어 포인터
- c# 추상 클래스
- docker
- github
- 유니티
- jupyter lab
- c# winform
- C++
- HTML
- c# 윈폼
- gitlab
- c언어
- Unity
- Data Structure
- Algorithm
- 플러터
- 포인터
- git
- C# delegate
- c#
- 깃
- Flutter
- dart 언어
- Python
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/
잘 밤에 쓸데없는 생각하기... - Git flow, GitHub flow, GitLab flow
회사에서 git을 가지고서 버전 관리를 본격적으로 하면서, 너무 많은 부분에서 문제가 발생을 하는 것을 보고 이걸 어떤 방식으로 사용하면 조금 더 꼬이는 것을 방지할 수 있을까라는 생각을 하고 있다. 물론 새로운 프로젝트를 진행하면서 어떤 방법으로 진행하는 것이 맞는 것인지도 필요하기도 했고, 그러다가 이상한 모임 Slack에서 관련 이야기가 나오면서 커밋을 하기 위한 방법론 중 하나인 git-flow의 종류가 3가지나 된다는 것을 보고 이놈들의 다른 점
ujuc.github.io
'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 |
'VCS/Git' Related Articles
more
Comments