«branching» 태그된 질문

리비전 제어에서 분기는 리비전 제어하에있는 객체를 복제하여 두 분기를 따라 수정이 동시에 발생할 수 있습니다.

2
Git Flow와 같은 병합 전략은 실제로 반 패턴입니까?
우리 회사는 Git을 사용하고 있으며 독특한 분기 방식을 사용하고 있습니다. 작업은 마스터에서 수행되며 지점은 릴리스를 위해 예약됩니다. 반복에서 수행 된 모든 작업이 지점으로 들어가는 한 제대로 작동하지만 중요한 생산 문제가 발생하면 작업이 두 지점 모두에서 이루어 지도록해야합니다. 최근에, 우리는 그 지점들과 함께 "재미"를 가지고 있습니다. 관리상의 골칫거리로 모든 작업이 모든 …
10
잘못된 지점에서 일하는 것을 어떻게 피합니까?
주의를 기울이면 일반적으로 문제를 예방할 수 있지만 , 임의의 소스 제어 경로를 확인하여 작업중인 분기 ( 예 : "흠 ... dev분기에 있습니다") 를 다시 확인해야하는 경우가 있습니다. 파일. 더 쉬운 방법을 찾기 위해 솔루션 파일의 이름을 적절하게 지정한다고 생각 했지만 ( 예 :) MySolution_Dev.sln 각 분기마다 파일 이름이 다르면 솔루션 …
6
새 프로젝트에 대한 마스터 링을 언제 중단해야합니까?
새로운 프로젝트가 시작될 때마다 "안정적인"무언가를 얻을 수있을 때까지 마스터에게 직접 커밋하여 시작한 다음, 지점에서 일을 시작하는 것이 좋습니다. 적어도 이것이 내가 정상적으로하는 방법입니다. 두 번째 커밋에서 즉시 분기를 시작하는 방법이 있습니까? 이런 식으로하는 것이 합리적입니까? 분명히, "초기 커밋"은 항상 마스터가되지만, 그 이후에 새로운 기능을위한 브랜치를 만들기 시작하는시기가 언제인지 알 수 …
8
힘내-마스터에 직접 작업하면 어떤 문제가 발생합니까?
git 브랜치 모델에 대한 많은 조언을 보았으며 가장 일반적인 의견은 마스터 브랜치에서 직접 변경하는 것이 좋지 않다는 것입니다. 우리 동료 중 한 명이 마스터 지점에서 직접 변경하는 것을 매우 기쁘게 생각하며 여러 대화에도 불구하고 변경하지 않을 것으로 보입니다. 이 시점에서 나는 마스터에게 직접 일하는 것은 나쁜 습관 인 동료를 설득 …
7
빌드가 거의 항상 깨질 때 효율적으로 유지하는 방법
나는 동일한 소스 코드를 공유하고 지속적인 통합을 유지하는 중소 규모의 팀에서 일하지만 우리 모두가 동일한 지점에서 작업해야하므로 빌드는 거의 항상 중단됩니다. 우리는 또한 깨진 빌드를 완화하기 위해 최근에 도입 된 규칙을 가지고 있는데, 이는 빌드하는 동안 아무도 체크인 할 수 없다는 것을 나타냅니다. 하루 종일 모든 사람들이 체크인 할 수있는 …
4
버전 관리하에 다른 버전의 라이브러리를 어떻게 배치합니까? 태그를 사용하십니까? 아니면 가지? 아니면 다른 방법?
나는 최근에 코드를 버전 제어 (실습, SVN 및 github (명확하게 git))에서 코드를 시작하기 시작했다. 버전 관리를 사용하기 전에 이런 식으로 작업했습니다. 버전 번호가있는 많은 폴더 안에 라이브러리 이름의 폴더가 있습니다. 새로운 버전으로 작업을 시작할 때마다 마지막 버전을 복사하고 이름을 새 버전으로 변경 한 다음 구현을 시작합니다. 그러나 이것은 폴더가 버전 …
5
모든 개발이 브랜치에있을 때 리팩터링하는 방법?
우리 회사에서는 모든 개발 (버그 수정 및 새로운 기능)이 별도의 지점에서 수행됩니다. 완료되면 해당 지점에서 테스트하는 QA에게 전달하고 녹색 표시를 주 지점으로 통합합니다. 이 과정은 하루에서 1 년 정도 걸릴 수 있습니다. 브랜치에서 리팩토링을 짜려고 시도하는 경우 "아웃"기간을 알 수 없으므로 다시 병합 될 때 많은 충돌이 발생할 수 있습니다. …
3
QA 팀은 Gitflow 분기 모델에서 테스트를 수행해야하는 위치
우리는 동일한 git 저장소를 사용하여 여러 프로젝트를 작업하는 큰 팀 (10-12 개발자 및 4 qa)입니다. 스프링 부트 기반 백엔드 웹 서비스입니다. 우리는 좋은 자식 분기 및 배포 전략을 찾고 있습니다. 우리는 또한 우리의 기능이 예상대로 작동하는지 확인하는 qa 팀을 가지고 있습니다 (버그가 어느 정도 무료입니다). 몇 가지 기사를 읽은 후 …
23 testing  git  branching  qa  gitflow 
3
기능 브랜치에서 마스터로 병합하기 전에 코드 검토 전략
나와 팀은 기능 분기 (git와 함께)를 사용합니다. 마스터로 병합하기 전에 코드 검토에 가장 적합한 전략이 무엇인지 궁금합니다. 마스터에서 새 브랜치를 체크 아웃하고 fb_ # 1이라고 부를 수 있습니다. 몇 번 커밋하고 다시 마스터로 병합하고 싶습니다. 내가 병합하기 전에 누군가가 코드를 검토해야합니다 이제 두 가지 가능성이 있습니다. 1 일 나는 병합 …
1
리팩토링은 GitFlow 지점 이름 지정 모델에서 어디에 속합니까?
최근 비트 버킷으로 구현 된 GitFlow 모델 작업을 시작했습니다. 그리고 나에게 완전히 분명하지 않은 것이 있습니다. 리팩토링 작업을 백 로그, 계획 및 구현하여 기술 부채를 정기적으로 해결하려고합니다. 이러한 리팩토링 브랜치는에 병합 된 풀 요청으로 끝납니다 develop. 내 질문은 리팩토링 브랜치가 GitFlow에서 어디에 속합니까 ? feature접두사를 사용 하는 것이 가장 논리적으로 …
4
장기 프로젝트의 제품 버전 관리 및 분기를 처리하는 가장 좋은 방법은 무엇입니까?
일반적으로 제품 수명주기 동안 여러 릴리스가있을 수 있고 이전 제품의 지원이 필요한 장기 프로젝트의 경우 제품 버전 및 코드 기반 분기를 처리하는 가장 좋은 방법은 무엇입니까? 좀 더 구체적으로 말하면, 적절한 분산 버전 관리 (git)가 있고 팀 규모가 크거나 크며 개발자가 한 번에 여러 프로젝트를 수행하고 있다고 가정하십시오. 현재 직면하고있는 …
5
왜 git commit에 그들이 만든 브랜치의 이름이 포함되지 않습니까?
피처 브랜치를 사용하는 팀에서 git으로 작업 할 때 종종 히스토리의 브랜치 구조를 이해하기가 어렵습니다. 예: 기능 분기 기능 / make-coffee 가 있고 기능 분기 와 병렬로 마스터 에서 버그 수정이 계속 되었다고 가정 해 봅시다 . 역사는 다음과 같습니다. * merge feature/make-coffee |\ | * small bugfix | | * …
20 git  branching 
2
자식에서 삭제 된 분기와 이름이 같은 태그를 만드는 것은 나쁜 생각입니까?
nvie의 git-flow 모델을 따르는 git branching 모델이있는 프로젝트가 있습니다. 릴리스 브랜치는 SemVer 형식으로 명명 됩니다. 예 :v1.5.2 릴리스 분기에 생산을위한 녹색 표시등이 제공되면 분기를 마스터로 병합하고 태그를 적용한 후 분기를 삭제하여 분기를 닫습니다. 릴리스 브랜치를 즉시 삭제함에 따라 브랜치에 태그를 지정할 때 동일한 식별자를 사용했습니다. 예 : v1.5.2 릴리스 브랜치를 …
8
가지가 쌓이지 않도록 유지
기능이 테스트 준비를 위해 점점 더 커질수록 문제가 발생하기 시작하지만, 모든 것이 테스트되고 승인 된 새로운 기능이 테스트 준비에 들어갑니다. 이는 테스트 된 기능과 테스트되지 않은 기능이 결합되어 있기 때문에 프로덕션 환경에 거의 도달 할 수없는 환경을 만들고 있습니다. 나는 이것이 일반적인 문제라고 확신하지만 아직 우리에게 좋은 자원을 찾지 못했습니다. …
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.