전환하지 않고 다른 Git 브랜치를 당기십시오

55

우리는 최근 SVN에서 Git으로 전환했으며 동시에 로컬 체크 아웃 및 파일 복사 대신 라이브 시스템을 버전 제어로 전환했습니다.

내가 할당 된 프로젝트에서 우리는 모두 동일한 저장소에 액세스하고 변경 사항을 적용하기 위해 git pull거기에 있습니다. 웹 디자이너가 VCS에 변경 사항을 적용하기 때문에 문제가 발생하지만 아직 웹 테스트 환경에는 없어야합니다.

개발자 중 한 명이 이제 라이브로 들어 오면 모든 (완료되지 않은) 변경 사항이 적용됩니다.

나는 여분의 지점으로 라이브로 전환하고 변경된 것을 병합하지만 git 지식이 없기 때문에 어떻게하는지 알지 못합니다.

내 생각은 :

라이브에 새 지점을 만듭니다 ( git branch live).
무언가가 생겨날 때마다
- 마스터에서 풀 변경 (같은 : git checkout master; git pull; git checkout live)
- git merge master

문제는 마스터로 전환하거나 모든 것을 라이브 시스템으로 직접 가져 오는 것이 문제를 일으킬 수 있으므로 이것을 피하는 것이 좋습니다.

이 작업을 수행 할 수있는 방법이 있습니까? 아니면 라이브 시스템을 관리하는 더 좋은 방법이 있습니까?

git

— 모필 두르
소스

git pull --all기본적으로 마스터를 라이브로 가져 오지 않고 마스터를 가져 와서 마스터와 병합합니다 (서버에있는 경우). 해봤 어?

— Tobias Kienzler

라이브에서 분기하기 전에 버전 제어 상태에 있지 않은 파일과 나중에 마스터로 수정 한 후 git-added 파일로 인해 문제가 발생합니까? 그건에게 전에 나에게 무슨 일이 있었는지의는 보통 일시적으로 해당 파일의 이름을 변경 충분합니다, 또는 그것에서 필요하지 않은 경우 라이브 , 사용 git checkout -f문제를 무시하는 - 그러나 백업을 만들!

— Tobias Kienzler

1

관련 : stackoverflow.com/questions/3216360/…

— Ciro Santilli 新疆改造中心法轮功六四事件

21

당신이 사용할 수있는 git stash마스터를 확인하고 당겨 전에, 라이브 다시 사용을 체크 아웃 후 git stash pop(당신의 자식이 오래된, 경우 또는 git stash apply및 git stash clear다른 가정이 은닉하지 않은 것을)

— 토비아스 키엔 슬러
소스

6

git pull --all모든 원격을 가져 오지만 여전히 브랜치 (또는 기본 브랜치)를 현재 브랜치로 병합하려고 시도합니다.

— mipadi

@mipadi 예,하지만 마스터를 체크 아웃하려고 시도하고 충돌을 일으키지 않으면 서 현재 분기 만 자체입니까?

— Tobias Kienzler

현재 분기에 자동으로 병합되도록 구성된 모든 분기를 병합합니다 (해당 분기가 구성된 경우).

— mipadi

1

@Superole 여러 저장소뿐만 아니라 브랜치도 포함하는 "모든 원격 가져 오기"로 문서화되어 있습니다. 가늠자이지만 git fetch --all, 더 나은 대답 일 수도 있습니다

— Tobias Kienzler

2

@TobiasKienzler git에게 구성된 모든 원격에서 가져 오도록 지시합니다. 가장 일반적인 경우는 이름이 원격 인 원점을 하나만 갖는 것입니다. 현재와 동일한 분기를 가진 하나 이상의 리모컨이 있고 서로 빨리 감기 지 않는 경우, --all옵션을 사용하면 분기의 다른 버전을 현재에 낙지 병합 할 수 있습니다 ! 그래서 내 조언은 --all그것이 당신이 추구하는 것이 아닌 한 멀리 하지 않는 것입니다. 대부분의 다른 경우에는 당신에게 아무것도주지 않기 때문입니다.

— Superole

72

나는에서 변화를 당길 수 있었다 origin/master으로 master이 명령을 사용하여 다른 지점에서 작업하는 동안 :

git fetch origin master:master

— 제프 B
소스

6

대박! 정확히 내가 찾던 것-이것은 훨씬 더 잘 문서화되어야합니다 ...

— Markus Shepherd

2

git-scm.com/docs/git-fetch#_examples

— c1moore

fetch! =pull

— D. Kovács

5

먼저 문제를 해결하십시오. 그들은 사업을 추진하지 않는 지점으로 추진해서는 안됩니다.

당신이 묻는 것처럼 보일 것입니다

git checkout live
git pull origin master

이것은 원격 마스터와 라이브 브랜치의 병합을 시도합니다.

— 조쉬 케이
소스

문제는 현재 지점이 하나 뿐이며 모든 사람들이 SVN에 너무 익숙하고 새로운 것의 장점을 기꺼이 배우지 않기 때문에 실제로 변경할 수 없다는 것입니다. 라이브 디렉토리에서만 새 브랜치를 생성 할 수 있습니다. 원격 마스터를 라이브 브랜치에 병합하는 것은 누군가가 디버그 코드, 불완전한 함수, 구문 오류 및 기타 다른 것을 마스터에게 푸시하는 것을 막을 수 없으므로 피하고 싶습니다 (결국 주니어 개발자입니다). 그래도 제안 해 주셔서 감사합니다.

— Morfildur

2

@dbeme : tarball과 패치를 사용할 수 있습니다. ;) 그들이 자식을 기꺼이 배우지 않는다면 (그리고 전혀 분기하고 병합하기가 어렵지 않습니다) 당신은 문제를 겪을 것입니다.

— Josh K

0

모든 사람이 커밋 할 테스트 git repo를 만드는 것이 좋습니다. 라이브 웹 사이트를 포함한 모든 리포지토리는 테스트 리포지토리의 복제본입니다. 이런 식으로 누구나 라이브 웹 사이트를 건드리지 않고도 테스트를 진행할 수 있습니다. 누군가 라이브 사이트를 업데이트해야 할 경우 git testing repo에서 라이브 사이트를 가져올 수 있습니다. 이 워크 플로우는 SVN과 상당히 유사합니다. 유연성을 높이려면 설명하는 "실시간"분기를 사용하는 것이 좋습니다.

요약하면, 모든 사람의 자식 저장소는 테스트 저장소의 복제본입니다. 라이브 프로덕션 사이트는 테스트 리포지토리의 복제본 일뿐입니다. 대안으로, 테스트는 라이브 풋 프린트의 복제본 일 수 있으므로 "git push"는 항상 프로덕션쪽으로 이동합니다.

"라이브"브랜치를이 배열에 추가하거나 테스트와 프로덕션 사이의 "스테이징"리포지토리를 포함하는 다른 옵션. 추가 보안을 위해 라이브 git repo에 대한 액세스를 제한하고 사람들이 라이브 프로덕션을 수행하는 보안 스크립트를 사용하도록 권장합니다.

— 에지 스터
소스