나는 현재 git 로의 마이그레이션을 계획하고 있지만 우리가 현재 svn 태그를 사용하는 방식에 대한 우아한 해결책을 찾지 못하는 것 같습니다. 현재의 내 저장소에서 나는이 자료를 1-1.n 있습니다모든 git 태그를 체크 아웃
tags
tags/1
tags/1.1
tags/1.n
tags/live
tags/library
tags/library/1
tags/library/2
을, 나는 라이브로 최신 버전을 병합하고 라이브러리는 각 버전에서 사용할 수있는 라이브러리가 포함되어 있습니다. 나는 git에서 1.n 태그를 만드는 방법을 이해하지만 라이브 태그 및 라이브러리 태그를 만드는 방법을 보려고 애 쓰고있다.
별도의 repo가 있어야하고 하위 모듈로 1-1.n에서 태그를 가져 오거나 직접 할 수 있습니까?
live은 태그가 아니라 지점이어야합니다. 단지 당신이 알지 못하는 경우 : 분기와 태그를 단순한 트리 복사 작업으로 취급하는 svn과 달리 (git과 함께 작업 할 때 사용하는 규칙이 유일한 구별) git의 분기와 태그는 단순히 특정 커밋에 대한 포인터 일 뿐이며, 주된 구분은 액티브 브랜치가 커밋을 따르는 반면 태그는 항상 커밋 된 상태를 유지한다는 점이다.
라이브러리 디렉토리가 분기 또는 태그가 아닙니다. 아마도 git submodules로 대체 될 수 있지만 작업하기가 까다로운 작은 놈이므로 일반 git 워크 플로우에서 기술을 조금이라도 향상시킬 때까지는 숨길 수 있습니다. 나를 틀리게하지 마라. 서브 모듈은 제 3 자 종속성을 관리하기위한 정확한 도구이지만, 익숙해지기까지하고, 근본적인 git 모델에 대한 강한 직관력이 없다면 완전히 신비하고 깨진 것처럼 보일 것입니다.
더 일반적인 용어로 말하자면, svn에서 git으로 갈 때 잃는 큰 일은 미리 설정된 워크 플로우의 편의입니다. Git을 사용하면 일반적인 svn 워크 플로와 훨씬 더 많은 작업을 수행 할 수 있지만 git 사용 방법에 대한 제약 조건을 적용하지 않으면 쉽게 스크래블 된 내역을 쉽게 만들 수 있습니다. 매우 효과적인 워크 플로 here을 찾을 수 있습니다. 이는 가능한 유일한 워크 플로가 아니며 상황에 가장 적합하지 않을 수도 있지만 워크 플로를 직접 작성하는 출발점이 될 수 있습니다. 예를 들어 svn에서 이동 한 우리 가게에서 master에 대한 커밋 대부분을 수행했는데 develop 분기를 사용하고 master 대신 release 분기에 태그를 붙입니다. 따라서 우리의 워크 플로우는 기본적으로 그들의 워크 플로우와 동일하지만, 수명이 긴 브랜치의 다른 이름 선택이 있습니다.
고마워, 그게 정말 도움이되고 좋은 시작이지만 그것은 같은 시간에 하나의 디렉토리에있는 모든 태그를 원할 때 우리가 원하는 것을 실제로하도록 허용하지는 않는다. –
@ JakeStride, git에서 태그가 어떤 디렉토리에도 없습니다. 저장소와 태그는 저장소의 특정 커밋에 대한 포인터입니다. git 커밋은 선형이 아니기 때문에 git에서 fin을 작동시킵니다. 하나의 커밋에는 여러 선행 및 후속 작업이있을 수 있습니다. – svick
@ JakeStride : 네가 맞아, 일반적으로 디렉토리에 태그를 표시 할 필요는 없어. 태그는 특정 커밋을 의미있는 이름으로 표시하는 방법 일뿐입니다. 태그를'git tag'처럼 쉽게 열거하고'git checkout
내역이 변경되면 태그가되어서는 안됩니다. 그리고 도서관은 그들의 꼬리표 안에 있으면 안됩니다. 그것들은 저장소의 일반적인 구조의 일부이거나 다른 저장소에 있어야합니다. 다시 말해서, 손에 엉망이 있고 그것을 합리적인 방법으로 git로 변환하는 것이 쉽지 않을 수 있습니다. – svick
svn에서이 폴더 구조는 배포 스택에서 작동하며 동일한 시스템에서 다른 버전을 실행할 수 있습니다. 이는 최상의 구조는 아니지만 필요한 작업에는 적합합니다. –
@ JakeStride 문제는 svn *에서 태그를 호출하는 것이 태그 *가 아니며 실제로 태그가 무엇인지 아는 VCS에서 태그로 사용할 수 없다는 것입니다. 그것은 svn이 무지하다는 것을 알려주며 오래된 태그를 태그라고 부를 수 있습니다. – hobbs