VPN 너머 SSHFS에서 git status가 느려질 때: 작업을 옮기세요

200 MB 파일을 복사하면 금방입니다. 같은 디렉터리에서 git status를 실행하면 기다림이 충분히 길어 다른 일로 넘어가고 싶어집니다. 두 관찰이 모순되지 않는 것은, 대량 전송은 처리량을 재지만, Git은 초당 얼마나 많은 작은 파일 시스템 질문을 할 수 있는지를 재기 때문이며, 마운트된 원격 트리는 모든 질문을 왕복으로 바꿉니다. VPN을 조정해도 잘못된 모양의 작업 부하는 고쳐지지 않습니다.

status가 잘못된 기준인 이유

Git은 많은 파일에 대해 알아야 합니다: 어떤 것이 수정되었고, 어떤 것이 추적되지 않았으며, 캐시된 인덱스 데이터가 아직 디스크의 내용과 맞는지. SSHFS 너머에서는 그 관찰 하나하나가 네트워크 작업이 될 수 있습니다. 여기서 작업 단위는 파일 수이지 메가바이트가 아닙니다.

그래서 클론 직후의 첫 status가 느리고, 빌드 출력으로 가득한 트리에서는 다음 status가 더 느릴 수 있습니다. 추적되지 않은 파일 스캔은 관심 없는 디렉터리까지 걷고, 그 한 걸음마다 링크 너머의 요청이 됩니다. 40 ms 경로에서는 몇천 개 항목의 트리가 몇천 번의 왕복이 됩니다. 이 산수를 확인하는 데 패킷 캡처는 필요 없습니다.

다운로드 기준은 링크가 괜찮다고 말하지만, 천 번의 작은 읽기가 오늘 오후에 끝날지는 아무것도 말하지 않습니다.

작업 트리를 옮기고, 조정 손잡이는 두세요

로컬 클론은 작업 트리, 인덱스, Git 작업을 같은 머신에 둡니다. pull이 눈에 보이는 네트워크 단계가 되고, 파일 검사마다 그럴 필요가 없어집니다.

개발자가 필요한 소스를 로컬에 둘 수 있을 때마다 맞는 방식이며, 대개 그렇습니다. 커밋과 배포의 경계도 선명해지는데, 로컬 파일을 편집해도 실행 중인 원격 서비스가 우연히 바뀌지 않고 변경은 다른 것과 마찬가지로 push하고 배포해야 하기 때문입니다. 대가는 코드가 두 곳에 존재한다는 것이므로 어느 복사본이 정본인지, 서버의 긴급 수정이 어떻게 저장소로 돌아오는지 정하세요. 그 대화가 아무도 실행하고 싶지 않은 status 명령보다 쌉니다.

작업 공간이 원격에 남아야 한다면, 거기서 Git을 실행하세요

때로 작업 공간을 옮길 수 없습니다: 빌드가 그 환경을 요구하거나, 데이터가 너무 크거나, 정책이 소스를 호스트에 두기 때문입니다. 그럴 때는 파일 옆에서 Git과 관련 개발 도구를, 승인된 원격 셸이나 원격 개발 환경을 통해 실행하세요. 편집기는 노트북에 남아 있고 그 백엔드가 작업 트리 옆에서 일합니다.

그러면 비싼 작업은 원격 호스트에서 로컬로 일어나고, 네트워크는 수천 번의 stat 호출 대신 편집기 트래픽을 나릅니다. 로컬 클론과 같은 해법이며, 마이그레이션이 아니라 배포 선택으로 표현한 것입니다.

동기화는 소유자가 있는 워크플로이고, 캐시가 아닙니다

동기화된 작업 공간은 반복되는 원격 읽기를 줄일 수 있지만 투명한 캐시는 아닙니다. 변경마다 소유자, 충돌에 대한 규칙, 양쪽이 자기 것이라 믿는 생성 파일에 대한 합의가 필요합니다. 그 규칙이 없으면 이 배치는 편의가 아니라 불일치를 만듭니다.

그것이 없는 양방향 동기화 도구는 해결한 문제와 다른 문제를 만듭니다—대개 누구도 귀속시킬 수 없는 병합입니다. 하나의 공유 작업 트리에 두 Git 프로세스를 돌리는 것은 둘이 어떻게 조정되는지 이해하지 못한다면 피하세요.

그다음 조정하고, SSH는 온건하게 두세요

배치가 옳아지면 두 설정이 Git이 몇 개 파일에 대해 물어야 하는지를 바꿉니다: status.showUntrackedFiles 그리고 core.untrackedCache 뒤의 추적되지 않은 캐시입니다. 둘 다 40 ms 너머 질문 하나의 비용을 바꾸지 않고, 질문의 수만 바꿉니다. 왕복이 로컬이 된 뒤에야 손잡이를 돌리세요.

큰 파일 하나를 복사하는 기준에서 추론하는 대신 짜증나는 명령의 시간을 재고, 지원되는 SSH 암호화는 그대로 두세요. 낡은 암호는 왕복을 줄이지 않고, 첫 문제보다 오래 사는 두 번째 문제를 더할 뿐입니다. git status 참조는 한 번 읽을 가치가 있습니다, 왜냐하면 명령은 이름이 암시하는 것보다 훨씬 많은 일을 하기 때문입니다.