나는 git와 github을 사용하고 있으며, iOS 앱 1.0 버전을 끝냈다. 여기에서 나는 어떻게하면 자식이 나를 가장 잘 섬길 수 있는지 궁금해.힘내 : 내 앱의 각 버전을 관리하나요?
여기서는 최상의 방법을 찾고 있으며, 다른 사람들이 주요 버전을 관리하기 위해 권장하는 것은 무엇입니까.
새 버전 (예 : 1.1, 1.5, 2.0 등)마다 새 분기를 만들어야합니까? 아니면 계속 마스터 브랜치로 이동해야합니까? 그렇다면 어떻게해야합니까?
난 당신이 V1.0이 v1.0라는 태그를 추가 수행되기 때문에 master 브랜치에서
git tag -a -m "Tagging release 1.0" v1.0
당신은 항상 또 다른 일반적인 관행 git checkout [tag_name]
를 호출하여 다시 언제든지 특정 버전으로 올 수있는이 방법은 안정 될 때까지 기능을 작동하는 지점을 사용하는 것입니다. [feature-branch]에 그것을 체크 아웃 어떤라는 이름의 새로운 지점을 생성
git checkout -b [feature-branch]
. 지형지 물에 대한 작업을 시작하려는 위치에서이 작업을 수행해야합니다 (일반적으로 master).
일단 안정되면 그들은 안전하게 master으로 통합 될 수 있습니다. master에서 다음을 실행 :
git merge [feature-branch]
당신의 master 지점이 항상 작동 상태로 유지 만 완료 항목을 한 번 준비가 추가됩니다 이런 식으로. 이렇게하면 테스트를 위해 항상 앱의 작업 사본을 유지할 수 있습니다 (이상적으로는 어쨌든).
태그를 사용하여 브랜치를 사용할 수 있지만 병합 할 수 없습니다. 우연히 다른 지점 버전.
버그 수정이 필요한 이전 버전을 유지 관리할지 여부에 따라 다릅니다. 새 기능을 2.0에 추가하는 동안 1.0에 버그 수정을 추가하려면 2.0 분기를 만들고 모든 버그 수정을 두 분기로 병합하고 2.0 기능을 추가하십시오. 그러나 각 지점 내의 각 릴리스에 필요한 것은 태그뿐입니다. 다시 병합하려는 가장 오래된 지점 인 을에서 분기하는 것을 잊지 마십시오.
개인적으로, 대형 프로젝트를 위해 내가 입양 한이 문서에 표시된 방법 중 가장 : 그것은 심지어 라이브러리와 할 수있는 도구가 지금 나를 위해 정말 잘 근무하고있다
http://nvie.com/posts/a-successful-git-branching-model/
방법론을 따르십시오 : http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
GitHub releases 메커니즘을 사용할 수도 있습니다. 그것은 GitHub로 소프트웨어 버전을 관리하는 방법입니다.
동의. 1.0 빌드 및 dsym 파일을 체크인하고 태그를 추가하십시오. 앞으로 버전 2.0에서 작업하면서 변경 사항을 1.1로 릴리스해야한다는 사실을 발견하면 해당 태그에서 항상 banch를 만들 수 있습니다.릴리스별로 지점이 필요하지 않지만 임시 개발을 할 때마다 주요 개발 분기를 단일 릴리스 분기로 병합하여 테스트를 위해 공개 된 코드의 명확한 기록을 유지하고 진행중인 불안정한 작업을 처리 할 수 있습니다. – Jonah
좋아, 그럼 1.0 태그를 추가하면 어떻게하면 1.1에서 작업을 시작할 수 있습니까? 다른 태그를 설정합니까? 이 개념에 대해 혼란스러워합니다. –
Jonah의 의견을 바탕으로 별도로 유지 관리하는 경우에만 버전 용 분기가 필요합니다. 예를 들어, master가 버전 3.0으로 작업하고 있지만 버전 2.0에서 몇 가지 버그를 발견하면 2.0 태그에서 시작하는 유지 보수 분기를 만들 수 있으며 결국 버전 2.1에 태그를 추가하고 해당 분기를 마스터 분기에 병합하여 곧 나오는 버전 3의 버그 수정. – Cascabel