SVN, Branch를 사용하는 방법? 꼬리표? 트렁크?

나는 약간의 인터넷 검색을하고 있었고 "어떻게 명령을 사용 하는가"라는 의미가 아니라 SVN 에 대한 "초보자"안내서를 찾을 수 없었다 . 소스 코드를 어떻게 제어합니까?

정리하고 싶은 것은 다음과 같습니다.

• 얼마나 자주 커밋합니까? 자주 Ctrl+를 누르는 것처럼 s?
• 지점이란 무엇이며 태그는 무엇이며 어떻게 제어합니까?
• SVN에는 어떤 것들이 있습니까? 여기에서만 소스 코드 또는 다른 파일을 공유합니까? (버전이 지정된 파일로 간주되지 않습니다..)

나는 브랜치와 태그가 무엇인지 전혀 모른다. 그래서 목적을 알지 못한다. 그러나 나의 추측은 트렁크에 물건을 업로드하고 주요 빌드를 할 때 브랜치로 옮기는 것이라고 생각한다. 그렇다면이 경우 주요 빌드로 간주되는 것은 무엇입니까?

서브 버전 책은 , 저장소를 배치 분기 및 태그에 대한 전략에 대한 정보의 훌륭한 소스입니다.

또한보십시오:

지점 또는 트렁크에서 개발을 계속합니까

분기 전략

Subversion을 구현할 때도 같은 질문을했습니다. 4-6 개의 프로젝트에 약 20 명의 개발자가 있습니다. 나는``답변 ''으로 좋은 소스를 찾지 못했습니다. 지난 3 년간 Google의 답변이 어떻게 발전했는지에 대한 일부 내용은 다음과 같습니다.

-유용한만큼 자주 커밋; 우리의 경험 법칙은 수정 작업을 잃어버린 경우 다시해야하는 문제가 될만큼 충분한 작업을 수행 할 때마다 커밋됩니다. 때로는 15 분마다 커밋하고 다른 경우에는 며칠 일 수 있습니다 (예, 때로는 한 줄의 코드를 작성하는 데 하루가 걸립니다)

-우리는 다양한 개발 경로에 대해 이전 답변 중 하나에서 제안 된 분기를 사용합니다. 현재 우리 프로그램 중 하나에 대해 3 개의 활성 브랜치가 있습니다.

-태그를 거의 사용하지 않지만 프로덕션 릴리스를 식별하기 위해 태그를 사용해야한다고 생각합니다.

단일 경로를 따라 개발이 진행되는 것을 생각하십시오. 어느 시점 또는 개발 상태 마케팅에서 제품의 첫 번째 버전을 릴리스하기로 결정하므로 '1'(또는 '1.0'또는 무엇을 가지고 있는지)이라는 경로에 플래그를 설치하십시오. 다른 때에 약간의 밝은 불꽃이 프로그램을 병렬화하기로 결정했지만 몇 주가 걸리고 사람들이 그 동안 계속해서 주요 길을 가고 싶어하기로 결정했습니다. 그래서 당신은 길에 포크를 만들고 다른 사람들이 다른 포크를 헤매고 있습니다.

도로의 깃발을 '태그'라고하며 도로의 포크는 '분기'가 나뉘는 곳입니다. 때때로, 가지도 함께 돌아옵니다.

-실행 파일 (또는 시스템)을 구축하는 데 필요한 모든 자료를 저장소에 넣습니다. 즉, 최소한 소스 코드와 파일 (또는 Visual Studio 용 프로젝트 파일)을 만들어야합니다. 그러나 아이콘과 구성 파일 및 기타 모든 것들이 있으면 저장소에 들어갑니다. 일부 문서는 저장소에 들어갑니다. 프로그램에 필수적 일 수있는 도움말 파일과 같은 문서는 물론 개발자 문서를 저장하는 데 유용한 장소입니다.

심지어 소프트웨어를 찾는 사람들에게 단일 위치를 제공하기 위해 프로덕션 릴리스 용 Windows 실행 파일도 넣었습니다. Linux 릴리스는 서버로 이동하므로 저장할 필요가 없습니다.

-리포지토리가 항상 빌드하고 실행하는 최신 버전을 제공 할 필요는 없습니다. 어떤 프로젝트는 그런 식으로 작동하지만 어떤 프로젝트는 그렇지 않습니다. 결정은 프로젝트 관리자에게 달려 있으며 많은 요인에 달려 있지만 프로그램을 크게 변경할 때 결정이 내려 진다고 생각합니다.

* How often do you commit? As often as one would press ctrl + s?

가능한 한 자주. 소스 제어하에 있지 않으면 코드가 존재하지 않습니다 :)

빈번한 커밋 (이후 더 작은 변경 세트)을 사용하면 변경 사항을 쉽게 통합하고 무언가를 중단하지 않을 가능성을 높일 수 있습니다.

다른 사람들은 함수형 코드가있을 때 커밋해야한다고 언급했지만 조금 더 자주 커밋하는 것이 좋습니다. 몇 번이나 소스 컨트롤을 빠른 실행 취소 / 다시 실행 메커니즘으로 사용하는 것으로 나타났습니다.

내 자신의 지점에서 일할 때 나는 가능한 한 많이 커밋하는 것을 선호합니다 (문자 그대로 Ctrl + s를 누를 때마다).

* What is a Branch and what is a Tag and how do you control them?

SVN 서적 읽기 -SVN을 배울 때 시작해야하는 곳입니다.

• 지점이란?
• 태그

* What goes into the SVN?

문서화, 빌드에 필요한 작은 바이너리 및 일부 가치가있는 기타 것들이 소스 제어로 이동합니다.

커밋 빈도, 커밋 메시지, 프로젝트 구조, 소스 제어 및 기타 일반적인 지침에 대한 리소스는 다음과 같습니다.

• 버전 관리 모범 사례 (나만의 블로그)
• 조기 체크인, 종종 체크인 (코딩 공포) (코멘트에는 많은 조언이 포함되어 있음)
• KDE의 커밋 정책

이 스택 오버플로 질문에는 다음과 같은 유용한 정보가 포함되어 있습니다.

• 두 개 이상의 언어를 혼합 할 때 소스 코드 기반 구성 (예 : Java 및 C ++)
• 좋은 커밋 메시지에 대한 제안 : 형식 / 지침?
• 소스 컨트롤에 변경 사항을 커밋하는 빈도는?
• 버전 관리 학습 및 학습

분기 및 태그 지정과 같은 기본 Subversion 개념에 대해서는 Subversion 책 에서 잘 설명되어 있다고 생각합니다 .

이 주제에 대해 조금 더 읽은 후에 알 수 있듯이이 분야의 모범 사례에 대한 사람들의 의견은 다양하고 때로는 상충됩니다. 가장 좋은 방법은 다른 사람들이하는 일을 읽고 자신에게 가장 적합한 지침과 관행을 선택하는 것입니다.

연습의 목적을 이해하지 못하거나 그 근거에 대한 이론적 근거에 동의하지 않는 경우 연습을 채택하는 것은 좋은 생각이 아닙니다. 따라서 맹목적으로 조언을 따르지 말고 자신에게 가장 잘 맞는 것에 대해 스스로 생각하십시오. 또한 여러 가지 일을하는 방법을 실험하는 것이 자신이 가장 잘 일하는 방법을 배우고 찾는 좋은 방법입니다. 이에 대한 좋은 예는 저장소를 구성하는 방법입니다. 옳고 그른 방법은 없으며 실제로 실제로 시도하기 전에는 어떤 방법을 선호하는지 알기가 어렵습니다.

커밋 빈도는 프로젝트 관리 스타일에 따라 다릅니다. 많은 사람들이 빌드 (또는 기능)를 깨뜨릴 경우 커밋을 자제합니다.

분기는 일반적으로 다음 두 가지 방법 중 하나로 사용될 수 있습니다. 1) 개발을위한 하나의 활성 분기 (및 트렁크는 안정적으로 유지됨) 또는 2) 대체 개발 경로를위한 분기.

태그는 일반적으로 릴리스를 식별하는 데 사용되므로 믹스에서 손실되지 않습니다. '릴리스'의 정의는 귀하에게 달려 있습니다.

주된 문제는 소스 제어의 정신적 그림이 혼란 스럽다고 생각합니다. 우리는 보통 트렁크와 브랜치를 가지고 있지만 태그 / 릴리즈와 관련이없는 아이디어 나 그에 영향을주는 것을 얻습니다.

당신이 나무의 아이디어를 더 완전하게 사용한다면 그것은 적어도 더 나아질 것입니다.

우리는 줄기를 얻습니다.

아이디어는 트렁크에서 프로젝트를 확장 한 다음 트렁크가 분기를 보유 할 수있을만큼 안정적이되면 분기를 작성한다는 것입니다. 그런 다음 지점에서 과일을 생산하면 지점에서 과일을 뽑아서 태그로 해제합니다.

태그는 본질적으로 결과물입니다. 줄기와 가지가 생산하는 반면.

다른 사람들이 말했듯이 SVN Book 은 시작하기 가장 좋은 곳이며 일단 바다 다리를 얻은 후에는 훌륭한 참고 자료입니다. 자, 당신의 질문에 ...

얼마나 자주 커밋합니까? ctrl + s를 누르는 빈도는?

ctrl + s를 누르는 것처럼 자주는 아니지만 개인적인 취향 및 / 또는 팀 정책의 문제입니다. 개인적으로 나는 기능적인 코드 조각을 완성 할 때 커밋이라고 말하고 싶습니다.

지점이란 무엇이며 태그는 무엇이며 어떻게 제어합니까?

첫째, 트렁크는 당신이 적극적으로 개발하는 곳입니다. 코드의 메인 라인입니다. 브랜치는 메인 라인과 약간의 편차입니다. 이전 릴리스와 같이 큰 편차이거나 시도하려는 약간의 조정일 수 있습니다. 태그는 코드의 스냅 샷입니다. 특정 개정판에 레이블 또는 책갈피를 첨부하는 방법입니다.

또한 서브 버전에서 트렁크, 브랜치 및 태그는 컨벤션 일뿐입니다. 태그에서 작업을하거나 메인 라인 인 브랜치를 가지거나 태그 브랜치 트렁크 구성을 모두 무시하지 않아도됩니다. 그러나 그럴만한 이유가 없다면, 관습을 지키는 것이 가장 좋습니다.

SVN에는 어떤 것들이 있습니까? 여기에서만 소스 코드 또는 다른 파일을 공유합니까?

또한 개인 또는 팀 선택. 빌드와 관련된 모든 것을 내 저장소에 유지하는 것을 선호합니다. 여기에는 구성 파일, 빌드 스크립트, 관련 미디어 파일, 문서 등 이 포함됩니다. 각 개발자의 컴퓨터에서 다른 파일을 체크인 해서는 안됩니다 . 또한 코드의 부산물을 체크인 할 필요도 없습니다. 나는 주로 빌드 폴더, 객체 파일 등을 생각하고 있습니다.

2009 년 1 월 SO podcast # 36에 실린 Eric Sink는 Source Control How-to 라는 제목으로 훌륭한 기사를 썼습니다 .

(Eric은 SourceSafe의 플러그 호환 버전을 판매하지만 끔찍함 이없는 SourceGear 의 창립자입니다 .)

다른 답변을 추가하려면 다음을 수행하십시오.

• 나는 일을 마칠 때마다 커밋합니다. 때로는 한 줄을 바꾸고 2 분이 걸리는 작은 버그 수정입니다. 다른 때는 땀이 2 주 분량입니다. 또한 경험에 비추어 볼 때 빌드를 손상시키는 것은 커밋하지 않습니다. 따라서 무언가를 수행하는 데 시간이 오래 걸린다면 커밋하기 전에 최신 버전을 사용하고 변경 사항으로 인해 빌드가 중단되는지 확인하십시오. 물론 커밋하지 않고 오랫동안 가면 그 일을 잃고 싶지 않기 때문에 불안해집니다. TFS에서는이 기능을 "선반"으로 사용합니다. SVN에서는 다른 방법으로 해결해야합니다. 아마도 자신의 브랜치를 만들거나 이러한 파일을 다른 컴퓨터에 수동으로 백업하십시오.
• 지점은 전체 프로젝트의 사본입니다. 사용에 대한 가장 좋은 예는 아마도 제품의 버전입니다. 대규모 프로젝트 (예 : Linux 커널)에서 작업하고 있다고 상상해보십시오. 몇 달 동안 땀을 흘린 후에 마침내 공개 버전 1.0에 도달했습니다. 그 후 당신은 더 나아질 제품의 2.0 버전 작업을 시작합니다. 그러나 그동안 버전 1.0을 사용하는 많은 사람들이 있습니다. 그리고이 사람들은 당신이 고쳐야 할 버그를 찾습니다. 이제 다가오는 2.0 버전의 버그를 수정하여 클라이언트에 제공 할 수는 없습니다. 전혀 준비가되지 않았습니다. 대신 1.0 소스의 오래된 사본을 꺼내어 버그를 수정하여 사람들에게 전달해야합니다. 이것이 가지를위한 것입니다. 당신이 1을 놓았을 때 0 버전은 SVN에서 지점을 만들었으며 그 시점에서 소스 코드의 사본을 만들었습니다. 이 지점의 이름은 "1.0"입니다. 그런 다음 주 소스 사본에서 다음 버전에 대한 작업을 계속했지만 1.0 사본은 릴리스 당시와 동일하게 유지되었습니다. 그리고 계속해서 버그를 고칠 수 있습니다. 태그는 사용하기 쉽도록 특정 개정판에 첨부 된 이름 일뿐입니다. "소스 코드의 개정 2342"라고 말할 수는 있지만 "첫 번째 안정 개정"이라고하는 것이 더 쉽습니다. :)
• 나는 보통 프로그래밍과 직접 관련된 모든 것을 소스 컨트롤에 넣습니다. 예를 들어, 나는 웹 페이지를 만들고 있기 때문에 이미지와 CSS 파일을 소스 제어에 넣고 구성 파일 등은 언급하지 않습니다. 프로젝트 문서는 거기에 들어 가지 않지만 실제로는 환경 설정의 문제입니다.

다른 사람들은 그것이 당신의 스타일에 달려 있다고 말했습니다.

가장 큰 문제는 소프트웨어를 "통합"하는 빈도입니다. 테스트 중심 개발, Agile 및 Scrum (및 기타 다수)은 작은 변화와 지속적인 통합에 의존합니다. 그들은 작은 변화가 이루어 졌다고 설교하며 모두가 휴식을 찾아 내고 고칩니다.

그러나 규모가 큰 프로젝트 (정부, 국방, 100k + LOC)에서는 불가능한 연속 통합을 사용할 수 없습니다. 이러한 상황에서는 분기를 사용하여 많은 작은 커밋을 수행하지만 작동하고 빌드에 통합 할 준비가 된 것만 트렁크로 다시 가져 오는 것이 좋습니다.

분기가있는 한 가지주의 사항은 제대로 관리하지 않으면 모든 사람이 트렁크의 다른 지점에서 개발함에 따라 트렁크에 작업을하는 것이 저장소에서 악몽이 될 수 있다는 것입니다. 지속적인 통합).

이 질문에 대한 확실한 답은 없습니다. 최선의 방법은 팀과 협력하여 최상의 타협 솔루션을 만드는 것입니다.

Subversion을 사용한 버전 관리 는 초보자와 노인 모두를위한 안내서입니다.

적어도 처음 몇 장을 읽지 않고도 Subversion을 효과적으로 사용할 수 있다고 생각하지 않습니다.

커밋을 위해 다음 전략을 사용합니다.

• 가능한 자주 커밋하십시오.

• 각 기능 변경 / 버그 수정은 자체 커밋을 가져와야합니다 (그러므로 많은 파일을 한 번에 커밋하면 해당 파일의 기록이 명확하지 않습니다. 예를 들어 로깅 모듈과 GUI 모듈을 독립적으로 변경하고 한 번에 모두 커밋하면, 두 가지 변경 사항이 두 파일 기록에 모두 표시되므로 파일 기록을 읽기가 어렵습니다.)

• 커밋에서 빌드를 중단하지 마십시오. 리포지토리의 모든 버전을 검색하여 빌드 할 수 있어야합니다.

앱을 빌드하고 실행하는 데 필요한 모든 파일은 SVN에 있어야합니다. 단위 파일의 일부가 아닌 경우 테스트 파일 및 그와 같은 파일을 사용해서는 안됩니다.

여기에 많은 좋은 의견이 있지만 언급되지 않은 것은 커밋 메시지입니다. 이것들은 필수적이고 의미가 있어야합니다. 특히 분기 / 병합시. 이를 통해 어떤 버그 기능과 관련된 변경 사항을 추적 할 수 있습니다.

예를 들어 svn commit . -m 'bug #201 fixed y2k bug in code'은 역사를 보는 사람에게 그 개정판의 내용을 알려줍니다.

일부 버그 추적 시스템 (예 : trac)은 저장소에서 이러한 메시지를 찾아서 티켓과 연관시킬 수 있습니다. 각 티켓과 관련된 변경 사항을 매우 쉽게 해결할 수 있습니다.

우리 작업의 정책은 다음과 같습니다 (객체 지향 프레임 워크에서 작업하는 다중 개발자 팀).

• 전날의 변경 사항을 얻으려면 매일 SVN에서 업데이트하십시오.

• 다음 날 아프거나 결석하면 매일 다른 사람이 당신이 쉬었던 곳에서 다른 사람을 쉽게 대신 할 수 있습니다.

• 다른 개발자에게 영향을 줄 수있는 코드를 커밋하지 마십시오.

• 작은 덩어리로 작업하고 의미있는 의견으로 매일 커밋하십시오!

• 팀으로서 : 개발 지점을 유지 한 다음 QA 용 시험판 코드를 생산 지점으로 옮깁니다. 이 브랜치는 완전히 작동하는 코드 만 있어야합니다.

TortoiseSVN TSVN 매뉴얼 은 subversion book을 기반으로 하지만 더 많은 언어로 제공됩니다.

커밋 빈도에는 두 가지 방법이 있다고 생각합니다.

1. 구현 된 각 메소드, 코드의 작은 부분 등에 대해 매우 자주 커밋하십시오.
2. 모듈 등과 같이 완성 된 코드 부분 만 커밋

소스 제어 시스템을 사용하는 것은 프로젝트 또는 회사뿐만 아니라 개발자에게도 유용하기 때문에 첫 번째를 선호합니다. 나에게 가장 좋은 기능은 할당 된 최상의 작업 구현을 검색하는 동안 모든 코드를 롤백하는 것입니다.