git기회를 줘

강력한 도구를 사용하는 것이 왜 문제인지 이해가 되지 않습니다. 주기적으로( 또는 타이머를 git통해) 실행되는 간단한 bash 스크립트를 작성하면 자동으로 커밋 메시지 등이 생성됩니다.cronsystemd

다른 사람들이 주석에서 강조한 것처럼 로컬 저장소를 생성하는 것도 물론 가능합니다(참조여기그리고거기자세한 내용은).

자신만의 원격 저장소를 호스팅하려면 "베어 저장소"를 설정해야 합니다. 둘 다 주장을 git init받아들입니다 .git clone--bare

보그 백업

나도 추천할 수 있어보그 백업. 이는 다음을 제공합니다:

• 타임스탬프
• borg diff(스냅샷 비교)
• 정리(이전 스냅샷 제거 - 이번 달의 스냅샷을 매일 원하지만 그렇지 않으면 한 달에 하나만 원한다고 가정)
• 암호화(선택사항)
• 압축(선택사항)
• 그리고 더...

멋진 점은 매우 유연하다는 것입니다. 설정이 쉽지만 원할 경우 다양한 옵션을 제공합니다.

언젠가 글을 쓴 적이 있다빠른 시작 가이드이것이 도움이 될 수 있습니다.

이를 수행하는 방법에는 여러 가지가 있습니다.

• vim
• emacs
• git
• inotify-tools
• git-annex(올인원 솔루션)

세부사항은 다음과 같습니다:

빔 사용:

그렇다면 이름에서 알 수 있듯이 undoVim 편집기의 작업뿐만 아니라 저장된 작업과도 관련된 실행 취소 기록을 사용하는 것이 좋습니다. 더여기.

다음을 다음 항목에 추가하세요 .vimrc.

let vimDir = '$HOME/.vim'
let &runtimepath.=','.vimDir

" Keep undo history across sessions by storing it in a file
if has('persistent_undo')
    let myUndoDir = expand(vimDir . '/undodir')
" Create dirs
    call system('mkdir ' . vimDir)
    call system('mkdir ' . myUndoDir)
    let &undodir = myUndoDir
    set undofile
endif

undodir모든 변경/실행 취소는 로컬 디렉터리 , vimDir기본적으로 .vim홈 디렉터리 , 명령줄 출력 :version또는 --version명령줄에 언급된 다른 디렉터리 에 영구적으로 저장됩니다 .

실행 취소 기록을 더 효과적으로 제어하려면 다음을 사용하는 것이 좋습니다.실행 취소 트리경험치를 추가합니다.

Emacs 사용:

비슷한 이름의 패키지가 있습니다.실행 취소 트리, 비슷한 작업을 수행합니다. 실행 취소 기록에 대한 추가 정보여기.

힘내 사용:

나는 사용하는 것이 좋습니다git 자동 커밋, 이것은 git이 유일한 종속성인 작은 bash 스크립트로, 새 파일이나 수정된 ​​파일에 대해 현재 git 디렉터리(시작 위치)를 모니터링하고 커밋합니다.

파일의 모든 변경 사항을 유지하는 특성상 Git프로덕션/심각한 프로젝트에는 적합하지 않지만 커밋 메시지/일반 커밋 메시지(나중에 언제든지 편집/추가할 수 있음)가 없어도 괜찮다면.

git init원하는 git 디렉터리로 이동한 후 시작합니다. (먼저 특정 디렉터리에서 생성합니다. 자세한 내용은 다음을 참조하세요.공식 매뉴얼)이와 같이:

screen -dmS namehere git-autocommit -i 1 -V

을 사용하는 경우 screen다음을 수행합니다 tmux.

tmux new -n namehere git-autocommit -i 1 -V

그렇지 않으면:

git-autocommit -i 1 -V

배경으로 설정하고 싶지 않다면 충분합니다.

inotify 도구를 사용하십시오.

inotify-toolsor 더 구체적으로 사용하는 것이 좋습니다 inotifywatch. 파일/디렉터리의 변경 사항을 감지하고 (이름에서 알 수 있듯이) 모니터링한 다음 해당 작업을 수행할 수 있습니다(예: 다른 곳에 저장하는 등).

사용할 플래그는 다음과 같습니다 inotifywatch.

inotifywait -r -m -q -e close_write --format %w%f yourdirectorypathhere

Bash위 내용을 사용한 예제 스크립트는 다음과 같습니다.

#!/bin/bash
inotifywait -r -m -q -e close_write --format %w%f directorytowatch | while IFS= read -r file; do

    process $file
done

파일이 수정되었을 때 백업을 만들고 싶거나 어딘가에 업로드하고 싶은 경우 process등 원하는 것은 무엇이든 가능합니다 .tarrclone

git-annex 사용:

, 등 의 다른 많은 외부 도구 git-annex만 포함 하지 않는 것이 좋습니다 .Gitinotify-toolsbashtarrcloneborg

추가 정보:여기.

나중에 위키/포럼을 읽으려면 로컬에서 git clone하여 오프라인으로 읽을 수도 있습니다.

git clone git://git-annex.branchable.com

웹사이트, 포럼(모두 Markdown 형식이므로 다운로드 속도가 매우 빠릅니다...) 및 코드 라이브러리(Haskell 형식!) 등

@steeldriver가 언급한 고대 RCS(패키지 "rcs")를 사용해 볼 수 있습니다. 이는 오버헤드나 복잡성이 거의 없이 파일별로 작동하는 최신 버전 제어 시스템입니다. 이를 사용하는 방법은 여러 가지가 있지만 다음은 한 가지 가능성입니다.

• 버전 기록을 저장할 RCS 하위 디렉터리를 만듭니다.
• 파일 편집
• 변경사항을 확인하세요.ci -l -m -t- myfile
• 반복하다

이 텍스트를 파일에 저장하는 경우:

$RCSfile$
$Revision$
$Date$

그런 다음 체크인하면(기술적으로 체크아웃할 때) RCS는 이러한 문자열을 개정판 및 날짜 스탬프에 대한 정보로 채웁니다.

저장된 파일은 RCS/호출되며 myfile,v각 버전 간의 차이점이 포함됩니다. 물론 RCS에 대해 알아야 할 것이 더 있습니다. ci, co, rcs및 기타 rcsdiff맨페이지를 볼 수 있습니다 .

자세한 내용은 다음과 같습니다.

• RCS/디렉터리 생성을 건너뛰면 아카이브가 파일과 동일한 디렉터리에 나타납니다.
• 파일을 "체크인"하여 ci해당 파일의 버전을 아카이브( *,vRCS/ 디렉터리에 있는 파일)에 기록할 수 있습니다. 체크인하면 데이터가 *,v아카이브에만 존재하도록 파일을 삭제하는 이상한 부작용이 있습니다 . 이러한 부작용을 방지하려면 -l또는 -u명령 을 사용하십시오 ci.
• 파일을 "체크아웃"하여 co아카이브에서 다시 빌드할 수 있습니다.
• 파일을 "잠금"하여 쓰기 가능하게 만들고 다른 사람이 파일에 쓰지 못하게 함으로써 "병합" 상황이 발생합니다. 귀하의 경우 한 명의 사용자만 파일을 수정합니다. "잠김"은 쓰기 가능을 의미하고 "잠금 해제"는 읽기 전용을 의미합니다. 파일을 수정하고 "잠금 해제"(강제 쓰기)하면 ci변경 사항을 확인하려고 할 때 오류가 발생합니다(따라서 이 작업을 피하십시오).
• 파일을 편집하는 유일한 사람은 여러 가지 옵션이 있습니다. 파일을 읽기 전용(잠금 해제) 또는 쓰기 가능(잠김)으로 유지할 수 있습니다. 나는 자주 변경될 것으로 예상되지 않는 파일에 대해 잠금 해제 모드를 사용합니다. 왜냐하면 파일이 읽기 전용이기 때문에 실수로 수정하는 것을 방지하기 때문입니다. 수정 중인 파일에 대해 잠금 모드를 사용하지만 콘텐츠의 개정 기록을 보존하고 싶을 때 사용합니다.
• -l와 함께 사용 ci하거나 co잠그고 쓰기 가능한 상태로 둡니다. 그렇지 않으면 -l읽기 전용이 되고, co그렇다면 완전히 삭제됩니다 ci. ci -u파일 내용을 아카이브에 체크인한 후 읽기 전용 모드로 유지하는 데 사용됩니다 .
• 을 사용하면 개정 메시지를 묻는 것이 -m.방지됩니다 .ci
• 를 사용하면 초기 메시지(아카이브 파일이 처음 생성될 때)를 묻지 -t-않습니다 .ci
• -Mwith ci또는 를 사용하면 co파일의 타임스탬프가 체크인 당시의 타임스탬프와 동기화된 상태로 유지됩니다.
• co -r1.2 -p -q myfile개정판을 표준 출력 1.2으로 인쇄합니다. myfile이 옵션이 없으면 " 잠금 해제"(읽기 전용) -p라고 가정하면 정보 메시지는 를 사용하여 비활성화됩니다 .myfileco -r1.2 myfilemyfile1.2myfile-q
• "브랜치"를 생성하고 다음과 같은 작업을 수행할 수 있습니다 1.3.1.1. 매우 빠르게 지저분해질 수 있으므로 권장하지 않습니다. 나는 개정 과정을 선형적으로 유지하는 것을 선호합니다.

따라서 파일을 항상 쓰기 가능한 상태로 유지하려면 을 사용 하여 현재 콘텐츠 와 가장 최근에 체크인한 버전 간의 차이점을 확인할 ci -l -M -m -t- myfile수 있습니다 . 개정 버전과 사용 버전 간의 차이점을 볼 수 있습니다.rcsdiff myfilemyfilercsdiff -r1.2 -r1.4 myfile1.21.4myfile

아카이브 파일은 에 설명된 형식의 단순한 텍스트 파일입니다 man rcsfile. 그러나 아카이브 파일을 직접 편집하려고 시도하지 마십시오. IMO, 텍스트 기반 아카이브, 최소한의 오버헤드(단일 아카이브) 및 키워드 교체는 RCS의 가장 큰 장점이며 또한 RCS를 훌륭한 로컬 전용, 단일 사용자, 단일 파일 도구로 만듭니다. 일회성 버전 관리. RCS를 다시 설계하면 이 상황(예: 다중 사용자, 분기) 이외의 복잡성을 제거할 수 있으며, 보다 현대적인 분산 버전 제어 시스템이 이를 더 잘 처리할 수 있다고 생각합니다.

다른 명령과 마찬가지로 몇 가지 특이한 점이 있습니다. 원하는 작업 흐름을 이해할 때까지 테스트 파일을 실험해 봐야 합니다. 그런 다음 최상의 결과를 얻으려면 다음과 같은 옵션을 기억할 필요가 없도록 즐겨찾는 옵션을 스크립트에 포함하세요 -t-.

근심적어도 귀하에게 적합한 경우 두 가지 장점을 모두 제공합니다. 파일을 편집할 수 있고 각 버전이 자동으로 커밋되는 git 저장소 보기를 제공합니다.

mkdir mnt
gitfs https://example.com/repo.git $PWD/mnt -o repo_path=$PWD/working_copy

그런 다음 에서 파일을 편집할 수 mnt/current있으며 파일의 모든 버전은 자동으로 git에 커밋되고 mnt/history/*/*.

첫 번째 매개변수는 원격 저장소여야 합니다. Gitfs는 로컬 저장소에서 작동하지 않는 것 같습니다. Naked인 경우 Git에게 origin존재하지 않는 원격 저장소에 액세스하도록 지시하고, Bare가 아닌 경우 Gitfs는 푸시를 시도하지만 실패하고 Gitfs는 그렇지 않습니다. 디버그 메시지를 통하지 않고는 이 사실을 알 수 없습니다. 이 경우 모든 변경 사항이 손실됩니다.

참고할 사항: gitfs는 버그가 많고 유지 관리가 잘 안되는 것 같습니다.조용한 실패일반적인 문제입니다( -o log=-,debug=true,foreground=true,…시도를 통해 진단). user_allow_other활성화 해야 합니다 /etc/fuse.conf.매개변수 조작에 문제가 있음. 올바른 개념이지만 누군가가 유지 관리 책임을 맡아서 고치지 않는 한 권장할 수 없습니다(저는 자원해서 수행하지는 않습니다).