여러 머신에서 Git으로 작업하기


15

조금 이상하게 들릴지 모르지만, 여러 방식으로 함께 연결된 여러 머신에서 Git에서 작업하는 좋은 방법이 궁금합니다. 두 가지 옵션이있는 것처럼 보이며 양쪽에서 이점을 볼 수 있습니다.

  • 공유를 위해 git 자체를 사용하십시오. 각 머신에는 자체 저장소가 있으며 그들 사이를 가져와야합니다.
    • 다른 컴퓨터가 오프라인 인 경우에도 두 컴퓨터에서 작업 할 수 있습니다. 이것 자체가 꽤 크다고 생각합니다.
  • 컴퓨터간에 네트워크를 통해 공유되는 하나의 저장소를 사용하십시오.
    • 코드가 항상 최신 상태이므로 기계를 전환 할 때마다 git pull을 수행 할 필요가 없습니다.
    • 이 컴퓨터에서 파일 공유를 작업하고 있었기 때문에 이제는 접근 할 수없는 다른 비 호스팅 컴퓨터에서 코드를 푸시하는 것을 잊었을 염려가 없습니다.

내 직감에 따르면 모든 사람은 일반적으로 첫 번째 옵션을 사용합니다. 그러나 내가 보는 단점은 다른 컴퓨터에서 코드에 항상 액세스 할 수는 없으며 매일 모든 끝에서 모든 WIP 분기를 github에 푸시하고 싶지는 않습니다. 또한 컴퓨터를 항상 그대로두고 싶지 않아 직접 컴퓨터에서 가져올 수 있습니다. 마지막으로 작은 지점은 여러 분기를 최신 상태로 유지하는 모든 git 명령이 지루할 수 있다는 것입니다.

이 상황에 대한 세 번째 핸들이 있습니까? 이 프로세스를 쉽게 만드는 데 도움이되는 타사 도구가 있습니까? 이 상황을 정기적으로 처리한다면 무엇을 제안합니까?


git은 분산 버전 관리 도구이며 git은 복제 할 때 항상 리포지토리의 로컬 복사본을 만듭니다. "중앙화 된"또는 "고유 한"리포지토리에 대한 개념은 git 세계에는 전 세계적으로 존재하지 않습니다.
user827992

2
@ user827992 나는 그 사실을 100 % 알고 있습니다. 나는 중앙 집중화에 대해 아무것도 제안하지 않았다고 생각합니다. 내가 언급 한 유일한 것은 파일 공유를 사용하는 경우 물리적으로 파일을 저장한다는 의미에서 한 시스템은 호스트입니다. 그것은 dvc와는 완전히 다른 개념입니다.
Tesserex

이 스레드 stackoverflow.com/questions/1550378/… 좋은 생각 이 들어 있습니다. 분기 커밋, 푸시, 풀, 재설정 및 삭제는 그 중 하나입니다 (자동화 가능)
phil294

답변:


14

매일 제안 된 솔루션을 모두 처리합니다. 그것들을 잘 처리하는 데에는 두 가지 주요 개념이 있습니다.

  1. 주제 분기를 사용하십시오. 나는 생산 역사가 깨끗해야한다고 생각합니다. 결과적으로 production지점의 기록을 논리적이고 복제 가능하며 디버깅 할 수 있게 만드는 데 많은 시간을 소비합니다 . 그러나 여러 머신을 사용할 때 때때로 진행중인 작업을 커밋해야합니다. 토픽 브랜치를 사용하십시오. 적은 노력으로 두 머신에서이 분기를 수행 할 수 pull있으며 push, 유지 보수가 용이 한 히스토리를 작성 하기 위해 병합 master하거나 리베이스 할 준비가되면 production .
  2. 다른 사용자와 공유하지 않는 한 네트워크를 통해 공유 된 하나의 저장소를 사용하는 것이 좋습니다. 우리는 창의적으로 scripts저장소 라는 스크립트를위한 공유 저장소를 사용 합니다. 처음에는 레포가 자주 바뀌지 않기 때문에 좋은 생각처럼 보였지만 시간이 지남에 따라 그것은 악몽이되었습니다. 서로의 작업을 쉽게 덮어 쓰기 할 수 있으며 작업을 수행 할 때 저장소를 배포하는 사람을 제어하는 ​​데 많은 시간이 소요됩니다.

가장 좋은 솔루션은 각 컴퓨터에 로컬 리포지토리를 유지하고 원격을 통해 컴퓨터간에 주제 분기를 공유하는 것입니다. 원하는만큼 자주 해당 지점에 진행중인 작업을 커밋하십시오. rebase보다 명료 한 역사를 기꺼이 받아들이 는 한 실제로 효과적입니다.

하루 종일 하나 이상의 토픽 브랜치에서 작업하고 있지만 각 git push <remote>브랜치를 개별적으로 원격으로 푸시하지 않으려 는 경우 기본적으로 모든 일치하는 브랜치를로 푸시합니다 <remote>. 이 기본값은 이후 버전의 git에서 변경 되지만 구성 파일에서 설정push.default 하거나 일치하는 항목을 지정하여 무시할 수 있습니다 refspec.

git push <remote> :

3

모든 머신이 항상 가동되지 않는 경우, 실버 총알이 없습니다. 머신을 종료하기 전에 변경 사항을 다른 곳으로 밀어야합니다. 개인 서버로 푸시하지만 드롭 박스 또는 USB 키가 어디든지 휴대 할 수 있습니다.

그렇습니다. 여러 지점을 중앙 위치로 밀면 지루해질 수 있지만 스크립팅하기에는 너무 어렵지 않습니다. 나는 push.sh그 기계에 대한 작업을 마칠 때마다 실행되는 스크립트를 사용합니다 .


2

나는 이것을 약간 다른 방향에서 왔습니다 (그리고 나는 수은을 사용하지만 철학적으로는 동일합니다). 이것은 내 생각이 아니며, 단지 그것을 사용하고 내 개인적인 물건에 효과적입니다.

SkyDrive 폴더에 리포지토리 복제본을 만들었으며 (드롭 박스 또는 선택한 다른 매직 동기화 도구 일 수도 있음) 두 머신의 인스턴스를 커밋시 SkyDrive 리포지토리에 자동으로 푸시하도록 구성했습니다.

상자를 전환하면 풀과 업데이트를 수행하는 문제가 이론적으로는 여러 저장소에 있더라도 항상 선형 방식으로 작업합니다.

여기서 핵심은 SkyDrive 리포지토리가 대부분 존재하여 두 컴퓨터 모두에서 최신 버전의 코드에 액세스 할 수 있도록 보장하는 수단을 제공한다는 것입니다. 추가 백업. "완료된"항목은 Kiln으로 푸시됩니다 (git을 사용하고 있고 게임이 진행되는 방식을 정확하게 이해하면 리베이스를 수행하는 지점이됩니다).

내가 정말로 원하지 않는 것은 공유 폴더를 실행하는 것입니다 ... DVCS를 사용하는 경우 이점을 누릴 수도 있습니다.


0

두 가지 대안 중 첫 번째가 답입니다. 이것은 "DVCS"의 "D"에 의해 암시됩니다. 각 사용자는 자신의 로컬 리포지토리 인스턴스를 가지고 있으며 리포지토리는 관리 가능한 방식으로 서로 대화합니다.

두 번째 대안을 수행 할 수는 있지만 문제는 저장소 작업 디렉토리가 하나뿐이라는 것입니다. 따라서 작업 트리는 한 번에 하나의 상태에만있을 수 있습니다. Joe는 한 지점에서 작업하고 Jane은 다른 지점에서 작업하지 않습니다. 따라서 개발자는 서로의 변경 사항을 덮어 쓰고 서로의 작업을 혼란시킬 수 있습니다. 왜 버전 관리가 전혀없는 것 같습니다!

네트워크 드라이브에 베어 리포지토리가 있고 개별 사용자가 체크인 및 체크 아웃하는 중간 지점이 있습니다. 이렇게하면 WIP 작업 (예 : 로컬에 보관)이 저장소에 게시 한 작업과 분리됩니다. "저장"이 아니라 "게시"입니다. 동료들이보고 사용하기 원하는 작업.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.