$HOME
나는 수년간 내 전체 카탈로그를 Subversion으로 확인해 왔습니다 . 여기에는 내 모든 도트 파일과 애플리케이션 구성 파일, 많은 스크립트, 도구 및 해킹, 내가 좋아하는 기본 홈 디렉토리 구조, 꽤 많은 이상한 프로젝트 및 임의의 데이터 저장소가 포함됩니다. 이것은 좋은 일입니다. 그것이 지속되는 동안.
그러나 상황이 걷잡을 수 없게 되었습니다. 기본 검사는 수십 개의 시스템에서 동일하지만 이 모든 항목이 내 모든 컴퓨터에서 작동하는 것은 아닙니다. 다른 배포판에서도 잘 작동하지 않습니다.
저는 집을 청소하고 있습니다. 데이터가 속한 곳을 분리하고, 일부 스크립트를 별도의 프로젝트로 분할하고, 자동화해야 할 항목에서 끊어진 링크를 수정하는 등의 일을 합니다.
subversion
내 의도는 최상위 git
체크아웃을 대체하는 것이지만 $HOME
모든 시스템에서 사용하고 싶은 것으로 축소하고 싶습니다. 즉, 도트 파일, 몇 개의 디렉토리 및 일부 기본 사용자 정의 스크립트를 의미합니다.
온라인에서 읽으면 많은 사람들이 이 작업을 수행하기 위해 심볼릭 링크 방법을 사용하는 것 같습니다. 즉, 하위 디렉터리에 복제한 다음 $HOME
저장소에서 심볼릭 링크를 생성하는 것입니다.$HOME
나는 10년 넘게 완전한 버전 제어를 받아왔고 이 접근 방식의 아이디어도 마음에 들지 않으며 왜 사람들이 직접 체크아웃 접근 방식에 그렇게 반대하는 것 같은지 이해가 되지 않습니다.git
최고의 결제를 위해 알아야 할 특정 문제가 있습니까 $HOME
?
추신: 좋은 코딩 연습의 일환으로 루트 체크아웃을 GitHub에 공개할 계획도 있습니다. 아무 생각 없이 공유했어야 할 파일에 보안에 민감한 정보가 얼마나 많이 수집되도록 허용했는지 무섭습니다! WiFi 비밀번호, 암호화되지 않은 RSA 키 등 이런!
답변1
예git
, 와 아무 관련이 없는 홈 디렉토리 관리를 고려할 때 적어도 하나의 주요 함정이 있습니다 subversion
.
기본적으로 Git은 욕심 많고 재귀적입니다..
Subversion은 모르는 것은 순진하게 무시하며, 알지 못하는(또는 다른 저장소에 속하는) 폴더에 도달하면 체크아웃에서 위아래로 폴더 처리를 중지합니다. 반면에 Git은 모든 하위 디렉터리로 계속 반복되므로 네임스페이스 문제로 인해 중첩된 체크아웃이 매우 복잡해집니다. 홈 디렉토리는 다양한 다른 Git 저장소를 확인하고 작업하는 곳일 가능성이 높기 때문에 홈 디렉토리를 git에 넣으면 인생이 엉망이 될 것이 거의 확실합니다.
이것이 사람들이 도트 파일을 별도의 폴더로 확인한 다음 해당 파일에 심볼릭 링크를 연결하는 주된 이유인 것으로 밝혀졌습니다. 집에서 전복 여부를 확인 하는 것은 순전히 선호 사항의 문제이지만 $HOME
git을 사용하는 경우에는 필수 사항이 됩니다.
하지만, 대체 솔루션이 있습니다. Git에서는 모든 저장소 시스템이 체크아웃 작업 디렉터리와 물리적으로 분리될 수 있는 대체 폴더에 숨겨져 있는 "가짜 루트"라는 기능을 허용합니다. 결과적으로 git 툴킷은 혼동되지 않습니다. 저장소도 볼 수 없고 작업 복사본만 볼 수 있습니다. 몇 가지 환경 변수를 설정하면 홈 디렉터리를 관리할 때 필요한 항목을 찾을 위치를 git에 묻는 메시지를 표시할 수 있습니다. 환경 변수가 설정되지 않으면 아무도 현명하지 못할 것이며 귀하의 집은 고전적인 파일 자체처럼 보일 것입니다.
이 기술을 더욱 원활하게 만들 수 있는 몇 가지 훌륭한 도구가 있습니다. 이것vcs-home 메일링 리스트사실상의 출발점이 되는 것처럼 보이는 정보 페이지는 방법과 사람들의 경험을 편리하게 요약합니다. 그 과정에서 다음과 같은 몇 가지 멋진 장치가 있습니다.VCSH,신사. 홈 디렉터리를 git에 직접 유지하려면 vcsh가 거의 필수 도구입니다. 홈 디렉토리를 백그라운드에서 여러 저장소로 분할하게 된 경우 빠르고 간단하게 여러 저장소를 조합하여 한 번에 관리하십시오 vcsh
.mr
답변2
나는 내 전체 홈 디렉토리가 버전 제어에 체크인되는 것을 원하지 않습니다. 이는 내가 들어가는 모든 하위 디렉토리가 내 홈 디렉토리의 버전 제어 컨텍스트를 갖게 된다는 것을 의미하기 때문입니다. 이 경우, 이와 같은 명령은 git checkout
실제 작업을 수행하며 실수로 잘못된 디렉터리에서 무언가를 실행하면 문제를 일으킬 수 있습니다. 그것이 그 git
자체이든 git을 호출하는 스크립트이든 상관없습니다.
또한 원하지 않는 콘텐츠를 저장소에 추가할 가능성이 높아지는데, 이는 모든 것을 체크인할 때는 문제가 아니었지만 지금은 문제가 됩니다. 실수로 개인 키 파일을 추가하고(아마도 습관적으로) 이를 github에 푸시했다면 어떻게 될까요?
그렇긴 하지만, 내 생각에 가장 큰 단점은 기술적인 것이 아니라 단지 내 방식에서 벗어나고 싶었다는 것입니다.
심볼릭 링크의 경우 저장소를 하위 디렉터리에 복제하고 스크립트를 사용하여 업데이트가 필요한 심볼릭 링크를 업데이트할 수 있습니다. 그러나 이 스크립트에 필요한 유지 관리는 이를 통해 얻는 이점보다 더 클 수 있으며 노력을 줄일 수 있습니다.
심볼릭 링크를 사용하면 배포별(또는 호스트별) 콘텐츠를 쉽게 추가하고 git에 체크인할 수도 있습니다. 심볼릭 링크 업데이트 스크립트는 호환되지 않는 플랫폼이나 다른 호스트의 파일을 무시하고 적절한 파일만 업데이트합니다.
그것은 다음과 같습니다:
HOMEREPO=$HOME/homerepo
HOST=$(hostname)
UNAME=$(uname)
for dotfile in $HOMEREPO/shared/* $HOMEREPO/host-$HOST/* $HOMEREPO/uname-$UNAME/*
do
target=$HOME/$(basename $dotfile)
[ ! -r $target ] && ln -s $dotfile $target
done
개인적으로 저는 심볼릭 링크 디렉터리를 사용하지 않고 그 안에 있는 파일만 사용합니다. 이를 통해 이러한 디렉터리에서 사이트 로컬 변경(예: 파일 추가/제거)을 수행할 수 있는 유연성을 얻을 수 있습니다. 모든 심볼릭 링크를 수동으로 다시 생성해야 했기 때문에 새 시스템에서 내 계정을 설정하는 것은 매우 지루했습니다.
답변3
또 다른 관점을 제시하자면, 나는 한동안 git 아래에 $HOME을 넣어왔는데 어떤 단점도 발견하지 못했습니다. 나는 분명히 이 git repo를 github에 동기화하지 않습니다. 나는 개인 저장소가 있는 서비스를 사용합니다. 또한 미디어 파일, 다운로드 또는 패키지를 git 제어하에 두지 않습니다.
git status
"해야 할 일, 청소할 일" 목록입니다.나는
~/tmp
무시되는 일시적인 일을 가지고 있습니다.나는 최근에 설치한 소프트웨어가 내 $HOME에 추가되는 것을 보고
git status
종종 이러한 파일을 삭제하거나 심지어 범인을 제거하는 것을 좋아합니다.정말 유용한 로컬 파일과 디렉터리를 수동으로 추가했는데
.gitignore
, 이는 "설치 시 수행할 작업을 아는" 이점을 제공합니다.새 가상 머신을 구축하거나 새 PC를 설치하는 경우 원격 홈 디렉터리를 $HOME에 복제하기만 하면 필요한 모든 것을 즉시 얻을 수 있습니다.
vim 플러그인 vundle과 같은 것들은 더 이상 필요하지 않습니다.
나는 복잡한 것을 좋아하지 않습니다. rcfile을 조정할 때 이 작업을 수행하고 커밋하고 푸시합니다. 그런 다음 반성하여 격일로 $HOME을 가져오고 항상 최신 구성을 유지합니다. 그렇게 간단합니다.
현재 이 상태의 컴퓨터: 가정용 노트북, 업무용 PC, 업무용 VM 및 3~4개의 원격 서버.
답변4
다음은 하나입니다: 이 작업을 시도 하고 저장소의 첫 번째 커밋이 git rebase -i --root
체크인되면 git은 파일을 일시적으로 삭제하고 결과적으로 리베이스 작업을 완료하려면 이름과 이메일 메일이 필요하므로 리베이스 작업을 완료할 수 없게 됩니다. 파일에 저장된 것들..gitconfig
.gitconfig
다시 구성하고 수행할 수 있지만 git rebase --continue
그렇게 하고 리베이스가 완료된 후 내 git 저장소는 해당 커밋 이전에 커밋 메시지 없이 빈 커밋을 받았습니다. 이는 저장소 제출의 첫 번째 커밋이었습니다. 잘 모르겠습니다. 그것을 제거하는 방법.
git rebase -i <commit>
이렇게 하고 .gitconfig
그 이후에 커밋을 확인하면 어떤 일이 일어날지 모르겠습니다 <commit>
.
아마도 가장 간단한 해결책은 .gitconfig
저장소에 추가하지 않고 대신 .gitignore
.