잘못된 지점에서 일하는 것을 어떻게 피합니까?

27

주의를 기울이면 일반적으로 문제를 예방할 수 있지만 , 임의의 소스 제어 경로를 확인하여 작업중인 분기 ( 예 : "흠 ... dev분기에 있습니다") 를 다시 확인해야하는 경우가 있습니다. 파일.

더 쉬운 방법을 찾기 위해 솔루션 파일의 이름을 적절하게 지정한다고 생각 했지만 ( 예 :) MySolution_Dev.sln 각 분기마다 파일 이름이 다르면 솔루션 파일을 병합 할 수 없습니다.

그다지 큰 문제는 아니지만 올바른 지점에 신속하게 도달하기 위해 사용하는 방법이나 "작은 트릭"이 있습니까? TFS 2008과 함께 Visual Studio 2010을 사용하고 있습니다.

— 헝니
소스

2

이것은 VS 2010 Extension을 작성하기에 좋은 후보처럼 들리며 일종의 구성 가능한 시각적 신호를 통해 분기를 나타낼 수 있습니다. 아마도 사용자 설정에 따라 솔루션 탐색기의 배경을 채색 할 수 있습니다 (개발에는 녹색, 품질 관리에는 노란색, 제품에는 빨간색).

— Jesse C. Slicer

VS 타이틀 바의 표시기조차 도움이 될 것입니다.

— henginy

1

나는 그것이 매우 효과적이라고 말하고 싶습니다. git 브랜치를 포함하도록 bash 프롬프트를 설정하고 소스 파일이 깨끗한 지 또는 체크인이 필요한지 여부

— Daenyth

TFS에 git status또는 이와 동등한 것이 hg status없습니까?

TFS 작업에 VS 사용자 인터페이스를 사용하므로 실제로 아이디어가 없습니다.

— henginy

16

나는 이것을 사용하고 있습니다 http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6

예를 들어 제목을 다음과 같이 업데이트합니다.

개발 \ myproject

또는

메인 \ myproject

또는

\ myproject 출시

그것이 도움이되기를 바랍니다.

— 일곡
소스

그것을 시도하는 것, 나는 그것을 시도 할 것이다 ..

— henginy

이 확장명을 정확히이 목적으로 사용합니다. 사실, 나는 ynnok이 이미 있음을 보았을 때 링크를 게시하려고했습니다.

— 밥슨

1

나는 내가 어느 지점에 있는지 제목에서 볼 수 있듯이 이것을 사용했습니다. 정말 대단해 !!!

— Piotr Kula

예, 실제로 매우 편리합니다!

— henginy

16

작업 디렉토리의 이름을 다르게 지정하십시오. 즉, 프로젝트 제목이 "MY_PROJECT"인 경우 각 분기마다 다른 작업 디렉토리를 만듭니다. "dev"라는 이름의 브랜치가 하나 있으면 다음과 같이 트렁크 용 디렉토리와 dev 용 디렉토리가 필요합니다.

~/henginy/projects/MY_PROJECT-trunk
~/henginy/projects/MY_PROJECT-dev

— 매튜 로다 투스
소스

실제로 작동하는 디렉토리의 이름은 다릅니다. 그러나 이미 열린 Visual Studio (예 : 커피를 마시고 책상으로 돌아간 후)로 디렉토리를 보려면 파일 경로를 확인해야합니다. 그래서 그것이 가장 간단한 방법이라고 생각합니다.

— henginy

2

@henginy 좋은 설명입니다. Visual Studio에서 확인하기 위해 열린 파일의 탭 위로 마우스를 가져갑니다. 루트가 "-dev"인지 "-trunk"인지 확인할 수있는 전체 파일 시스템 경로의 툴팁이 표시됩니다. 그것을 시도하고 그것이 당신을 위해 작동하는지 확인하십시오.

— Matthew Rodatus

1

그렇습니다. 이것이 바로 "임의 파일의 소스 제어 경로를 확인하는 방법"입니다. 더 빠른 방법을 찾으려고합니다.)

— henginy

@ henginy 아, 맞아. 당신은 OP에서 그것을 말했다. 나는 머리 꼭대기에서 더 나은 방법을 모른다. 당신의 상황이 전혀 개선되지 않은 것 같습니다. :-(

— Matthew Rodatus

내 질문에 더 잘 설명해야합니다. 도와 주셔서 감사합니다!

— henginy

8

일반 개발자 또는 트렁크 지점에서 일하지 않습니다.

항상 피처 브랜치에서 작업합니다. 기능이 완료되면 다음 단계를 따릅니다.

오픈 소스 컨트롤 탐색기.
dev에서 현재 기능 분기로 병합
충돌을 해결하고 모든 것이 여전히 작동하는지 확인하십시오.
다시 체크인하십시오. 기능을 개발 지점으로 병합
개방형 개발 솔루션.
체크인 개발 지점.
개발 솔루션을 닫습니다.
CI를 구축하고 배포하십시오.

나는 dev 브랜치를 한 번에 몇 분 동안 만 열고 즉시 닫습니다.

— CaffGeek
소스

7

각 분기에 빈 파일을 만들 수 있습니다 (예 : 트렁크의 THIS_IS_TRUNK.txt 및 DEV의 THIS_IS_DEV.txt).

— 로브 스텔
소스

2

실제로 작동 할 수 있습니다. 특히 파일 이름 앞에 밑줄을 붙여 솔루션 탐색기에서 위로 이동하십시오.

— henginy

6

커맨드 라인에서 많은 (D) VCS 작업을 수행합니다. 현재 위치에 프롬프트가 표시되는 것이 좋습니다. 예를 들어, Git 저장소에있을 때의 프롬프트는 다음과 같습니다 (SVN에서도 마찬가지입니다).

[BranchName]RepoTop/path/to/current/wd >>

리포지토리가 현재 더러워진 경우 (커밋되지 않은 변경 사항) :

[BranchName!!]RepoTop/path/to/current/wd >>

또한 prod에 로그인하면 배경이 빨간색으로 설정됩니다. 간단한 시각적 알림이 매우 효과적이라는 것을 알았습니다.

컴퓨터로 돌아와서 가장 자주이 내용을 볼 수 있다고 언급했습니다. 내가 떠날 때 키보드에 현재 초점 (분기, 버그 번호, 기능)이 붙어있는 메모를 발견했습니다. 마지막으로 무엇이든 다시 만들지 않고 신속하게 작업 할 수있게하는 데 매우 효과적입니다. .

— 미첼시 슬롭
소스

4

이에 도움이 될 수있는 TFS 솔루션 정보 라는 무료 Visual Studio 확장 이 있습니다. 그것은 당신이 원하는 곳에 도킹 / 고정 할 수있는 작은 창에 현재 지점과 작업 공간을 보여줍니다.

— 글렌 아른트
소스

멋져 보이지만 VS2012를 지원합니다

— Piotr Kula

3

내가 사용하고 VSCommands의 확장 (비주얼 스튜디오 2012,하지만 2010 년 버전이있다) 그리고 편리하게 화면의 왼쪽 상단 모서리에뿐만 아니라 솔루션 탐색기에 지점 이름을 넣습니다.

어떤 식 으로든 제품과 관련이 없으며 단지 행복한 사용자입니다.

— R0MANARMY
소스

1

슬프게도 슬프게도 필요하지 않은 모든 추가 비용을 지불해야합니다 :(

— Piotr Kula

2

하나의 브랜치 에서 거의 모든 작업을 수행함으로써 잘못된 브랜치에서 작업하는 것을 피합니다 (트렁크마다 "불안정한 트렁크" 브랜칭 전략 이라고 함 ).

브랜치를 업데이트 해야하는 경우는 매우 드 rare니다. 이는 사전 및 사후 프로덕션 버그 수정입니다 (프로덕트 후보 코드는 브랜치에서 분리됩니다). 이러한 수정 사항도 트렁크에 있어야하므로 일반적으로 트렁크에 바로 수정, 테스트 및 확인한 다음 제품 분기로 포트합니다. 일반적으로 포팅은 분기 및 빌드 확인을 위해 1-5 개의 파일을 간단히 복사하는 것입니다.

또한 대부분의 프로젝트 관리에서 고객이 오래된 릴리스를 패치하는 대신 최신 릴리스를 사용하도록 설득하기를 선호한다는 점에서 다소 운이 좋았습니다. 이는 지점에서 업데이트 후 생산 부분을 거의 무시할 수있는 수준으로 만듭니다.

— 모기
소스

이전 릴리스를 유지 관리하지 않아도되는 것이 좋습니다. 이 경우 실험 목적으로 만 브랜치를 사용합니다.

— henginy

@henginy 이전 릴리즈를 전혀 유지할 필요가없는 고급 스러우면 사례를 기억할 수 없습니다. 그러나 관리 태도는 여기서 큰 차이를 만들 수 있습니다. 예를 들어 오래된 지사에서는 1 년에 1-2 건의 핫픽스를 구현

— 하거나이

1

구체적인 답변은 사용중인 버전 제어 소프트웨어에 따라 다르지만 일반적으로 작업중인 지점을 쉽게 확인할 수있는 명령이 있습니다. 예를 들어 Subversion의 svn info경우 디렉토리 에서 명령을 사용하여 해당 분기의 URL을 봅니다. 특정 파일에 더 관심이 있다면 다음을 지정할 수도 있습니다.

caleb-dev$ svn info foo.c 
Path: foo.c
Name: foo.c
URL: https://svn.mycompany.com/repo/sample/branches/caleb-dev/foo.c
Repository Root: https://svn.mycompany.com/repo/sample
Repository UUID: d62f7aef-3ad2-6098-12a-c16647d854ab
Revision: 1042
Node Kind: file
Schedule: normal
Last Changed Author: caleb
Last Changed Rev: 1031
Last Changed Date: 2011-06-07 15:28:27 -0400 (Tue, 07 Jun 2011)
Text Last Updated: 2011-06-08 03:08:12 -0400 (Wed, 08 Jun 2011)
Checksum: 123456789098765432123456789098

URL에서 foo.c의 사본이 caleb-dev 브랜치에 있음을 알 수 있습니다.

로컬 디렉토리의 이름이 지점과 동일하기 때문에 자주 그렇게 할 필요가 없습니다. 명령 행 프롬프트를 간단히 살펴보면 일반적으로 올바른 디렉토리에 있고 올바른 분기에서 작업하고 있음을 확인할 수 있습니다.

— 케일럽
소스

1

여기에 많은 답변이 있지만 각 지점에 대해 dev 환경을 포함하는 새 VM을 만들고 적절한 지점에서 체크 아웃하는 간단한 솔루션에는 아무런 영향을 미치지 않습니다. 이를 수행하고 한 번만 가져와야 만 VM을 전환하여 분기를 전환 할 수 있습니다.

— 메이슨 휠러
소스