백업 도구로서의 GIT


101

서버에서 git을 설치하십시오.

cd /
git init
git add .
git commit -a -m "Yes, this is server"

그런 다음 /.git/네트워크 드라이브 (SAN, NFS, Samba 등) 또는 다른 디스크를 가리 킵니다. 시간 / 일 등마다 크론 작업을 사용하여 변경 사항을 업데이트하십시오. .git 디렉토리에는 모든 서버 파일의 버전이 지정된 사본이 포함됩니다 (/ proc, / dev 등 쓸모 없거나 복잡한 파일은 제외)

적절한 백업 시스템에서 번거롭고 비용이 많이 들지 않고 백업이 편의를 위해 중요하지 않은 중요하지 않은 개발 서버의 경우 (즉, 이 서버를 백업 할 필요 는 없지만 절약 할 수 있음) 일이 잘못되면 언젠가는 이것이 유효한 백업 솔루션 일 수 있습니까? 아니면 큰 똥 더미에 떨어질 것입니까?


3
비슷한 아이디어를 사용하여 sparkleshare하지 않습니다 ??
B14D3

@ B14D3 sparkleshare는 일종의 dropbox 유형이라고 생각하지만, 살펴 보겠습니다
Smudge

2
맞습니다.하지만 일종의 벅업을 만들기 위해 git을 사용합니다 (여러 PC에 복사 및 파일 버전 제어);
B14D3

이것의 큰 문제는 중앙 제어가 없다는 것입니다. 어떤 형태의 유지 관리 또는 백업 유효성 검사를 수행하려면 머신에 직접 (ssh) 액세스해야합니다. 항상 백업 할 상자에 앱을 설치 한 다음 중앙 위치에서 관리하는 것이 훨씬 큰 승리라는 것을 알았습니다.
hafichuk

@hafichuk Puppet / Chef와 같은 도구를 사용하면 큰 문제는 아니지만 요점을 알 수 있습니다.
Smudge

답변:


88

당신은 바보 같은 사람이 아닙니다. git백업 메커니즘으로 사용 하는 것은 매력적일 수 있으며 다른 사람들의 말에도 불구하고 git이진 파일과 잘 작동합니다. 이 주제에 대한 자세한 내용 은 Git Book에서이 페이지를 읽으십시오 . 때문에 기본적으로, git델타 저장 메커니즘을 사용하지 않는, 정말 상관하지 않는다 어떤 파일의 모양 (만의 유틸리티가 git diff주식 구성에 바이너리 파일에 대한 매우 낮다).

git백업에 사용하는 데 가장 큰 문제 는 대부분의 파일 시스템 메타 데이터를 보존하지 않는다는 것입니다. 구체적으로 다음을 git기록하지 않습니다.

  • 파일 그룹
  • 파일 소유자
  • 파일 권한 ( "이 실행 파일"이외)
  • 확장 된 속성

이 정보를 리포지토리에 명시 적으로 기록하는 도구를 작성하여이 문제를 해결할 수 있지만이 정보를 얻는 것이 까다로울 수 있습니다.

git 백업 메타 데이터에 대한 Google 검색은 읽을 가치가있는 것으로 보이는 여러 결과를 산출합니다 (이미 제기 한 문제를 이미 보상하려고 시도하는 일부 도구 포함).

etckeeper 는 백업을 위해 개발되었으며 /etc이러한 많은 문제를 해결합니다.


15
ACL / 권한에 대한 +1
Larry Silverman

22
힘내도 빈 디렉토리를 저장하지 않습니다.
Flimm의

또한 기록을 통해 파일 이동 / 이름 바꾸기를 추적합니다.
cregox

1
git은 바이너리 파일을 잘 다루지 않기 때문에 git annex 를 살펴보면 더 좋습니다. 그러나 git이 무엇인지에 대한 아이디어를 변경합니다.
Wouter Verhelst

1
내 의견은 git을 사용하여 데이터를 백업 할 수 있지만 전체 서버는 백업 할 수 없다는 것입니다.
EKanadily

21

나는 그것을 사용하지 않았지만 git을 기반으로하는 백업 도구 인 bup 을 볼 수 있습니다 .


한 번도 보지 못했지만 재미있어 보인다
Smudge

1
최근 하드 드라이브가 충돌하기 며칠 전에 최근에 bup을 사용하기 시작했습니다.
André Paramés

1
@ AndréParamés 그래서 당신이 말하는 것은 하드 드라이브가 충돌하여 bup을 설치 한 직후입니다 ... mmmmhh ... :) 농담
hofnarwillie

12

유효한 백업 솔루션 일 수 있습니다. etckeeper는이 아이디어를 기반으로합니다. 그러나 .git디렉토리 권한을 주시하십시오. 그렇지 않으면 디렉토리에서 푸시 /etc/shadow를 읽을 수 있습니다 .git.


11

기술적 으로이 작업을 수행 할 수는 있지만 두 가지주의 사항이 있습니다.

1, 이진 데이터에 대한 소스 버전 제어 시스템을 사용하고 있습니다. 따라서 설계되지 않은 용도로 사용하고 있습니다.

2, 새로운 기계를 구축하기위한 프로세스 (문서화 또는 자동화)가 없으면 개발 프로세스가 걱정됩니다. 버스를 샀다면, 누가 무엇을해야하는지, 무엇을 중요하게 생각했을까요?

재해 복구는 중요하지만 모든 것을 백업하는 것보다 새로운 개발 상자 설정을 자동화 (스크립트)하는 것이 좋습니다. 컴퓨터의 모든 파일이 아니라 스크립트 / 문서에 git을 사용하십시오.


4
개발 상자는 모두 KickStart 파일에서 가져 오며 실제로 평균 상자는 다시 빌드하기 전 약 2 ~ 3 개월 동안 지속됩니다. 그러나 사람들은 설정을 변경하고 일을하고 상자를 다시 만들고 사람들은 "저는 소스 제어에 넣지 않았지만 그 상자에 약간의 똥이 있다는 것을 알고 있습니다"라고 말하면서 바보가 된 것에 대해 웃었습니다. 모든 시간, 좋은 시간. 이진 데이터는 암캐 일 것입니다. 샤워 중에 완전히 간과 한 것입니다.
Smudge

나는 기본 교장을 따르지 않는 사람들에게 당신의 태도에 박수를 보냅니다. 개인적으로 나는 당신과 비슷한 상황을 가지고 있지만, 모든 구성 파일에서 모든 것을 잡기보다는 중요 할 수있는 git 저장소를 가지고 있습니다. 설정 단계가 포함 된 txt 문서와 함께.
Phil Hannent

1
git은 바이너리 파일에서 잘 작동한다고 생각합니다 .Google Android의 많은 부분은 사전 빌드 된 실행 파일의 git 저장소입니다.
user377178

6

Windows 시스템의 백업으로 git을 사용하는데 매우 유용했습니다. 게시물 맨 아래에는 Windows 시스템에서 구성하는 데 사용하는 스크립트가 표시됩니다. 모든 시스템의 백업으로 git을 사용하면 두 가지 큰 장점이 있습니다.

  1. 상용 솔루션은 종종 자체 소유 형식을 사용하는 것과 달리 백업은 널리 지원되며 문서화가 잘 된 오픈 소스 형식입니다. 이를 통해 데이터를 완벽하게 제어 할 수 있습니다. 어떤 파일이 언제 변경되었는지 쉽게 알 수 있습니다. 당신의 역사를 자르고 싶다면 그렇게 할 수도 있습니다. 당신의 역사에서 무언가를 없애고 싶습니까? 문제 없어요. 파일 버전을 되 돌리는 것은 git 명령만큼 간단합니다.
  2. 원하는만큼의 미러 수만큼 미러를 구성 할 수 있으며 모두 백업 시간을 사용자 지정할 수 있습니다. 인터넷 트래픽이 느려지면 로컬 미러가 생겨서 (1) 하루 종일 더 자주 백업 할 수있는 능력과 (2) 빠른 복원 시간을 제공합니다. (문서를 잃어버린 시간이 사용자 오류에 의한 것임을 알기 때문에 빈번한 백업은 큰 장점입니다. 예를 들어, 자녀가 실수로 지난 5 시간 동안 작업했던 문서를 덮어 씁니다.) 원격 미러 : 로컬 재난 또는 도난시 데이터 보호의 이점을 제공합니다. 인터넷 대역폭을 절약하기 위해 사용자 정의 된 시간에 원격 미러 백업을 원한다고 가정 해보십시오. 문제 없어요.

결론 : git 백업은 백업 수행 방식을 제어하는 ​​데 엄청난 양의 파워를 제공합니다.

내 Windows 시스템에서 이것을 구성했습니다. 첫 번째 단계는 모든 로컬 데이터를 커밋 할 로컬 git repo를 만드는 것입니다. 로컬 보조 하드 드라이브를 사용하는 것이 좋지만 동일한 하드 드라이브를 사용하면 효과가 있습니다 (그러나 원격 드라이브를 어딘가에 밀어 넣거나 하드 드라이브가 죽으면 나사를 조일 것으로 예상됩니다).

먼저 cygwin (rsync 포함)을 설치하고 Windows 용 git도 설치해야합니다. http://git-scm.com/download/win

다음으로 로컬 git repo를 작성하십시오 (한 번만 실행).

init-repo.bat :

@echo off
REM SCRIPT PURPOSE: CREATE YOUR LOCAL GIT-REPO (RUN ONLY ONCE)

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror


REM Create the backup git repo. 
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
mkdir %GBKUP_LOCAL_MIRROR_HOME%
git %GIT_PARAMS% init
git %GIT_PARAMS% config core.autocrlf false
git %GIT_PARAMS% config core.ignorecase false 
git %GIT_PARAMS% config core.fileMode false
git %GIT_PARAMS% config user.email backup@yourComputerName
git %GIT_PARAMS% config user.name backup

REM add a remote to the git repo.  Make sure you have set myRemoteServer in ~/.ssh/config   
REM The path on the remote server will vary.  Our remote server is a Windows machine running cygwin+ssh.  
REM For better security, you could install gitolite on the remote server, and forbid any non-fast-forward merges, and thus stop a malicious user from overwriting your backups.
git %GIT_PARAMS% remote add origin myRemoteServer:/cygdrive/c/backup/yourComputerName.git

REM treat all files as binary; so you don't have to worry about autocrlf changing your line endings
SET ATTRIBUTES_FILE=%GBKUP_LOCAL_MIRROR_HOME%\.git\info\attributes
echo.>> %ATTRIBUTES_FILE% 
echo *.gbkuptest text>> %ATTRIBUTES_FILE% 
echo * binary>> %ATTRIBUTES_FILE% 
REM compression is often a waste of time with binary files
echo * -delta>> %ATTRIBUTES_FILE% 
REM You may need to get rid of windows new lines. We use cygwin's tool
C:\cygwin64\bin\dos2unix %ATTRIBUTES_FILE%

다음으로 백업 스케줄러가 정기적으로 호출하는 백업 스크립트 래퍼가 있습니다.

gbackup.vbs :

' A simple vbs wrapper to run your bat file in the background
Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "cmd /c C:\opt\gbackup\gbackup.bat"
oShell.Run strArgs, 0, false

다음으로 래퍼가 호출하는 백업 스크립트 자체가 있습니다.

gbackup.bat :

    @echo off

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror
REM the user which runs the scheduler
SET GBKUP_RUN_AS_USER=yourWindowsUserName
REM exclude file
SET GBKUP_EXCLUDE_FILE=/cygdrive/c/opt/gbackup/exclude-from.txt

SET GBKUP_TMP_GIT_DIR_NAME=git-renamed
for /f "delims=" %%i in ('C:\cygwin64\bin\cygpath %GBKUP_LOCAL_MIRROR_HOME%') do set GBKUP_LOCAL_MIRROR_CYGWIN=%%i

REM rename any .git directories as they were (see below command)
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (%GBKUP_TMP_GIT_DIR_NAME%) do ren "%%i" ".git" 2> nul

SET RSYNC_CMD_BASE=C:\cygwin64\bin\rsync -ahv --progress --delete --exclude-from %GBKUP_EXCLUDE_FILE%

REM rsync all needed directories to local mirror
%RSYNC_CMD_BASE% /cygdrive/c/dev %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/asmith %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/bsmith %GBKUP_LOCAL_MIRROR_CYGWIN%

cacls %GBKUP_LOCAL_MIRROR_HOME% /t /e /p  %GBKUP_RUN_AS_USER%:f

REM rename any .git directories as git will ignore the entire directory, except the main one
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (.git) do ren "%%i" "%GBKUP_TMP_GIT_DIR_NAME%" 2> nul
ren %GBKUP_LOCAL_MIRROR_HOME%\%GBKUP_TMP_GIT_DIR_NAME% .git

REM finally commit to git
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
SET BKUP_LOG_FILE=%TMP%\git-backup.log
SET TO_LOG=1^>^> %BKUP_LOG_FILE% 2^>^&1
echo ===========================BACKUP START=========================== %TO_LOG%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a%%b)
echo %mydate%_%mytime% %TO_LOG%
echo updating git index, committing, and then pushing to remote %TO_LOG%
REM Caution: The --ignore-errors directive tells git to continue even if it can't access a file.
git %GIT_PARAMS% add -Av --ignore-errors %TO_LOG%
git %GIT_PARAMS% commit -m "backup" %TO_LOG%
git %GIT_PARAMS% push -vv --progress origin master %TO_LOG%
echo ===========================BACKUP END=========================== %TO_LOG%

exclude-from.txt 파일이 있습니다. 여기서 모든 파일을 무시합니다.

exclude-from.txt :

target/
logs/
AppData/
Downloads/
trash/
temp/
.idea/
.m2/
.IntelliJIdea14/
OLD/
Searches/
Videos/
NTUSER.DAT*
ntuser.dat*

원격 저장소로 가서 'git init --bare'를 수행해야합니다. 백업 스크립트를 실행하여 스크립트를 테스트 할 수 있습니다. 모든 것이 작동한다고 가정하면 Windows 스케줄러로 이동하여 시간별 백업을 vbs 파일로 지정하십시오. 그 후, 당신은 매 시간마다 컴퓨터의 자식 역사를 갖게됩니다. 매우 편리합니다. 우연히 텍스트 섹션을 삭제하고 놓치나요? git 저장소를 확인하십시오.


궁금한 점은 NetDrive 또는 Expandrive에서 에뮬레이트 된 것과 같이 느리거나 비표준 네트워크 드라이브에서도 작동합니까? 이 네트워크 드라이브에 실패한 대부분의 백업 소프트웨어가 있습니다. 또한 백업의 모든 파일을 나열하고 개별 파일을 추출하려는 경우 고통스럽게 느려지고 시간이 초과되는 경향이 있습니다. 자식이 이러한 문제를 해결할 수 있습니까?
JustAMartin

@JustAMartin 네트워크 드라이브에서 테스트 한 적이 없으므로 말할 수 없습니다. git repo에 파일을 가져 오면 git이 매우 효율적입니다.
user64141

4

글쎄, 그것은 나쁜 생각은 아니지만, 제기해야 할 적신호가 2 개 있다고 생각합니다.

  • 하드 디스크에 장애가 발생하면 커밋을 다른 서버 / 드라이브로 푸시하지 않으면 모든 내용이 손실됩니다. (이벤트를 계획 한 경우 언급하고 싶습니다.)

...하지만 여전히 손상 관련 문제에 대한 좋은 백업이 될 수 있습니다. 또는 .git / 폴더가 다른 곳에 있다면 말했듯이.

  • 이 백업은 항상 크기가 커집니다. 가지 치기 또는 회전 또는 기본적으로 아무것도 없습니다.

... 따라서 태그를 추가하도록 cronjob에 지시 한 다음 태그가없는 커밋을 정리해야합니다.


우리는 아마도 .git 디렉토리를 원격 서버에 마운트 할 것입니다 rm -Rf /. 현재 백업 시스템은 2 년 또는 50 개 버전 (둘 중 마지막 버전)을 유지하므로 백업이 지속적으로 증가하고 있습니다. 그러나 나는 태그를 추가한다는 아이디어를 좋아한다. "daily", "weekly"등을 가질 수있다.
Smudge

증가하는 공간 요구 사항에 대해 +1
hafichuk

@sam git은 계속 성장하고 있습니다. 당신은 N 년보다 오래된 역사를 정리할 수 없습니다. 나는 당신의 현재 시스템이 그렇게 생각합니다.
rds

1
크기 증가와 관련하여 정기적으로 또는 다른 (중앙) 서버로 푸시하기 전에 'git gc'를 수행하십시오. 이것이 없으면 git repo가 ​​예상보다 커질 수 있습니다. 한 번 16MB로 축소 할 수있는 346MB의 git repo가있었습니다.
Hendy Irawan

3

전체 시스템으로 시도하지는 않았지만 MySQL 백업 (--skip-extended-insert 옵션 사용)에 사용하고 있으며 실제로 잘 작동했습니다.

이진 데이터 파일에 문제가 발생하고 (전체 내용이 변경 될 수 있고 변경 될 수 있음) .git폴더가 실제로 커지는 데 문제가있을 수 있습니다 . .gitignore파일을 설정하고 실제로 필요한 텍스트 파일 만 백업 하는 것이 좋습니다 .


--extended-insert = false와 함께 MySQL 백업에도 사용하고 있습니다. 커밋 직후 또는 정기적으로 "git gc"를 사용하십시오.
Hendy Irawan


3

나는 한 번 subversion을 기반으로 백업 솔루션을 개발했습니다. 꽤 잘 작동하고 (git이 더 잘 작동해야하지만) 더 나은 해결책이 있다고 생각합니다.

나는 rsnapshot 을 더 나은 것으로 생각 합니다 . 하드 링크를 잘 사용하면 매일, 매주 및 매월 백업이 1 년까지 걸리는 300GB 파일 서버 (50 만 개의 파일)가 있습니다. 사용 된 총 디스크 공간은 하나의 전체 사본 + 각 백업의 증분 부분이지만 하드 링크 덕분에 각 백업에 완전한 "라이브"디렉토리 구조가 있습니다. 다시 말해, 파일은 매일 0 (가장 최근 백업)에서뿐만 아니라 매일 1 (yestarday) 또는 weekly.2 (2 주 전) 등에서도 직접 액세스 할 수 있습니다.

백업 폴더를 Samba와 다시 공유하면 사용자는 PC를 백업 서버로 가리 키기 만하면 백업에서 파일을 가져올 수 있습니다.

또 다른 매우 좋은 옵션은 rdiff-backup 이지만 탐색기를 \\ servername으로 이동하여 파일에 항상 액세스 할 수 있기를 원하므로 rsnapshot이 더 나은 솔루션이었습니다.


rdiff-backup의 마지막 릴리스는 2009 년입니다. 매우 잘 설계되어 전혀 업데이트가 필요하지 않습니까? 아니면 단순히 버려진 프로젝트입니까?
Mateusz Konieczny

그것이 달성되었는지는 모르겠지만 기본적으로 "완료"입니다.
shodanshok

보고에서 savannah.nongnu.org/bugs/... 거기 늦게 2015과 같은 일부 활동했지만 많은 버그 리포트는 무시됩니다 것으로 보인다. 나는 그것을 버려진 것으로 분류 할 것이라고 생각합니다.
Mateusz Konieczny

2

기본적으로 버전 백업이 가능하기 때문에 git으로 백업하는 것과 동일한 아이디어가있었습니다. 그런 다음 rdiff-backup을 보았습니다. 이 기능은 훨씬 더 많은 기능을 제공합니다. 정말 좋은 사용자 인터페이스가 있습니다 (CLI 옵션을보십시오). 나는 그것에 매우 만족합니다. 은 --remove-older-than 2W꽤 멋지다. 2 주가 지난 버전 만 삭제할 수 있습니다. rdiff-backup파일의 차이 만 저장합니다.


2

git을 처음 접했지만 기본적으로 로컬 브랜치가 아니며 원격 저장소로 명시 적으로 푸시해야합니까? 이것은 불쾌하고 예기치 않은 놀라움이었습니다. 결국, 모든 로컬 저장소가 서버에 '백업' 되기를 원하지 않습니까? 자식 책 읽기 :

로컬 브랜치는 사용자가 쓰는 리모콘에 자동으로 동기화되지 않습니다. 공유하려는 브랜치를 명시 적으로 푸시해야합니다. 이렇게하면 공유하고 싶지 않은 작업에 개인 브랜치를 사용할 수 있으며 공동 작업하려는 주제 브랜치 만 푸시 할 수 있습니다.

나에게 이것은 내 로컬 머신의 다른 비 git 파일과 같은 로컬 브랜치가 비 git 수단에 의해 정기적으로 백업되지 않는 한 손실 될 위험이 있음을 의미했습니다. 어쨌든이 작업을 수행하지만 내 저장소에서``모든 것을 백업 ''하는 git에 대한 내 가정을 어겼습니다. 이것에 대한 설명을 듣고 싶습니다!


1
리모컨을 제외한 git에 관한 거의 모든 것이 로컬입니다. 그것은 의도적으로 설계된 것입니다. 원격으로 항목을 푸시 할 수 있으며 특히이 시나리오에서와 같이 백업에 사용해야하는 경우에 필요합니다. 분기의 경우 다시, 예를 들어, 원격에 추가하려면 명시 적으로 분기해야합니다. 개발을 위해, 이것은 종종 무언가를 테스트하기를 원하기 때문에 훌륭하지만, 해당 테스트 브랜치를 무기한으로 보존 할 필요는 없습니다. 필요한 것을 얻으면 개발자 브랜치에 병합하고 테스트 브랜치를 델링 할 것입니다.
LocalPCGuy

1

나는 이것이 내 dev 상자에 좋은 방법론이라는 것을 알았습니다. 배치 엔드 포인트에만 백업해야하는 것으로 변경합니다.

모든 구성 및 패키지 설치 매니페스트는 Puppet에 저장되므로 쉽게 재배치 및 구성 업데이트 할 수 있습니다. Puppet 디렉토리는 git으로 백업됩니다. 킥 스타트는 초기 배포를 수행하는 데 사용됩니다.

또한 당시 개발중인 패키지에 대한 사용자 지정 YUM 저장소를 유지합니다. 이것은 우리가 작업하고있는 패키지가 로컬 시스템에서 무인 바이너리로 남지 않는다는 추가 이점을 제공합니다. 누군가 적절한 절차를 따르지 않았습니다.



1

사용되는 접근 방식입니다.

Keepconf 는이 작업에 rsync와 git을 사용합니다. 작업을 쉽게 수행 할 수 있도록이 도구에 대한 래퍼입니다.

백업 서버에 액세스하도록 구성된 ssh 키가있는 중앙 서버와 구성 파일의 몇 줄만 있으면됩니다. 예를 들어,이 파일은 모든 / etc / 및 데비안 패키지를 설치하기위한 내 파일입니다.

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

[files]
/etc/*
/var/lib/dpkg/status

이를 통해 rsync 백업과 git commit이 있습니다.


0

내 개인적인 의견은 이것이 기본적으로 모든 것입니다. 파일을 꺼내지 않고 백업 솔루션으로 파일을 푸시합니다.

서버 구성을 우선 중앙 집중화 한 다음 꼭두각시와 같은 것을 사용하여 서버 구성을 끌어내는 것이 훨씬 좋습니다.

즉, 그것은 효과가있을 수 있습니다. 나는 그것이 그렇게 좋을 것이라고 생각하지 않습니다.

backuppc를 살펴보십시오. 설정이 쉽고 솔직합니다.


0

다소 작동하지만 두 가지주의 사항이 있습니다.

  1. 커밋을 수행 할 때 파일 추가가 자동으로 선택되지 않습니다. 커밋을 수행하기 전에 추가 할 새 항목을 찾으려면 --porcelean om git status를 사용하십시오.

  2. 왜 .ssh에 대한 원격 마운트의 번거 로움이 있습니까? 그것은 깨지기 쉬워 Bd 당신은 그것이 실패했다는 것을 알지 못할 것입니다. 일반 ssh 키 로그인으로 맨 끝에 저장소를 사용하십시오. 저장소가 베어 있고 하나의 소스에서만 푸시하는 한 병합을 통해 작동합니다.

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