Git merck inconvenience

우리는 SVN에서 Git으로 전환하는 개발자 팀이 더 간단하고 표준화 될 것이라고 생각합니다. 불행히도, 지금까지 우리는 실패와 문제에 봉착했습니다.Git merck inconvenience

우리는 기능 분기가 필요하지 않습니다. 모든 개발자가 공유하는 "개발"이라는 단일 분기가 있습니다.

우리는 TortoiseSVN을 사용하여 UI 용 TortoiseGit을 사용하기로 결정했습니다.

커밋 및 푸시 작동. Pull 조작과 함께 문제가 발생합니다. SVN은 로컬 버전을 변경해도 새 버전을 다운로드하고 가능 한 내용을 자동으로 병합하며 충돌하는 파일을 해결하도록 요청했습니다. 힘내, 같은 파일에 로컬 변경 사항이있을 경우 자동 병합 할 수 있다고하더라도 그냥 멈추게됩니다. 당신은 두 가지 선택을 할 수 있습니다. (중도에서 작업을해도) 로컬 변경 사항을 커밋합니다. 쓸모없는 커밋 톤으로 "로그보기"창을 오염 시키거나 숨기거나 끌어 당기고 SVN이하는 일과 유사한 작업을합니다. 쓸모없는 단계. 더 좋은 방법이 있니?

숨겨진 팝 작업이 자동 병합 (좋은)을 시도하지만 실제 충돌에서 상황이 좋지 않습니다. SVN에서 그것은 쉬웠습니다. 새로운 파일 한 편과 diff 파일의 반대편에있는 로컬 파일을 가지고 로컬 부분을 수정하고 저장하고 해결 방법으로 표시했습니다. 힘내 밑에는 "보통"파일, BASE 파일, REMOTE 파일, LOCAL 파일이있다. 완전하게 섞여있는 것 중 하나는 "원격"파일 (실제로는)이 변경 사항을 포함하고있는 숨겨진 파일이기 때문에 명확성을 위해 도움이되지 않는다는 것입니다.

그래서 병합 도구를 여는 "Edit conflicts"메뉴 옵션을 선택하십시오. TortoiseGitMerge 인터페이스는 매우 친숙하지 않으며 KDiff3는 온라인에서 널리 사용되므로 우리는이 인터페이스를 사용하기로 결정했습니다. 따라서 "병합"탭을 만드는 병합 단추를 누르고 충돌이있는 줄에서는 A, B, C 단추를 누를 수 있습니다. 지금까지는 괜찮습니다. 문제는이 결과 파일을 저장할 때 file.ccs 대신에 file.cs.LOCAL.cs에 저장된다는 것입니다. 그런 다음 TortoiseGit에서 "Resolve", "Resolve using My"또는 "Resolve using theirs"를 선택했는지 여부에 상관없이 병합 된 파일을 삭제하고 최종 파일의 잘못된 버전을 제공합니다 (병합 작업없이). 우리가 얻을 수 있었던 유일한 방법은 병합 된 파일의 임시 백업을 만들고, 해결 된 것으로 플래그 지정하고 백업을 다시 복사하는 것입니다. 도대체 뭐야? 우리의 업무 흐름에서 우리가 일을 잘못하고있는 곳은 어디입니까?

출처

2014-03-13 Dunge

Git 대신 Git을 너무 많이 사용하고 Git에서 변경 사항을 로컬에서 적용하고 다른 개발자와 변경 사항을 공유하기 전에 로컬 기록을 다시 쓰지 않아도되는 것처럼 들립니다. 또한 마지막 단락을 조금 더 부러 뜨릴 수 있습니까? 쉽게 소화하기에는 너무 큽니다. –

'pull --rebase '을 사용하지 않는 한 (새로운 원격 변경에서) 변경을 수행하는 동안 (로컬 변경 사항을 가져 오는 것) (즉, 변경 사항을 원격 변수의 맨 위에 추가) 의미가 없습니다. 각 개발자는 * 원하는 *만큼 로컬 브랜치를 가질 수 있으며 게시 용으로 마스터 브랜치에만 병합 할 수 있습니다. 아마도 [atlassian] (https://www.atlassian.com/git/workflows) 에서처럼 효과적으로 git를 사용하는 워크 플로에 대한 제안을 찾아보십시오. – vonbrand

답장을 보내 주셔서 감사합니다. 푸시하기 전에 여러 번 커밋하는 것에 대해 이야기하고 있습니까? 우리는 그렇게 할 수 있습니다. (비록 내가 왜 그렇게하고 싶은지를 생각할 수는 없지만) 잘 작동합니다. 제가 언급했듯이 문제는 Pull입니다. 나는 마지막 단락을 제안대로 나누었다. vonbrad : 리베이스가 논리적으로 흥미 롭습니다. 논리적으로 리모트 변경 사항을 로컬이 아닌 역으로 추가하는 것이 좋습니다. 그리고 논리적이지 않은 이유는 무엇입니까? 나는 기능에 대해 연구 중이다. 다른 사람이 응용 프로그램의 나머지 부분을 업데이트하면 내 기능을 계속 사용하면서 변경 사항을 활성화하고 싶다. – Dunge

몇 가지 유용한 정보와 팁을 알려 드리겠습니다. 먼저 나는 이것을 말할 것이다. svn 기능 만 있으면 git으로 갈 수 있습니다. 그 경우에는 svn이 좋습니다. git은 훨씬 더 강력한 일을 할 수 있지만 git-way로해야 할 것입니다. 다른 방법은 기껏해야 번거로울 것입니다.

그렇습니다. 당신의 장기적인 목표가 완전히 자식의 생각을 채택하는 것이 잠시 동안 svn처럼 점진적으로 생각을 바꾼 것처럼 "그냥해라"하는 데 도움이 될 수 있습니다.

당신이 할 때 git pull 실제로 두 가지

git fetch 
git merge

또는

그것은 구성 설정 또는 옵션 --rebase에 따라

git fetch 
git rebase

중 하나를 수행. 로컬 브랜치 (로컬 마스터조차도)는 rebase를 선호하지만, 충돌에 대해서는 "자신의"와 "내"가 매우 혼란 스럽지만 여기에는 어떤 일이 발생하는지가 나와 있습니다.

자식이 먼저 다시 해당 지역의 지점 및 기원 지점이
을 발산하는 곳으로 작업 사본 및 HEAD 되감기 후 원점에서 커밋을 모두 적용됩니다.
그러면 git은 커밋을 하나씩 다시 적용하려고 시도합니다. 현재 충돌이 발생하면 변경 사항을 호출 한 다음 올바르지 만 매우 혼란스러운 "해당 사항"을 다시 적용합니다. "내"는 이미 작업 복사본에있는 것, "자신의 것"은 추가 될 것이고 더 의미가 있다고 생각하십시오.

리베이스 대신 병합을 수행하면 반대 방향입니다. 변경 사항은 이미 작업 사본 인 '광산'에 포함되어 있으며 병합되는 변경 사항은 '해당'입니다. 불행히도 매우 혼란 스럽습니다.

필자는 kdiff3이나 TortoiseGIT를 한번도 사용하지 않았기 때문에 도움을받을 수는 없지만 명령 줄 도구를 사용하여 충돌이 발생하면 원래 이름의 파일에 충돌 마커가 가득 찰 것입니다. , 그것은 svn과 마찬가지입니다. 어떤하여 편안한 도구를 사용하여 충돌을 해결하기 위해 다음

git add <conflict file> 
git rebase --continue

또는 리베이스 또는 병합 경우에 따라

git add <conflict file> 
git commit

충돌을 해결하고 이동 할 수 있습니다.

출처

2014-03-13 19:39:26

도움이됩니다. Rebase는 쓸모없는 "merge"커밋 수와 함께 파일 로그를 오염시키지 않기 때문에 일반적인 해결책처럼 보입니다. .gitconfig에 추가 할 구성 줄을 찾았습니다. 하지만 물론 모든 개발자에게 콘솔 명령을 사용하도록 요청할 수는 없으므로 TortoiseGit을 사용해도 문제가 없다고 생각합니다.이제 병합 도구가 예상대로 작동하지 않는 이유는 아직 설명하지 않습니다. – Dunge

예 TortoiseGit Pull 명령은 설정을 무시하는 것 같습니다 (자체 매개 변수 사용) Rebase 메뉴 옵션은 입력하기 전에 변경 사항을 숨겨달라고 요청합니다. 그래서 여전히 혼합되어 있습니다. – Dunge

답변

관련 문제