버전 개정 관리 전략

비주얼 컨트롤 버전 컨트롤.
버전 제어 (일명 개정 제어, 소스 제어)를 사용하면 시간이 지남에 따라 파일을 추적 할 수 있습니다. 너 왜 신경 쓰냐? 그래서 엉망이되면 이전 작업 버전으로 쉽게 돌아갈 수 있습니다.
그렇게 괴상한 이름을 가지고 있다는 것을 깨닫지 못한 채 자신의 버전 제어 시스템을 만들었을 것입니다. 이런 파일들있어? (내가 바라는 이들 정확한 것은 아니다).
instalalc-logo3.png
우리가 "다른 이름으로 저장"을 사용하는 이유입니다. 이전 파일을 삭제하지 않고 새 파일을 원한다. 일반적인 문제이며 솔루션은 일반적으로 다음과 같습니다.
단일 백업 복사본을 만듭니다 (Document. old. txt). 우리가 영리하다면 버전 번호 나 날짜를 추가합니다. Document_V1.txt, DocumentMarch2015.txt 다른 사람들이 파일을 보지 않고 파일을보고 편집 할 수 있도록 공유 폴더를 사용할 수도 있습니다. 파일을 저장 한 후에 파일의 레이블을 다시 지정하면되기를 바랍니다.
그렇다면 VCS (Version Control System)가 필요한 이유는 무엇입니까?
우리의 공유 폴더 / 명명 시스템은 수업 프로젝트 또는 일회성 서류에 적합합니다. 그러나 소프트웨어 프로젝트? 기회가 아닙니다.
Windows 소스 코드가 "Windows2007-Latest-UPDATED !!"와 같은 공유 폴더에 있다고 생각하십니까? 누구든지 편집 할 수 있습니까? 모든 프로그래머는 다른 하위 폴더에서 작동합니까? 안돼.
크고 빠르게 변화하는 많은 저자와 함께하는 프로젝트는 변화를 추적하고 일반적인 혼란을 피하기 위해 버전 제어 시스템 ( "파일 데이터베이스"용 geekspeak)이 필요합니다. 좋은 VCS는 다음을 수행합니다.
백업 및 복원. 파일은 편집 할 때 저장되며 언제든지 이동할 수 있습니다. 그 파일이 2007 년 2 월 23 일에 필요 했나요? 문제 없어. 동기화. 사람들이 파일을 공유하고 최신 버전으로 최신 상태를 유지할 수 있도록합니다. 단기 실행 취소. 원숭이가 파일을보고 엉망으로 만들었습니까? (그것은 당신과 똑같습니다, 그렇지 않습니까?). 변경 사항을 버리고 데이터베이스의 "마지막으로 성공한"버전으로 돌아가십시오. 장기 실행 취소. 때때로 우리는 나빠질 것입니다. 1 년 전에 변경했다고 가정하면 버그가 있습니다. 이전 버전으로 돌아가서 그날 어떤 변화가 있었는지 확인하십시오. 변경 사항 추적. 파일이 업데이트되면 변경 사항이 발생한 이유를 설명하는 메시지 (파일이 아닌 VCS에 저장 됨)를 남길 수 있습니다. 따라서 시간이 지남에 따라 파일이 어떻게 변해가고 있는지, 왜 그런지를 쉽게 알 수 있습니다. 소유권 추적. VCS는 모든 변경 사항을 작성한 사람의 이름으로 태그 지정합니다. 믿음을주는 블레미노미밍에 도움이됩니다. 샌드 박싱 또는 자신에 대한 보험. 큰 변화를 만들었습니까? 격리 된 영역에서 임시 변경을 수행하고 변경 사항을 "체크인"하기 전에 꼬임을 테스트하고 해결할 수 있습니다. 분기 및 병합. 더 큰 샌드 박스. 코드 사본을 별도의 영역으로 분기하고 개별적으로 수정 (변경 사항을 별도로 추적) 할 수 있습니다. 나중에 공용 영역으로 다시 병합 할 수 있습니다.
공유 폴더는 빠르고 간단하지만 이러한 기능을 능가 할 수는 없습니다.
Lingo에 대해 알아보십시오.
대부분의 버전 제어 시스템에는 레이블이 다를 수 있지만 다음 개념이 포함됩니다.
저장소 (repo) : 파일을 저장하는 데이터베이스입니다. 서버 : repo를 저장하는 컴퓨터. 클라이언트 : 컴퓨터가 저장소에 연결됩니다. 작업 집합 / 작업 복사본 : 변경 한 파일의 로컬 디렉터리. Trunk / Main : repo에있는 코드의 기본 위치입니다. 코드를 가계도라고 생각하면 트렁크가 주된 선이됩니다.
추가 : 처음으로 파일을 저장소에 저장합니다. 즉, 버전 관리로 파일을 추적하기 시작합니다. 수정 버전 : 파일의 버전 (v1, v2, v3 등). 헤드 : 리포의 최신 개정판. 체크 아웃 : 레포에서 파일을 다운로드하십시오. 체크인 : 저장소에 파일을 업로드합니다 (변경된 경우). 파일에 새로운 개정 번호가 생기고 사람들은 최신 개정 번호를 "체크 아웃"할 수 있습니다. 체크 인 메시지 : 변경된 내용을 설명하는 짧은 메시지. 변경 내역 / 기록 : 파일이 생성 된 이후에 변경된 사항의 ​​목록입니다. 업데이트 / 동기화 : 파일을 저장소의 최신 파일과 동기화합니다. 이렇게하면 모든 파일의 최신 버전을 가져올 수 있습니다. 되돌리기 : 로컬 변경 사항을 버리고 리포지토리에서 최신 버전을 다시로드하십시오.
지점 : 개인 용도 (버그 수정, 테스트 등)를위한 별도의 파일 / 폴더 복사본을 만듭니다. 지점은 동사 ( "지점 코드")와 명사 ( "어느 지점입니까?")입니다. Diff / Change / Delta : 두 파일 간의 차이점을 찾습니다. 리비전간에 변경된 사항을 확인하는 데 유용합니다. 병합 (또는 패치) : 한 파일에서 다른 파일로 변경 사항을 적용하여 최신 상태로 만듭니다. 예를 들어 한 지점에서 다른 지점으로 기능을 병합 할 수 있습니다. (Microsoft에서 이것은 역 통합 및 전달 통합이라고 함) 충돌 : 파일에 대한 보류중인 변경 사항이 서로 모순되는 경우 (두 가지 변경을 모두 적용 할 수 없음). 해결 : 서로 모순되는 변경 사항을 수정하고 올바른 버전을 체크인하십시오. 잠금 : 잠금을 해제 할 때까지 아무도 수정할 수 없도록 파일을 제어합니다. 일부 버전 제어 시스템에서는 충돌을 피하기 위해이 기능을 사용합니다. 잠금 해제 : 파일을 강제로 열어 편집 할 수 있습니다. 누군가가 파일을 잠그고 휴가를 간다면 (또는 Halo 3이 나오는 날에 "아프다"라는 전화가 필요한 경우) 필요할 수 있습니다. 편집 체크 아웃 : 파일의 "편집 가능한"버전 체크 아웃. 일부 VCS에는 기본적으로 편집 가능한 파일이 있고 다른 파일에는 명시적인 명령이 필요합니다.
일반적인 시나리오는 다음과 같습니다.
Alice는 파일 (list. txt)을 저장소에 추가합니다. 그녀는 그것을 체크 아웃하고 변경 ( "우유"를 목록에 넣음) 한 다음 체크 인 메시지 ( "필수 항목 추가")를 사용하여 체크 인합니다. 다음날 Bob은 로컬 작업 집합을 업데이트하고 "우유"가 들어있는 list. txt의 최신 개정판을 봅니다. 그는 changelog 또는 diff를 검색하여 Alice가 전날에 "우유"를 넣었는지 확인할 수 있습니다.
시각적 인 예.
이 가이드는 의도적으로 높은 수준입니다. 대부분의 자습서는 일련의 텍스트 명령을 사용자에게 던집니다. 구문에 얽매이지 않고 상위 개념을 다루겠습니다 (Subversion 매뉴얼은 항상 존재합니다. 걱정하지 마십시오). 가능한 경우가 있는지 확인하는 것이 좋습니다.
가장 간단한 시나리오는 파일 (list. txt)을 체크인하고 시간이 지남에 따라 수정하는 것입니다.
새 버전을 체크인 할 때마다 새로운 개정판 (r1, r2, r3 등)이 생성됩니다. Subversion에서는 다음을 수행합니다.
-m 플래그는이 체크 인에 사용할 메시지입니다.
체크 아웃 및 편집.
실제로는 파일을 계속 체크인하지 못할 수도 있습니다. 체크 아웃, 편집 및 체크인해야 할 수도 있습니다. 주기는 다음과 같습니다.
변경 사항이 마음에 들지 않아 처음부터 다시 시작하려면 이전 버전으로 되돌리고 다시 시작하십시오 (또는 중지하십시오). 체크 아웃 할 때 기본적으로 최신 개정판이 제공됩니다. 원하는 경우 특정 개정을 지정할 수 있습니다. Subversion에서 다음을 실행합니다.
트렁크는 파일이 변함에 따라 변경된 기록을 가지고 있습니다. Diffs는 편집하는 동안 변경 한 내용입니다. 파일을 "껍질을 벗겨"제거하고 파일에 적용 할 수 있다고 상상해보십시오.
예를 들어 r1에서 r2로 이동하려면 계란 (+ 달걀)을 추가합니다. 빨간 스티커를 벗겨서 r1에 올려 놓고 r2를 얻는다고 상상해보십시오.
r2에서 r3으로 가려면 Juice (+ Juice)를 추가하십시오. r3에서 r4로 이동하려면 Juice를 제거하고 Soup (-Juice, + Soup)를 추가하십시오.
대부분의 버전 제어 시스템에는 파일의 전체 사본이 아닌 diff가 저장됩니다. 이렇게하면 디스크 공간을 절약 할 수 있습니다. 파일을 4 번 개정한다고해서 4 개의 사본이 있다는 것을 의미하지는 않습니다. 우리는 1 개의 사본과 4 개의 작은 diff를 가지고 있습니다. 꽤 멋진, 응? SVN에서, 우리는 다음과 같은 두 개의 파일 버전을 비교합니다 :
Diffs는 변경 사항 ( "이 버그를 어떻게 다시 수정 했습니까?")을 발견하고 한 지점에서 다른 지점으로 적용하는 데 도움을줍니다.
보너스 질문 : r1에서 r4까지의 차이점은 무엇입니까?
"Juice"가 어떻게 관여되지 않았는지주의하십시오. r1에서 r4 로의 직접 점프는 Juice가 Soup에 의해 무시 되었기 때문에 변경이 필요하지 않습니다.
브랜치를 사용하면 코드를 별도의 폴더에 복사 할 수 있으므로 별도로 원숭이를 사용할 수 있습니다.
예를 들어 쌀 목록이나 Eggo 와플과 같은 미친 물건에 대한 새롭고 실험적인 아이디어를위한 지점을 만들 수 있습니다. 버전 제어 시스템에 따라 분기 (사본)를 작성하면 개정 번호가 변경 될 수 있습니다.
이제 지점이 생겨 코드를 변경하고 꼬임을 해결할 수 있습니다. ( "흠 ... 와플? 나는 상사가 생각하는 것을 모른다. 쌀은 안전한 내기다."). 우리는 별도의 지점에 있기 때문에 변경 사항을 테스트하고 별도로 테스트를 수행 할 수 있습니다. 그리고 우리의 지점 기록은 버전 제어하에 있습니다.
Subversion에서는 디렉터리를 다른 디렉터리로 복사하여 분기를 만듭니다.
따라서 분기는 너무 개념이 어렵지 않습니다. 코드를 다른 디렉토리에 복사했다고 가정합니다. 당신은 아마도 학교 프로젝트에서 코드를 분파했을 것입니다. 일이 터지면 복귀 할 수있는 "실패 안전"버전을 갖추 었는지 확인하십시오.
브랜치는 간단합니다. 뭐, 한 지점에서 다른 지점으로 변경 사항을 병합하는 방법을 찾는 것이 까다로울 수 있습니다.
실험적인 지점에서 메인 라인으로 "쌀"기능을 얻고 싶다고 가정 해 봅시다. 어떻게할까요? 차이 r6과 r7과 그것을 메인 라인에 적용할까요?
우롱고. 우리는 단지 지사에서 일어난 변화를 적용하기를 원합니다! . 그것은 우리가 r5와 r6을 달리하고 그것을 메인 트렁크에 적용한다는 것을 의미합니다 :
r6과 r7을 비교해 보면, main에 있던 "Bread"기능을 잃을 것입니다. 이것은 미묘한 점입니다. 실험 지점 (+ 라이스)에서 변경 사항을 "떼어 내고"이를 메인에 추가한다고 상상해보십시오. 메인에는 다른 변경 사항이있을 수 있습니다. 괜찮습니다. 쌀 기능을 삽입하기 만하면됩니다.
Subversion에서 병합은 diffing과 매우 유사합니다. 메인 트렁크 안에서 다음 명령을 실행하십시오 :
이 명령은 r5-r6을 experimental 브랜치와 비교하여 현재 위치에 적용합니다. 불행하게도, Subversion은 병합이 적용된 것을 쉽게 추적 할 수있는 방법이 없으므로 조심하지 않으면 동일한 변경을 두 번 적용 할 수 있습니다. 계획된 기능이지만 현재 조언은 r5-r6을 기본으로 병합했음을 알려주는 변경 로그 메시지를 유지하는 것입니다.
VCS는 변경 사항을 파일의 다른 부분에 자동으로 병합 할 수 있습니다. Joe는 계란을 제거하고이를 치즈 (-eggs, + 치즈)로 대체하기를 원하며 Sue는 계란을 핫도그 (-eggs, + 핫도그)로 대체하려고합니다.
이 시점에서 경주가 있습니다. Joe가 먼저 체크인하면 변경 사항이 적용됩니다 (그리고 Sue는 변경을 할 수 없습니다).
변경 사항이 겹쳐서 이와 같이 모순되면 VCS가 충돌을보고하고 체크인을 허용하지 않습니다. 이 딜레마를 해결하는 최신 버전을 확인하는 것은 사용자의 몫입니다. 몇 가지 접근법 :
변경 사항을 다시 적용하십시오. 최신 버전 (r4)에 동기화하고 변경 사항을이 파일에 다시 적용하십시오. 이미 치즈가있는 목록에 핫도그를 추가하십시오. 자신의 변경 사항을 무시하십시오. 최신 버전 (r4)을 확인하고 버전을 복사 한 다음 버전을 확인하십시오. 사실상 치즈가 제거되어 핫도그로 바뀝니다.
갈등은 드물지만 고통이 될 수 있습니다. 일반적으로 최신 정보로 업데이트하고 변경 사항을 다시 적용합니다.
누가 버전 제어 시스템을 웹 2.0과 호환 될 것이라고 생각했을까요? 많은 시스템이 쉽게 참조 할 수 있도록 모든 개정을 태그 (레이블) 할 수 있습니다. 이렇게하면 특정 빌드 번호 대신 "릴리스 1.0"을 참조 할 수 있습니다.
Subversion에서 태그는 편집하지 않기로 동의하는 지점입니다. 그들은 후계자를위한 것이므로 버전 1.0 릴리스에 포함 된 내용을 정확히 볼 수 있습니다. 따라서 그들은 스텁에서 끝납니다 - 갈 곳이 없습니다.
실제 예제 : Windows 소스 코드 관리.
우리는 Windows가 공유 폴더에서 관리되었다고 추측했지만 그렇지 않습니다. 그럼 어떻게 됐어?
안정적인 Windows 빌드가있는 메인 라인이 있습니다. 각 그룹 (네트워킹, 사용자 인터페이스, 미디어 플레이어 등)에는 새로운 기능을 개발할 자체 지사가 있습니다. 이들은 개발 중이며 주전보다는 덜 안정적입니다.
지점에 새 기능을 개발하고이를 "Reverse Integrate (RI)"로 바꾸어 Main으로 가져옵니다. 나중에 "전달 통합"을 사용하여 Main의 최신 변경 사항을 지사로 가져옵니다.
우리가 Media Player 10 및 IE 6에 있다고 가정 해 봅시다. Media Player 팀은 자체 지사에서 버전 11을 만듭니다. 테스트 준비가 완료되면 10-11의 패치가 Main에 적용됩니다 ( "쌀"예제와 비슷하지만 좀 더 복잡함). 이것은 분기에서 트렁크로의 역 통합입니다. IE 팀도 같은 일을 할 수 있습니다.
나중에 Media Player 팀은 IE와 같은 다른 팀의 최신 코드를 선택할 수 있습니다. 이 경우 Media Player는 메인에서 최신 패치를 통합하여 해당 지점으로 가져옵니다. 이것은 "Bread"기능을 실험실로 가져 오는 것과 같지만, 다시 말하면 더 복잡합니다.
그래서 그것은 RI와 FI입니다. 네 네. 이렇게하면 주 코드에서 새 코드를 유지하면서 분기 전반에 걸쳐 변경 사항을 필터링 할 수 있습니다. 멋지다, 응?
실제로, RI에 도착할 때를 결정하는 품질 척도와 함께 많은 지점과 하위 지점이 있습니다. 하지만 브랜치를 사용하면 복잡성을 관리하는 데 도움이됩니다. 이제 가장 큰 소프트웨어 프로젝트 중 하나가 어떻게 구성되는지에 대한 기초를 알게되었습니다.
주요 테이크 아웃.
내 목표는 버전 제어 시스템에 대한 높은 수준의 생각을 공유하는 것이 었습니다. 기본 사항은 다음과 같습니다.
버전 컨트롤을 사용하십시오. 진지하게, OS를 작성하지 않더라도 좋은 일입니다. 그것은 백업만으로도 가치가 있습니다. 천천히 해. 나는 지금 내 프로젝트를 위해 분기하고 합병하는 것에 만 집중하고있다. 그냥 버전 제어를 사용하여 핸들을 얻고 거기에서 이동하십시오. 소규모 프로젝트의 경우 분기 / 병합이 문제가되지 않을 수 있습니다. 대규모 프로젝트는 종종 지점과 패치를 추적하는 관리자를 경험했습니다. 계속 공부하다. SVN, CVS, RCS, Git, Perforce 또는 사용중인 모든 시스템에 대한 안내서가 많이 있습니다. 중요한 점은 개념을 알고 모든 시스템이 고유 한 용어와 철학을 가지고 있다는 것입니다. 에릭 싱크 (Eric Sink)는 상세한 버전 컨트롤 가이드도 가지고있다.
이것들은 기본입니다. 시간이 흐르면서 나는 내 프로젝트에서 배운 구체적인 교훈을 나눌 것입니다. 이제 일반 VCS를 알아 냈으므로 분산 버전 제어에 대한 그림이있는 가이드를 사용해보십시오.
이 시리즈의 다른 게시물.
회신을 남겨주세요.
416 "비주얼 컨트롤 버전 컨트롤"에 대한 의견
나는 금요일을 절대적으로 좋아하지만이 기사는 이미 내 하루를 보냈다! 이것을 정리해 주셔서 감사합니다. & # 8230; 오늘 나중에이 책을 읽으셔야 할 것입니다.
[& # 8230;] 버전 컨트롤에 대한 비주얼 가이드 SVN 예제 [& # 8230;]가있는 버전 컨트롤에 대한 설명이 포함 된 시각적 가이드
멋진 기사 Khalid, 그리고 Eric의 기사에 대한 링크에 감사 드리며, 그들은 역시 좋았습니다!
두 가지 모두 언급 한 태깅 및 브랜칭 접근 방식을 테스트 할 예정입니다. 즉, 이전 버전의 브랜치를 새 폴더로 체크 아웃 할 수 있습니다. & # 8230; 버그 수정을 수행하고 브랜치에 다시 체크인하여 보다 통제되고 추적 가능한 방식입니다. 그런 다음 버그 수정을 현재 트렁크에 병합해야합니다 (마지막 버전 이후의 개발 작업).
다음은 SVN과 소스 제어를위한 유용한 리소스입니다. svnbook. red-bean /
안녕 Carlton, 들러 주셔서 고마워! 그래도 새로운 개발을하면서 라이브 버전을 쉽게 편집 / 업데이트 할 수 있도록 내 자신의 분기 / 병합 체계를 연구 중입니다. 통찰력이 있으면 알려주세요. :)
안녕하세요. Mark, 의견 및 링크에 감사드립니다. & # 8212; 이전에는 SCM을 보지 못했습니다.
와우 .. 너 숨쉬는 민트 야!
생명을 구하는 사람은 정확해야합니다. 저는 하루 종일 이런 사람을 찾고있었습니다.
그것은 아주 맛있었습니다. 고맙습니다.
고마워요! 음식 테마 (생명의 은인, 맛있는 기사)로 무슨 일이 일어나고 있는지 확신 할 수 없지만 나는 기꺼이 행복해한다. :)
(편집 : 와우, 나는 음식 아이템이 내가 사용한 예를 잊어 버렸을 정도로 여러 번 기사를 다시 읽고 있었다! 그들은 단지 나에게 일련의 단어가되었다.)
훌륭한 기사. 다이어그램 작성에 어떤 도구를 사용했는지 궁금합니다.
개요 주셔서 감사합니다. 정말 내가 기본을 이해하는 데 도움이. :)
저는 1 년 넘게 svn을 사용하여 저는 그것을 좋아합니다. 그 상쾌한 혀를 가져 주셔서 감사합니다, 그것은 초보자를위한 진정한 즐거움을 배우게합니다.
그 깔끔한 그래픽을 어디에서했을까요?
[& # 8230;] 시각적 인 버전 관리 안내서 | BetterExplained (태그 : subversion svn 프로그래밍 버전 컨트롤 가이드 도구 scm 참조 하우투 튜토리얼 webdev) [& # 8230;]
[& # 8230;] 그룹으로 프로젝트를 개발하는 경우 버전 관리가 필수적입니다. 다음은 버전 관리를 설명 할 때 더 잘 수행 할 수있는 웹 사이트입니다. 버전 관리에 대한 시각적 가이드 [& # 8230;]
[& # 8230;] 버전 관리 버전 정보 제어 (일명 개정 제어, 소스 제어라고 함)에 대한 시각적 가이드를 사용하면 시간이 지남에 따라 파일을 추적 할 수 있습니다. 너 왜 신경 쓰냐? 그래서 엉망이되면 이전 작업 버전으로 쉽게 돌아갈 수 있습니다. (태그 : 개발 가이드 subversion versioncontrol) [& # 8230;]
[& # 8230;] Betterexplained에서 버전 관리에 대한 훌륭한 기사가 있습니다. 그것에 대해 거의 또는 전혀 모르는 경우, 이것은 당신을 흥미롭게하는 훌륭한 입문서입니다. 코멘트 게시 | 트랙백 URI [& # 8230;]
[& # 8230;] 시각적 인 버전 관리 안내서 | 더 나은 설명 (태그 : svn subversion 프로그래밍 버전 제어 가이드 도구 **) [& # 8230;]
[& # 8230;] 아티스트 유형에 대한 버전 관리에 대한 매우 간단하고 간단한 소개입니다. betterexplained / articles / a-visual-guide-to-version-control / [& # 8230;]
[[# 8230;] 저는이 사이트에 Version Control에 대한 비주얼 가이드가있었습니다. 하지만 Ruby on Rails, 자연 로그, 그리고 숫자, 프로그래밍, 비즈니스 및 커뮤니케이션과 관련된 다른 주제에 관한 기사도 있습니다. 나는 관심을 보였다. [& # 8230;]
안녕 모두, 의견 주셔서 감사합니다. 비밀 소스를 알고 싶습니까? Microsoft 그림판.
농담 :). PowerPoint 2007에서는 다양한 모양을 그려 적절히 배열하고 스타일을 지정하여 다이어그램을 만듭니다. 원할 경우이 기사를 확인하십시오.
및 해당 PowerPoint 파일 :
그렇습니다. 같은 질문을 던졌습니다. 그 덕분에 멋진 web2.0ish 그래픽을 만들기 위해 어떤 도구를 사용 했습니까?
멋진 읽기, 함께 이걸 넣어 주셔서 감사합니다.
[& # 8230;] 시각적 인 버전 관리 안내서 | BetterExplained (태그 : 튜토리얼 프로그래밍 참조) [& # 8230;]
Kalyan : 저는 PowerPoint 2007 & # 8212; 위의 의견 # 14에 자세한 내용이 있습니다.
venki : 코멘트 주셔서 감사합니다, 그것은 많은 재미를 작성합니다.
이 시리즈에서.
사이트 정보.
BetterExplained는 450k 월간 독자들에게 친절하고 통찰력있는 수학 강좌를 제공합니다 (그 이상).

버전 개정 관리 전략
App Store를 통해 가져 오기 우리의 응용 프로그램 에서이 게시물을 읽으십시오!
분기 전략 [닫힘]
내가 현재 일하고있는 회사는 현재의 브랜치 모델에 문제가 있기 시작했으며 지역 사회에 어떤 종류의 분기 전략이 노출되어 있는지 궁금합니다.
상황에 따라 좋은 것이 있습니까? 귀하의 회사는 무엇을 사용합니까? 장점과 단점은 무엇입니까 ??
casperOne이 (가) 건설적이지 않은 것으로 마감 24 Feb '12, 19:53.
현재이 질문은 Q & A 형식에 적합하지 않습니다. 우리는 답변이 사실, 참고 문헌 또는 전문 지식에 의해 뒷받침 될 것으로 기대하지만, 이 질문은 논쟁, 논쟁, 여론 조사 또는 확장 토론을 유도 할 것입니다. 이 질문을 개선하고 다시 열 수 있다고 생각되면 도움말 센터를 방문하여 안내를 받으십시오. 이 질문을 도움말 센터의 규칙에 맞게 수정하려면 질문을 수정하십시오.
17 답변.
좋은 성공과 함께 과거에 사용한 방법은 다음과 같습니다.
/ 트렁크 - 출혈 가장자리. 코드의 다음 주요 릴리스. 주어진 시간에 작동하거나 작동하지 않을 수 있습니다.
/branches/1.0, 1.1 등 안정적인 코드의 분기. 버그를 수정하고 새 릴리스를 안정화하는 데 사용됩니다. 유지 보수 지점 인 경우 해당 시점에 컴파일하고 (해당되는 경우) QA / 출하 준비를해야합니다. 안정화 브랜치의 경우 컴파일이 완료되고 기능이 완료되어야합니다. 새로운 기능을 추가하거나, 리팩터링을하지 않으며, 코드를 정리하지 않아야합니다. 안정화 분기와 유지 보수 분기를 나타내는 사전 접 두부를 추가 할 수 있습니다.
/ branches / cool_feature. 트렁크 (또는 유지 보수 지점)로 만들거나 만들지 않을 수있는 고도의 실험적 또는 파괴적인 작업에 사용됩니다. 코드 컴파일, 작동 또는 기타 정상적으로 작동하는 코드에 대한 보장이 없습니다. 메인 라인 브랜치에 병합하기 전에 가능한 한 최소 시간 동안 지속되어야합니다.
/tags/1.0.1, 1.0.2, 1.1.3a 등. 패키지 된 & amp; 출하 된 출시. 절대로 변하지 않습니다. 원하는만큼의 태그를 만들지 만 변경할 수는 없습니다.
이 문제에 대한 에릭 싱크 (Eric Sink)의 의견을 읽는 것이 좋습니다.
저는 Eric처럼 그가 말하는 "폴더"스타일의 분기를 선호합니다.
브랜드 애플 턴의 스트리밍 라인 : 병렬 소프트웨어 개발을위한 브랜칭 패턴을 참조하십시오. 그것은 중무기이지만 분지에 대한 지식의 폭과 깊이에 관해서는 그것을 능가하는 것을 보지 못했습니다.
우리 저장소는 다음과 같습니다.
/ 트렁크가 당신의 표준, 출혈 가장자리 개발입니다. CI를 사용하므로 항상 테스트를 작성하고 통과해야합니다.
/ branches 이것은 우리가 '승인 된'큰 변화를 두는 곳입니다. 즉, 우리가 알고있는 어떤 것이 트렁크에 들어가지만, 약간의 작업이 필요할 수도 있고 CI를 깨뜨릴 수도 있습니다. 또한 자체 CI 프로젝트가있는 유지 관리 릴리스에서 작업합니다.
/ sandbox 각 개발자는 자신의 샌드 박스와 공유 샌드 박스를 가지고 있습니다. 이는 실제 작업을 수행하지 않을 때 수행하는 "LINQ 공급자를 제품에 추가 할 수 있도록 허용"과 같은 작업을위한 것입니다. 결국 트렁크에 들어갈 수도 있지만 그렇지 않을 수도 있습니다. 하지만 버전 제어가 있습니다. 여기에 CI가 없습니다.
/ 벤더 표준 벤더 브랜치는 우리가 컴파일하는 곳의 프로젝트를위한 것이지만 우리가 유지 관리하는 코드는 아닙니다.
/ ccnet 이것은 CI 태그입니다. CI 서버 만이 여기에 쓸 수 있습니다. Hindsight는 CI, BUILDS 등과 같이 좀 더 일반적인 이름으로 이름을 바꾸라고 말했을 것입니다.
활성 개발을위한 하나의 브랜치 (전문 용어에 따라 / main 또는 master) 각 유지 관리 릴리스마다 하나의 브랜치 -> 모든 주요 개발이 / main으로가는 반면 아주 작은 수정 만 받음 ​​새로운 태스크마다 하나의 브랜치 : Bugzilla / Jira / Rally의 모든 새로운 항목을 작업하는 새로운 지점. 커밋을하고, 자갈 체크섬을 사용하여 변경 사항을 자체 문서화하고, 완료되고 잘 테스트 된 경우에만 "상위"분기로 다시 병합합니다.
첫 번째 : 키스 (간단하게 멍청한 상태로 유지하십시오!)
* 1) 유지할 수있는 버전 유지 - 예 : 서비스 팩, 핫픽스, 필요한 경우 트렁크에 병합 될 수있는 버그 픽스 * 2) major. minor. build. revision.
태그 폴더를 체크 아웃 할 필요는 없습니다. 릴리스 브랜치에서 코딩을 거의하지 않으면 서 병합이 간단 해집니다. 코드 정리 등을하지 마십시오. 태그 폴더를 코딩하지 마십시오. 구체적인 버전 정보를 소스 파일에 넣지 마십시오. 플레이스 홀더 또는 0.0.0.0을 사용하여 빌드 메카니즘을 빌드하고있는 버전 번호로 바꾸십시오. 써드 파티 라이브러리를 소스 컨트롤에 넣지 마십시오 (또한 아무도 STL, MFC 등 라이브러리를 SVN에 추가하지 않습니다 ;-)) 만 하드 코드 된 경로 (절대 경로 및 상대 경로) 대신 환경 변수 사용
최종 품질 보증을 위해 릴리즈가 준비되면 우리는 분기합니다. 품질 보증 프로세스 중에 문제가 발견되면 해당 버그는 지점에서 수정되고 유효성이 확인 된 다음 트렁크에 병합됩니다. 지점이 QA를 통과하면 출시로 태그를 지정합니다. 해당 릴리스의 모든 핫픽스는 또한 분기에 대해 수행되고 유효성 검사가 수행되며 트렁크에 병합 된 다음 별도의 릴리스로 태그가 지정됩니다.
폴더 구조는 다음과 같습니다 (1 QA 라인, 2 개의 핫픽스 릴리스 및 트렁크).
야생, 야생, 서쪽 스타일의 git-branches를 사용합니다. 컨벤션으로 정의 된 잘 알려진 이름을 가진 가지가 있지만 우리의 경우 회사의 프로세스 정책 요구 사항을 충족시키기 위해 실제로 태그가 더 중요합니다.
아래에서 Subversion을 사용하는 것을 보았으므로 Subversion Book에서 분기하는 부분을 확인해야한다고 생각합니다. 특히 지점 유지 관리 및 공통 지점 패턴의 "저장소 레이아웃"섹션을 살펴보십시오.
여기서 내가 보지 못하는 대안은 "변화에 맞서기"철학입니다.
트렁크에 "와일드 웨스트"가있는 대신 트렁크가 "현재 릴리스"이면 어떻게 될까요? 이것은 웹 사이트와 같이 한 번에 하나의 응용 프로그램 버전 만 릴리스 될 때 잘 작동합니다. 새로운 기능이나 버그 수정이 필요할 때 해당 변경 사항을 보관하기 위해 지점이 만들어집니다. 종종 수정 프로그램을 개별적으로 릴리스 할 수있게 해주 며 카우보이 코더가 실수로 의도하지 않은 기능을 추가하는 것을 방지합니다. (종종 백도어 - "개발 / 테스트 용")
벤 콜린스 (Ben Collins)의 조언은 상황에 따라 어떤 스타일이 효과가 있을지를 결정하는 데 매우 유용합니다.
Henrik Kniberg의 여러 Agile 팀을위한 Version Control에는 고려해야 할 몇 가지 좋은 점도 있습니다.
우리는 현재 "새 이니셔티브"를위한 한 가지 지사를 유지 관리를 위해 하나의 지회를두고 있는데, "미래의 언젠가는 나올 것"이라는 의미입니다. 또한 현재 두 개의 유지 보수 지점을 운영하고 있는데, 하나는 현재 생산중인 제품과 QA에있는 제품을 수정하는 것입니다.
우리가 보아 왔던 가장 큰 장점은 사용자 요청 및 응급 상황에보다 신속하게 대응할 수 있다는 것입니다. 프로덕션에있는 지점에서 수정을 수행하고 이미 체크인되었을 수있는 추가 항목을 릴리스하지 않고 릴리스 할 수 있습니다.
가장 큰 단점은 지점 간 병합을 많이하게되어 결국 뭔가 잘못되거나 병합 될 가능성이 높아진다는 것입니다. 지금까지 문제는 아니지만 분명히 명심해야 할 것이 있습니다.
이 정책을 수립하기 전에 우리는 일반적으로 트렁크에서 모든 개발 작업을 수행했으며 코드를 공개 할 때만 분기했습니다. 그런 다음 필요에 따라 해당 지점에 대한 수정 작업을 수행했습니다. 그것은 더 간단했지만 유연하지는 않았습니다.
제프 앳 우드 (Jeff Atwood)는 좋은 블로그 게시물에 이렇게 적었습니다. 해당 게시물에 몇 가지 중요한 링크가 있습니다.
Gnat은 분기 전략에서 찾을 수있는 다양한 조언에 대해 이렇게 우수한 분석을 작성했습니다.
분기 전략이 하나도 없으며 다음과 같은 기능을 제공합니다.
팀 크기 제품 및 라이프 사이클 기간 사용중인 기술 (웹, 내장, Windows 응용 프로그램) 소스 컨트롤 힘내, TFS, Hg.
제프 앳 우드의 게시물은 많은 가능성을 무너 뜨립니다. 추가 할 또 다른 개념은 승진의 개념입니다 (Ryan Duffield의 링크에서). 이 설정에서는 dev 브랜치, test bracnh 및 release 브랜치가 있습니다. 릴리스 브랜치에 도달하여 배포 될 때까지 코드를 승격시킵니다.
우리가 일하는 철학은 트렁크를 사이트에 과격한 피해없이 언제든지 밀어 넣을 수있는 상태로 유지하는 것입니다. 이것은 트렁크가 항상 완벽한 상태에 있다고 말할 수는 없습니다. 물론 버그가있을 것입니다. 그러나 요점은 그것을 절대로 부숴 버릴 수 없다는 것입니다.
추가 할 기능이있는 경우 분기하십시오. 디자인 변경, 지점. "오랜 시간이 걸리지 않을 트렁크에서이 작업을 할 수 있습니다."라고 생각한 곳이 너무 많았습니다. 그런 다음 5 시간 후에 나는 물건을 깨뜨리는 버그를 파악할 수 없었습니다. 정말로 내가 갈라 놓았 으면 좋겠다.
트렁크를 깨끗하게 유지하면 버그 수정을 빠르게 적용하고 푸시 할 수 있습니다. 당신은 당신이 편리하게 갈라 놓은 깨진 코드에 대해 걱정할 필요가 없습니다.
이것은 사용중인 버전 제어 시스템에 따라 다릅니다. 각 VCS에는 분기에 대한 다양한 접근 방식이 있습니다.
어떤 VSC를 사용합니까?
Subversion의 경우 Ryan Duffield의 의견에 동의합니다. 그가 언급 한 장은 사용할 시스템에 대한 좋은 분석을 제공합니다.
내가 요청한 이유는 Perforce가 SVN 또는 CVS에서 분기를 생성하는 완전히 다른 방법을 제공한다는 것입니다. 또한 분기에 대한 철학을 전하는 모든 DVCS가 있습니다. 분기 전략은 사용중인 도구에 따라 결정됩니다.
FYI, Svnmerge. py는 SVN에서 분기를 병합하는 것을 지원하는 도구입니다. 자주 사용하면 (10-30 초마다) 커밋됩니다. 그렇지 않으면 도구가 혼란 스러울 수 있습니다.
어떤 분기 패턴을 선택하든 다음과 같이 분기를 2 진 트리 형식으로 유지해야합니다.
하위 노드는 직접 상위 노드와 병합해야합니다. 부모 분기를 사용하여 전체 분기 만 병합하는 것이 좋습니다. 지점 내의 하위 폴더는 병합하지 마십시오. 전체 분기에서 병합하고 선택하는 경우 필요한 경우 체리를 선택할 수 있습니다. 위의 그림에서 다음 분기는 설명을위한 것일 뿐이므로 필요하지 않을 수도 있습니다.

콩 줄기 안내.
목차.
당신이 버전 통제에 흥미 있고, 그러나 점프를 아직 만들지 않은 경우에, we†™ ve가 들리는 일반적인 이유는 그것이 혼란스럽게 보이는 방법이다. 버전 관리를 처음 사용하는 경우 시작하는 가장 좋은 장소는 기본 개념입니다.
버전 관리가 중요한 이유는 무엇입니까?
당신이 이것을 읽는 경우에, 당신은 index-v12-old2.html 같이 무언가를 보는 문서를 새롭게하고 있다는 것을 가능한 그것 †™ 가능하다. Let†™ s는 이것에서 멀리 떨어져 당신이 당신의 원시 코드 및 파일을 통제하는 것을 허용 할 것이 아니라, 팀으로 더 생산적이게 될 것입니다. 익숙하다면 :
업데이트 정보를 통해 팀과 연락합니다. 프로덕션 서버에서 직접 업데이트했습니다. 실수로 다시 검색 할 수없는 일부 파일을 덮어 씁니다.
이제 다음을 기대할 수 있습니다.
모든 팀 구성원에 대해 일관된 파일 이름 및 디렉토리 구조 자신감을 가지고 변경하고 필요할 때 되돌릴 수도 있습니다. 팀의 커뮤니케이션 매체로 소스 제어를 사용합니다. 다른 버전의 코드를 준비 또는 프로덕션 서버에 쉽게 배포 할 수 있습니다. 누가 변경을했는지와 언제 일어 났는지 이해하십시오.
기본 개념.
추적 변경.
버전 제어 시스템은 주로 디렉토리 또는 파일 내에서 발생하는 변경 사항을 추적하는 하나의 개념을 기반으로합니다. 버전 제어 시스템에 따라 파일에서 특정 문자 또는 바이트가 변경되었음을 알게 된 것으로 변경된 사실을 알 수없는 경우가 있습니다.
대부분의 경우 버전 제어를 통해 변경 내용을 추적해야하는 디렉터리 또는 파일 집합을 지정합니다. 이는 호스트에서 저장소를 체크 아웃 (또는 복제)하거나 소프트웨어에 버전 제어하에있는 파일을 알려줌으로써 발생할 수 있습니다.
버전 제어하에있는 파일 또는 디렉토리 세트는 더 일반적으로 저장소라고합니다.
변경 사항을 적용하면 장면 뒤에서 각 변경 사항을 추적합니다. 변경 사항을 커밋 할 준비가 될 때까지 프로세스가 사용자에게 투명 해집니다.
커밋.
버전 제어하에있는 파일로 작업 할 때마다 각 변경 사항이 자동으로 추적됩니다. 여기에는 파일 수정, 디렉토리 삭제, 새 파일 추가, 파일 이동 또는 파일 상태를 변경할 수있는 다른 작업이 포함될 수 있습니다. 각 변경 사항을 개별적으로 기록하는 대신 버전 제어 시스템은 변경 사항을 단일 조치 모음으로 제출할 때까지 기다립니다. 버전 제어에서이 작업 콜렉션을 커밋이라고합니다.
수정 및 변경 집합.
커밋이 이루어지면 변경 사항은 변경 집합으로 기록되고 고유 한 수정 버전이 제공됩니다. 이 개정은 시스템에 따라 증분 된 숫자 (1, 2, 3) 또는 고유 한 해시 (예 : 846eee7d92415cfd3f8a936d9ba5c3ad345831e5) 형태 일 수 있습니다. 변경 세트의 개정을 알면 나중에 쉽게 보거나 참조 할 수 있습니다. changset은 커밋 한 사람, 변경된 시점, 영향을받는 파일 또는 디렉토리, 주석 및 파일 (코드 줄)에서 발생한 변경 사항에 대한 참조를 포함합니다.
협업에 관해서는 과거의 개정판과 체인지 세트를 보는 것이 프로젝트가 진화하고 팀원 코드를 검토하는 데 유용한 도구입니다. 각 버전 제어 시스템에는 저장소의 각 개정 및 변경 집합의 전체 기록 (또는 로그)을 볼 수있는 형식화 된 방법이 있습니다.
업데이트를 얻는 중.
팀 구성원이 변경 사항을 적용하면 최신 버전을 보유하는 것이 중요합니다. 최신 버전을 사용하면 충돌 가능성이 줄어 듭니다. 저장소에서 최신 변경 사항을 가져 오는 것은 다른 컴퓨터 (일반적으로 호스트되거나 중앙화 된 서버)에서 풀링 또는 업데이트하는 것만 큼 간단합니다. 업데이트 또는 끌어 오기가 요청되면 마지막 요청 이후의 변경 사항 만 다운로드됩니다.
최신 업데이트 또는 커밋이 충돌하는 경우 어떻게해야합니까? 즉, 변경 사항이 다른 팀 구성원이 버전 제어 시스템에서 정확하고 권위있는 변경 사항을 결정할 수 없다는 변경 사항과 매우 유사하면 어떻게됩니까? 대부분의 경우 버전 제어 시스템은 충돌 버전 간의 차이점을 볼 수있는 방법을 제공하여 사용자가 선택을 할 수 있도록합니다. 파일을 수동으로 편집하여 옵션을 병합하거나 하나의 개정이 다른 개정보다 우선하도록 허용 할 수 있습니다. 당신은 다른 커밋을 한 사람과 협력하여 자신의 중요한 일을 취소하지 않는 you†™ re를 확인하기를 원할 수 있습니다!
Diffing (또는 차이점보기)
각 커밋은 파일 또는 파일 및 디렉토리 집합에 대한 변경 사항으로 기록되므로 수정 사이에 변경된 내용을 보는 것이 유용 할 때가 있습니다. 예를 들어 웹 사이트의 최근 배포가 중단되고 특정 파일에 대한 원인을 좁히는 경우 취할 수있는 최선의 조치는 해당 파일에서 최근에 변경된 내용을 확인하는 것입니다. diff를보고 두 파일 또는 파일 세트를 비교하여 변경된 코드 행, 변경된 행 및 변경된 행을 볼 수 있습니다. 대부분의 버전 제어 도구를 사용하면 두 개의 순차적 리비전을 비교할 수 있지만 히스토리의 어느 위치에서든 두 개의 리비전을 비교할 수 있습니다.
분기 및 병합.
코드에서 변경 사항을 실험하거나 변경 사항을 커밋 (예 : 새 기능 작업)하려는 경우가 있습니다. 이 코드를 주 파일 집합 (보통 트렁크 또는 마스터라고 함)에 직접 커밋하는 대신 분기라는 것을 만들 수 있습니다. 브랜치를 사용하면 기본 세트를 변경하지 않고 병렬로 수정할 수있는 저장소의 사본 (또는 스냅 샷)을 작성할 수 있습니다. 다른 사람이 트렁크 또는 마스터에게 변경 사항을 적용하지 않고 커밋하는 동안 작업 할 때 계속해서 분기에 대한 새 변경 내용을 커밋 할 수 있습니다.
실험 코드에 익숙해지면 트렁크 또는 마스터의 일부로 다시 만들 수 있습니다. 버전 관리 시스템은 지금까지 모든 변경 사항을 기록했기 때문에 각 파일이 어떻게 변경되었는지 알고 있습니다. 분기를 트렁크 또는 마스터 (또는 다른 분기)와 병합하면 버전 제어 도구가 각 파일과 코드 행을 자동으로 병합하려고 시도합니다. 분기가 병합되면 트렁크 또는 마스터를 최신 파일로 업데이트합니다.
예를 들어 let†™는 웹 사이트의 새로운 레이아웃을 실험하고 싶다고 말합니다. 많은 파일에서 많은 변경이 필요하고 기존 코드가 손상 될 수 있으며 예상대로 작동하지 않을 수 있습니다. 또한 시간이 오래 걸릴 수 있으므로 변경 사항을 계속 커밋하고 싶습니다. 트렁크 또는 마스터 파일 집합에 커밋하는 대신 분기를 만듭니다. 이 시점부터 새로운 지점에서 변경 한 내용은 트렁크 또는 마스터의 다른 사람에게 영향을 미치지 않습니다. 며칠이나 몇 주가 지나면 변경 사항을 적용하고 테스트하고 조정할 수 있습니다. 새로운 레이아웃이 제대로 작동하고 결과가 마음에 들면 사이트의 영구적 인 부분이 될 준비가 된 것입니다. 이것은 지점을 트렁크 또는 마스터와 병합 할 지점입니다. 병합이 완료되면 브랜치의 변경 사항을 트렁크 또는 마스터의 최신 버전과 결합합니다.
경우에 따라 버전 제어 시스템은 병합을 수행 할 때 두 개정 사이에 적용 할 변경 사항을 파악하지 못할 수도 있습니다. 이 경우 충돌이 발생합니다. 이 시나리오의 충돌은 위에서 언급 한 충돌과 동일하며 수동 개입을 통해 어떤 파일이나 코드 줄이 남아 있는지 결정해야합니다.
버전 제어 시스템의 유형.
3 가지 가장 많이 사용되는 버전 제어 시스템은 중앙 집중식 및 분산 형 (분산 형이라고도 함)의 두 가지 주요 범주로 나뉩니다.
중앙 집중식 버전 제어.
이 글을 쓰는 시점에서 가장 인기있는 버전 제어 시스템은 Subversion으로 알려져 있습니다. Subversion은 중앙 집중식 버전 제어 시스템으로 간주됩니다. 중앙 집중식 시스템의 주요 개념은 클라이언트와 서버 관계에서 작동한다는 것입니다. 저장소는 한 곳에 있으며 많은 클라이언트에 대한 액세스를 제공합니다. It†™ s는 당신이 FTP 서버에 연결하는 FTP 클라이언트가있는 곳에 FTP와 아주 유사하다. 모든 변경 사항, 사용자, 커밋 및 정보는 중앙 저장소에서 보내고 받아야합니다.
Subversion의 주요 이점은 다음과 같습니다.
이해하기 쉽습니다. 사용자와 액세스를 더 많이 제어 할 수 있습니다 (한 곳에서 제공되기 때문에). 더 많은 GUI & amp; IDE 클라이언트 (Subversion은 더 오래 사용되었습니다). 시작하기 간단합니다.
동시에 Subversion에는 몇 가지 단점이 있습니다.
서버에 대한 액세스에 따라 다릅니다. 서버와 백업을 관리하기가 어렵습니다. (물론 Beanstalk이 아닙니다!) 모든 명령이 서버에 연결되기 때문에 속도가 느려질 수 있습니다. 분기 및 병합 도구는 사용하기가 어렵습니다.
분산 버전 제어.
분산 시스템은 새로운 옵션입니다. 분산 버전 제어에서 각 사용자는 파일뿐만 아니라 기록도 포함하여 전체 저장소의 자체 복사본을 가지고 있습니다. 개별 리포지토리의 네트워크라고 생각하십시오. 대부분의 경우 모델이 배포 되더라도 Beanstalk와 같은 서비스는 변경 사항을 공유하는 기술적 과제를 단순화하는 데 사용됩니다. 가장 널리 사용되는 분산 버전 제어 시스템은 Git과 Mercurial입니다.
Git과 Mercurial의 주요 이점은 다음과 같습니다.
더 강력하고 상세한 변경 추적 기능으로 충돌이 줄어 듭니다. 서버를 필요로하지 않습니다. 공유 저장소를 제외한 모든 작업은 로컬입니다 (오프라인으로 설정). 분기 및 병합은보다 안정적이므로 더 자주 사용됩니다. 빠른 It†™ s.
동시에 Git과 Mercurial에는 몇 가지 단점이있다.
분산 모델은 이해하기가 더 어렵습니다. 새로운 It†™ s 이렇게 많은 GUI 클라이언트 아닙니다. 수정본은 증분 번호가 아니기 때문에 참조하기가 더 어려워집니다. 모델에 익숙하지 않으면 실수를하는 것이 더 쉬울 수 있습니다.
어느 것이 당신에게 옳은가? 이것은 실제로 어떻게 일하는가에 달려 있습니다. 방금 시작한 경우 Subversion을 사용하는 것이 좋습니다. 명령 줄에 익숙하지 않거나 많은 분기 및 병합을 계획하지 마십시오. 그렇지 않으면, 우리는 당신이 힘내 또는 의욕적 인 시도하고 당신이 그것을 좋아하는지보십시오 것이 좋습니다. Beanstalk을 사용하면 전환 호스트없이 필요에 따라 앞뒤로 자유롭게 이동할 수 있습니다.
Chris Nagele은 필라델피아 출신의 Wildbit 설립자입니다.
지금 Beanstalk를 시도하십시오!
가입하고 분만에 시작하십시오.
아직도 몇 가지 질문이 있으십니까?
&부; Wildbit, LLC, 2007-2017. 판권 소유. The Beanstalk logo and name are trademarks of Wildbit, LLC .

Version revision control strategy

As a longtime lover of source control, I've been known to have a few opinions on how to use it. I've generally taken the approach that the tool I use needs to work for me, not against me. Unfortunately with the flexibility of a distributed version control system, such as Git, the right answer isn't always obvious. Taking the time to impose some arbitrary constraints on your workflow will make your daily tasks more predictable, and therefore easier to complete. One of the biggest wins you can make is using a standardized branching pattern for your work. If your team hasn't already "unvented" its own best practices, this article will help you choose an effective workflow for your team.
The different workflows really break down into two simple categories: the first is best described as a scheduled release pattern; the second as continuous deployment . Of course there are a spectrum of options in between, but let's look at the polar opposites for now.
The first option, the scheduled release, is typically used for products which have launch dates and different versions available at any one point in time. For example, Drupal uses a major. minor syntax for its releases. In some scheduled releases, you will also have a smaller “hotfix” release which adds a third set of numbers to the released version. From a branch perspective, this means you have a number of parallel development branches at work. Each time you begin new work, you need to carefully consider your starting point. This branching pattern was popularized by the 2010 blog post describing what is now referred to as the Gitflow Branching Model.
The advantage of the scheduled release is that you always have a safe version of the code you can make a few quick changes to and deploy; the disadvantage is that you have more branches to manage and keep up to date as changes are made. The more things fall out of sync, the more likely you are to have merge conflicts when you do try to incorporate new work. For example: you need to make a quick security patch to your site, and then you need to roll this patch back into the main development line. If there's been a lot of development work since the last release, you may have code conflicts to deal with when you try to apply the same patch to the newer code.
That approach to branching is in stark contrast to the second style of branching commonly used for continuous deployment. As the name suggests, this style is typically used for systems which are already deployed, as opposed to products with a strict release date. In this style the master branch is always kept in a deployment-ready state. Nothing is considered a hotfix, because all changes are urgent and ready for deployment. Typically, this style of development will have permissions (sometimes referred to as “flippers” or “flags”) which turn off all new functionality exposed by the branch except to privileged users. Then, as the code is tested, the flag is reset to expose the functionality to increasingly more people until it is made public. Etsy, Facebook, and Flickr are all rumored to use this deployment pattern. The exact branching pattern varies a little, but you can get the gist of the pattern from The Dymitruk Model.
If you hate dealing with merge conflicts, the continuous deployment strategy can look pretty appealing. But this strategy has its own drawbacks as well. When you are using a continuous deployment strategy, it is assumed that the tip of your master branch is always safe to deploy into production. By design, there isn't a space to include a brief pause (of a day or two) for a quality assurance check of the code, and if there was a problem with the deployed code, you would be relying on tags to know when the last safe deployment of the code was. You'd be stuttering your way back through time to try and find a commit which was solid and deployable, with the time pressure of knowing you had broken code on your production server.
The concept of recovery is an important one in source control. Yes, you need to optimize your workflow so that it is easy to move forward, but you must also consider how quickly you can unravel the past and uncover the source of a regression. The two graphs shown were both relatively tidy; in reality, the graphs for your repository may not be as easy to interpret. The tools you use to untangle the past will also dictate how you commit today. (Do you love bisect? You'll want your commits stored in a specific way to take advantage of it.) I wrote about this in more detail at “The Evolution of Social Coding.” The scheduled release model provides more “life lines” to the past, whereas the continuous deployment model is moving constantly forward with smaller, more granular changes over time.
The correct solution for your team probably lies somewhere on the spectrum between the two strategies. To get a sense of how one Drupal team used variations on these two workflows, take a look at the pre-launch and post-launch workflows the Drupalize. Me team used during its upgrade process from Drupal 6 to Drupal 7.
자세한 내용은:
Getting Started With Services Using Views.
Will The Revolution Be Drupalized?
Web API Alphabet Soup.
로그인하거나 등록하여 의견을 게시하십시오.
Emma Jane Hogbin Westby is the author of Front End Drupal , Drupal User's Guide , and Learning Git for Teams . You can follow her adventures on Twitter at emmajanehw.
Popular tags.
우리 블로그에서.
In Drupal 7 the Field API introduced the concept of swappable field storage .
Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.
Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the.
The entertainment industry is not for the faint of heart.
Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!
Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.
Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.
For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.
Did we have fun in Barcelona?
Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.