Professional 버전 관리에 대한 대안 [닫기]


57

우리는 프로젝트 중 하나에 기여해야하는 비 프로그래머 (작가)와 협력하고 있습니다.

이제 그들은 작업을 버전 관리하기 위해 Git (또는 그 문제에 대한 것)을 사용하는 아이디어를 좋아하지 않습니다. 나는 이것이 트위스트 버전 관리 개념 주위에 머리를 감쌀 가치가 없다는 것을 알기 때문이라고 생각합니다. (처음으로 분기 및 병합에 대해 소개했을 때 문제를 일으키는 것처럼 보였습니다.)

이제 우리는 그들을 교육 시키거나 사용하도록 설득 할 수있는 위치에 있지 않습니다. 우리는 대안을 찾기 위해 노력하고 있습니다. 모든 작업의 ​​버전이 필요합니다 (필요한 것). 워크 플로가 쉽고 작업에 집중합니다.

나는 몇 가지 아이디어를 생각해 냈습니다 ...

  • 사소한 변경을 할 때마다 작업을 별도의 파일로 저장하도록 지시 한 다음 변경 사항을 추적하기 위해 우리 측의 diff를 사용하십시오.
  • 어떤 방식으로 CSSEdit에서 "마일스톤"을 구현하는 프로그램을 파이썬으로 작성하십시오.

프로젝트 정보 :

자연 언어 처리 시스템입니다 (C + Python으로 작성). 우리는 다른 언어로 시스템에 대한 입력을 준비하기 위해 일부 작가를 고용했습니다. 소프트웨어가 발전함에 따라 작가는 자신의 입력 (문서)을 변경해야합니다. 때로는 변경 사항이 매우 적거나 (한두 단어) 다른 경우도 많습니다.

이러한 변경 사항을 버전 제어해야하는 이유는 입력의 모든 작은 / 큰 변경이 시스템의 출력을 크게 변경할 수 있기 때문입니다.


15
@rwong-또는 버전 관리가있는 wiki도 작동 할 수 있습니다.
Joris Timmermans

4
@ MadKeithV 의견에 추가하면 git-powered wiki는 어떻습니까? github.com/github/gollum- 워크 플로우의 일부 변경이 이루어지며 두 팀을 연결하려고합니다. 현재 도구를 살펴 보셨습니까? 그들은 어떤 종류의 버전 관리를 지원할 가능성이 적으며, 작가는 결코 알아
채지 않아도

20
정말 간단합니다. 이 사람들에게 돈을 지불하려는 경우, 그들은 당신의 도구를 사용하여 돈을받을 수 있다고 말하거나, 그들이 당신의 도구를 사용하지 않으면 돈을받지 못한다고 말하십시오. 중간 정도의 비용은 결국 더 많은 작업을 의미합니다. 비용이 많이 들기 때문에 도구로 작업 할 사람들을 찾는 것과 균형을 이룹니다.
Ramhound

4
화석은 버전이 지정된 위키와 함께 제공되는 흥미로운 VCS입니다. 우리는 문서를 최신 상태로 유지하는 방법으로 사용했지만 이와 같은 것을 "버전 화"하는 데 사용할 수 있습니다.
Ben Brocka

34
왜 비 기술자들에게 지점을 도입하고 병합하려고 했습니까? 당신은 그들의 작업 버전을 원합니다. 저장 방법을 알려줄 수 있습니다. 당신은 그들이 가지와 합치기를 처리하기를 원합니다. Tortoise *와 같이 멋지고 쉬운 것을 얻었어야하고 실제로 필요하지 않은 것을 말하지 않아야합니다.
David Thornley

답변:


102

처음에 브랜치 및 병합에 대해 소개했을 때

분기 및 병합이 고급 개념이므로 변경 내용을 추적하는 것보다 유용성이 적기 때문일 수 있습니다.

그렇다면 왜 "커밋"(저장)과 "업데이트"를 설명하지 않겠습니까? 두 가지 간단한 개념. 10 분 안에 설명 할 수있을 것입니다.

실제로 별도의 가지와 그와 같은 것을 사용하려면 관련 부분을 사용하지 않고 직접 할 수 있습니다.


20
+1. 그들의 목적 상, 직선 이력을 유지하는 것은 근본적이고 게임을 바꾸는 개념입니다. 필자는 작가가 실제로 브랜치와 병합을 필요로하지 않을 것이라고 생각한다. 만약 그렇게한다면, 관리하는 동안 보유 할 개발자의 손이 필요할 것이다.
Dan Ray

7
@ BillK, 실제로 git과 병합을 시도 했습니까? SVN보다 훨씬 잘 작동한다고 생각합니다. (필요하지 않은 곳에 병합을 사용하는 것을 옹호하지 않습니다.)
svick

10
@Bill K 솔직히, 이것은 SVN에서 20 년 후에 (일부라도) 따라 잡아야하는 것처럼 들립니다. 브랜치와 병합은 이러한 작가에게는 실제로 의미가 없을 수도 있지만 레포를 브랜치하지 않고 20 년 동안 어떻게 프로그램을 관리했는지 잘 모르겠습니다. 가지가 좋은 연습을하고 삶을 편하게하는 많은 경우가 있습니다. 사실, 개념을 맹목적으로 거부하는 것은 나쁜 판단 (IMHO)을 보여줍니다. SVN에서 브랜칭은 고통 스럽지만 자식이 있으면 정말 쉽습니다. 자비를 베풀고 오후에 투자하여 git의 기본 사항을 배우십시오. 당신은 그것을 후회하지 않을 것이라고 약속했습니다!
Robin

6
@ user606723 : TortoiseSVN 및 TortoiseGIT는 Windows 셸 통합을 제공합니다.
Roy Tinker

6
나는 Git 브랜칭을 가르치고 비 기술자들에게 합병을 시도하는 것은 인권을 침해한다고 확신한다.
Steve Bennett

69

다소 정통적인 접근 방식은 Dropbox 만 사용하는 것 입니다. 작성자에게 파일을 dropbox 디렉토리에 저장하도록하고 버전 관리 및 백업을 무료로 받으십시오. 또한 기본적으로 저자에게는 학습 곡선이 없습니다.

git의 경우 결국에는 저자에게 올바른 브랜치 버전을 제공하게 될 것이므로 git repo를 dropbox에 넣고 저자의 브랜칭 및 병합을 처리하십시오.


21
나는 같은 것을 제안하려고했다. Dropbox의 폴더를 git repo (알 필요가 없음)로 만들고 주기적으로 (예 : 매일) 커밋을 수행 할 수있는 이유는 없습니다. 그렇게하면 모든 멋진 자식 자료 (diffs, logs, bisects 등)를 무료로 얻을 수 있습니다.
Simon Whitaker

4
무료 버전은 내가 올바르게 기억하면 ~ 30 일 동안 만 버전을 저장하므로 유료 버전을 사용해야합니다.
DMan

5
여기에 다른 답변에서 제안 된 유용한 소프트웨어가 너무 많고 관련 당사자가 명시 적으로 제시된 경우 외부 서비스를 제안하고 단일 실패 지점을 소개하며 잠재적 인 침입자에게 데이터를 제공하는 답변 만 -1 할 수 있습니다 유능한 프로그래머로서.
sam hocevar

4
@DavidThornley : Dropbox실제 보안 문제에 대해 들어 보지 못했습니다 ???
sam hocevar

3
@ Sam Hocevar : 알았어요. 그것은 4 시간의 취약점으로, 반드시 좋지는 않지만 반드시 그것이 나쁜 생각이라는 것을 의미하지는 않습니다. 다시 말하지만, 글쓰기가 얼마나 민감한 지, 그리고 외부인이 볼 수있는 작은 기회가 허용되는지에 달려 있습니다. (의료 기록에는 적합하지 않지만, 허구의 허구와 완성되지 않은 소프트웨어 프로젝트를 떠나는 것에 대한 자격은 없습니다.)
David Thornley

28

정직하게 대답은 당신의 편집에있다 : "우리는 어떤 작가를 고용했습니다"- 때때로 당신은 그냥 마음이 피 묻은해야 ... 그들이 무엇을해야 할 당신의 돈을 원하는 당신은 당신이 원하는 것은 불합리 아님을 제공하고자합니다.

당신이하는 주장은 당신이 이미 발전시킨 주장입니다. 우리는 제품을 작동시키기 위해 X, Y 및 Z를 수행 할 수 있어야합니다.이를 위해서는 우리가 그렇게해야합니다. 우리는 우리가 할 수있는만큼지지 적이 될 것입니다. 그러나 이것이 효과가 있기 위해서는 (그래서 그것이 당신을위한 소득원으로 계속 이어지기 위해서는) 이것이 일어나야합니다.

적절한 Wiki 기반 솔루션이 적절하게 일치한다는 데 동의하는 경향이 있지만 여기서의 과제는 워크 플로와 요구 사항 사이에서 타협점을 찾는 방법입니다.

당신이 당신이 발생하지 않는 경우 기사, 기사에 일하는 사람들이 규칙의 합의 세트에 의해 재생이 때문에 버전 관리 할 필요가 성공적으로 프로젝트의 순서 - 나는 핵심을 반복 할 수 있습니다 것입니다 수 불에 타거나 연장하면 라이터도 마찬가지입니다.


네 말에 전적으로 동의 해. 그러나 우리 (프로그래머 팀)와 작가 사이에는 "관리"라는 것이 있습니다. 경영진은 작가들을 고용하고 그들과 함께 일하라고 말했습니다. 이들이 버전 관리를 배우기를 꺼린다는 사실은 경영진이 우리 (팀)와 그들 (프로그래머) 사이에서 "조정"되어야하는 문제라고 생각합니다.
treecoder

1
나는 일종의 추측 ...하지만 당신은 경영진에게 사건을 제기해야합니다. 그것들은 "조정되어야"하는 단어 (흥미로운 단어 선택)가 맞습니다. 그러나 타협은 두 가지 방법입니다.
Murph

예-항상 설명처럼 설명하지 않습니다.
Murph

2
@greengit 팀간에 "조정"되어야하는 문제는 경영진의 일부입니다. 한 팀에 책임을 위임하는 것은 게 으르거나 경영진이 해당 팀의 접근 방식을 선호한다는 힌트 일 수 있습니다. 따라서 귀하에게 더 적합한 솔루션을 경영진에게 제안하고 다른 모든 것에 대해 걱정하도록 제안하십시오.
yannis

3
나는 이러한 "조정"을 제안 된 변경에 대한 예산의 형태로 경영진에게 제시하는 경향이있다. "물론, 우리는 그들의 사용을 피할 수있다. (git,…) 우리는 그들을 위해 그것을하기 위해 비서를 고용해야한다. 여기에 서명하면 월요일에 인터뷰를 시작할 것이다."
BRPocock

18

전에도 이와 비슷한 상황을 처리해야했습니다. 결국 우리는 하나의 개발자 (me)를 제 3 자의 버전 관리 연락처로 지정했습니다.

제 3자는 매일 프로젝트 파일의 zip 파일을 이메일로 보냈으며 체크인 할 것입니다. 별도의 프로젝트 작업 영역과 svn 계정을 설정하고 해당 작업 영역에 파일을 압축 해제하여 해당 항목을 덮어 쓴 다음 해당 계정에서 체크인합니다.

매일하는 것이 가장 재미 있지는 않았지만 때로는 일을 끝내는 것이 더 중요합니다.

한 가지 장점은 작업을 검토하여 빌드를 손상시킬 수있는 잘못된 코드 및 데이터를 체크인하지 않았는지 확인하는 데 도움이되었다는 것입니다.


+1 가능하다면 "문제가 해결되었습니다!" 우리를 위해. 우리가 소규모 회사이기 때문이 아니기 때문에이 작업을 위해 개발자 한 명을 부분적으로 또는 전적으로 구제한다고 제안하는 것은 (멍청한) 경영진으로부터 나에게 미소를 돌려 줄 것이라고 생각하지 않습니다. 실제로 저는 경영진에 대해 그렇게 생각합니다.
treecoder

2
@greengit-이것이 당신이 생각하는 유일한 해결책이라고 제안한다면, 비용은 관리가 다른 사람들을 고용하도록 강요 할 것이며, 그들은 당신의 도구로 일할 것입니다. 물론 버전 제어를 제외한 모든 솔루션은 문제를 해결하고 문제를 해결하기 위해 추가 시간을 소비하여 문제를 해결하고 문제를 해결하기 위해 비용을 지불한다고 설명 할 수 있습니다 (두 가지 핵심 사항을 모두 무시하지 않는 한) , 문제가 발생할 것입니다. 실제로는 문제가 발생합니다).
Ramhound

3
@greengit 분명히 프로세스에 관련된 모든 것에 달려 있지만 제 경우에는 타사 파일을 체크인하는 데 하루 5 분도 걸리지 않았습니다. 프로세스를 개발하고 써드 파티를 훈련시키는 데 시간을 낭비하는 것이 저의 해결책이었습니다.
Alan Barber

그렇게 힘들어서는 안됩니다. 한 사람은 작가에서 버전 관리 시스템으로의 인터페이스입니다. 그들은 모든 변경 사항을 그에게 제출하는 것을 알고 있습니다. 변경 사항을 적용하고 커밋하는 데 1 ~ 2 분 이상 걸리지 않아야합니다.
Dan Ray

@greengit-이것은 내 대답이 될 것입니다. 예, 유용한 작업을 수행하는 데 시간이 걸립니다. 커스텀 시스템을 작성하는 데는 시간 이 걸립니다. 그리고 작가들은 여전히 ​​불평 할 것입니다.
Mike Baranczak

18

SparkleShare 는 git 기반의 dropbox-clone입니다. 귀하의 요구에 적합하다고 생각합니다.

SparkleShare는 컴퓨터에 특수 폴더를 만듭니다. 이 폴더에 원격으로 호스팅 된 폴더 (또는 "프로젝트")를 추가 할 수 있습니다. 이 프로젝트는 누군가 파일을 추가, 제거 또는 편집 할 때 호스트 및 모든 동료와 자동으로 동기화됩니다.

... 웃는 얼굴로 잘하고 덜 잘하는 것에 대한 몇 가지 예가 있습니다.

  • 텍스트, 사무실 문서 및 이미지와 같은 프로젝트 파일을 자주 변경
  • 여러 사람이 편집 한 파일 추적 및 동기화
  • 파일을 기록의 특정 지점으로 되돌리기
  • 암호화를 사용하여 서버의 파일을 감시하지 못하도록 방지

그렇게 크지 않다

  • 전체 컴퓨터 백업
  • 사진 또는 음악 컬렉션 저장
  • 비디오 편집 프로젝트와 같이 자주 변경되는 큰 이진 파일 ...

업데이트 (2015 년 11 월) : 프로젝트가 중단 된 것 같습니다 (2014 년 4 월의 마지막 릴리스).


매우 유망하지만 어쩌면 약간 미숙 할 수도 있습니다. 그래도 나는 이것을 계속 지켜 볼 것입니다.
Zsolt Török

13

투명한 VCS 사용으로 준비된 작업 공간 을 제공 할 수 있으면 VCS를 사용합니다. 프로그래머가 아닌 사람들에게 VCS를 프로그래머의 방식으로 사용하도록 가르치지 마십시오

VCS 지원 기능이 내장 된 편집기를 찾아 구성 하고 작업 과정에서 추가 단계간단하게 표시 하십시오 .

단지 예-Editplus는 Subversion에 대해 알고 편집기 창에서 기본 SVN 작업을 수행 할 수 있습니다. 최신 Editplus도 Git 통합을 위해 TortoiseGIT를 사용할 수 있습니다

편집 : 일부 대안 솔루션 발견 : EasySVN- 올바르게 구성되어 작업 사본을 모니터링하고 자동 커밋 및 자동 병합을 수행 하여 최종 사용자 및 모든 문서 형식에 대한 제작 도구사용할 수 있습니다


11

WebDAV 설정은 어떻습니까?

자동으로 직선 버전 관리 기록을 처리합니다. 네트워크 드라이브 인 것처럼 서버에 연결하기 만하면 모든 저장이 커밋됩니다.


WebDAV의 경우 +1 실제로 그 옵션에 대해서는 생각하지 않았습니다. WebDAV 서버를 배포하고 유지 관리하는 것이 얼마나 어렵다고 생각
하십니까

아파치, 서브 버전, 리포지토리를 설정하는 것은 정말 간단합니다. 그런 다음 아파치 모듈을 설치하고 구성하면 모든 작업이 완료됩니다.
Malfist

"자동으로"는 단어가 아니기 때문에 -1입니다.
dreftymac


1
서버에 Subversion + Apache + WebDAV를 설정하고 비 개발자 클라이언트에서 WebDAV 공유를 마운트하면이 대답을보다 명확하게 만들 수 있습니다. 사용자에게 적어도 하루에 한 번 WebDAV 공유 작업을 저장하도록 지시하십시오.
Jan

7

구글 문서

Google 문서 도구는 원하는 작업을 수행 할 수 있습니다. File > See Revision History변경 사항을 추적 할 수 있습니다.

또한 무료로 파일을주고받는 문제도 있습니다. 모든 사람에게 문서를 공유하면됩니다.

마지막으로 사용하기 쉽습니다. 작가는 버전 관리가 진행되고 있음을 알 필요조차 없습니다.


6

OS 불가지론

파일을 끌어다 놓을 수있는 Python 프로그램을 작성하면 해당 프로그램이 수행 할 수있는 작업 git add과 수행 할 수없는 작업을 수행 할 수 있습니다 git commit.

또는

머신에 마운트 할 수있는 WebDav 기반 파일 시스템을 사용하고 서버가 git투명하게 작업하도록하십시오 .

OSX / 리눅스

파일을 가져 와서 git에 커밋하는 Python 기반 FUSE 플러그인을 작성하십시오. 그런 다음 마운트 된 파일 시스템에서 투명하게 열고 저장할 수 있습니다. Windows 리소스에 대한 일부 FUSE가 있지만 아마도 속일 가치가 없습니다.

윈도우

파일 시스템 필터 드라이버 를 사용 하여 git작업 을 투명하게 수행하는 코드를 작성할 수 있습니다 .


5

아, 코더가 아닌 사람들의 기쁨. git / mercurial 환경을 설정하는 것이 좋습니다. 레포가 처리 할 수있는 형식으로 모든 것을 저장하도록 지시하십시오. tortoisegit 또는 tortoisehg를 사용 하면 repo가 ​​어떻게 작동하는지 필요가 없습니다 . 프로젝트 디렉토리에 느낌표가 있는지 확인하고 문제가되는 파일을 마우스 오른쪽 단추로 클릭 한 다음 커밋을 클릭하십시오. 변화에 대한 개요를 작성하십시오 (작가가 맞습니까?) 이제 끝났습니다!

워크 플로우의 추가 단계이지만 병합 / 브랜치 / 멋진 것은 아닙니다. 사전 빌드 된 환경은 이미 라이터 분기에 설정되어 있으므로 코드가 표시되지 않습니다. 스크립트가 매일 자동으로 동기화하도록합니다. 나중에 커밋에 익숙해지면 추가 기능을 보여줄 수 있습니다. 변경 사항을 확인할 수있는 기능은 작업 흐름에 몰입 한 후에는 수행 할 수없는 유용한 기능입니다.


5
내가 깨닫게 된 한 가지는 모든 (YMMV) 비 기술적 작가가 이전의 작업을 변경하면 쓸모없는 것으로 간주 한다는 것입니다. 그들은 업데이트 된 작업 (문서 또는 글로 쓴 것)이 가장 좋다고 생각하며, 과거 버전을 유지하는 것은 어리 석습니다. 우리의 경우에도, 우리는 또한 왜 우리에게 역사가 필요한지 적어도 성공적으로 설명했습니다.
treecoder

아마 @greengit. 경영진에게 어떻게 수용하고 있는지,이 간단하고 쉬운 단계가 어떻게 도움이되는지, 이것이 회사의 돈을 저축 / 수납하는 방법을 보여 주면 어쨌든 그렇게해야합니다. 비즈니스는 결론에 의해 결정되므로,이를 통해 작가를 기술 파이프 라인에 통합하고 통합 비용, 백업 (레포를 백업하고 있습니까?) 및 정보 전달 비용을 절약 할 수 있습니다.
스펜서 Rathbun

+1 또한 프로젝트 코디네이터와 고객 서비스 직원을 구성하여 TortoiseSVN을 사용했습니다. 초기 설명 (및 초기 체크 아웃 지원) 후에 변경된 버전 (대부분 사무용 문서 및 모형 이미지)을 커밋하는 데 아무런 문제가 없었습니다. 동료가 무언가를 변경하면 자동으로 최신 버전을 얻는 것을 좋아했습니다.
sleske

3

공유 포인트는 어떻습니까? 나는 개발 세계에서 인기가 없다는 것을 알고 있지만 작가가 Windows를 OS로 사용하고 있다면 잘 작동하며 실제로 버전 제어를 사용하고 있다는 것을 알지 못할 것입니다.

이 솔루션은 또한 그들이 새로운 것을 ski 아 먹는 것처럼 보이기 때문에 겁나는 것들을 다루지 못하게합니다.


이것이 우리 팀이 이미하고있는 일이므로 +1합니다.
sq33G

SharePoint에 새 버전을 업로드하는 데 더 많은 작업이 필요하기 때문에 회사의 일부 문서가있는 SharePoint에 적절한 버전 제어 시스템을 사용하는 것이 좋습니다.
Chris Morgan

2

작성자가 파일을 저장하는 파일 시스템을 모니터링하고 저장을 할 때마다 자동 커밋을 수행하는 도구를 설정할 수 있습니까?

네트워크 공유에 배치하면 전혀 관여하지 않고 모든 구성을 수행 할 수 있습니다. 그러나 팀에서 사용할 업데이트 버전을 제공 할 때마다 git에 추가됩니다.


1

플라스틱 SCM을 보았습니까? 그들은 더 사용하기 쉽게 만들려고 노력하고 있습니다.

버전이 지정된 백업 만 원한다면 Dropbox를 사용하거나 Windows 백업 서비스를 설정할 수 있습니다. 또는 Crashplan 또는 다른 유사한 제품을 설치할 수 있습니다.


DVCS 영역의 새로운 상업용 오퍼링에 대해 +1
Roland Tepp

1

Mercurial DVCS에는 EasyMercurial 이라는 사용자 인터페이스가 있으며 , 기본 버전 제어 작업에 대한 간단한보기를 제공하는 것이 목표입니다.

EasyMercurial은 다음과 같습니다.

  • 히스토리 그래프 표시를 사용하여 실제 저장소 상태를 표시하고 가르치는 간단한
    • 플랫폼 간 일관성있는 Mercurial을위한 일반적인 명령 행 워크 플로우에 근접

우리는 어떤 목적 으로든 "최고의"Mercurial 클라이언트를 생산하려고하지 않습니다. 우리는 적극적으로 사용자의 요구가 발전함에 따라 다른 클라이언트로 이동하도록 권장합니다. 목표는 단순히 공유 원격 저장소로 작업하는 소규모 프로젝트 그룹의 초보자에게 액세스 가능한 것을 제공하는 것입니다.

시도해 보는 것이 좋습니다.


1

나는 프로그래머가 아닌 사람들과 여러 번 일해야했다. (대부분 그래픽 아티스트들이다. 만약 작가들이 아티스트로서 작업 파일을 관리하는 방법에 대한 단서가 거의 없다면, 당신은 ... 흠 ... 재미 .. ). 세 가지 가능한 접근 방식이 있습니다.

  1. 프로그래머 인 척하고, 버전 관리를 사용하는 방법을 가르치십시오. 이것은 작동하지 않으며 끊임없이 싸울 것입니다.
  2. 그들에게 현재 버전을 잡고 어딘가에 붙여서 필요한 경우 어제의 파일로 되 감을 수있는 매우 간단한 도구를 작성하십시오. 이것은 가능하며 몇 년 전에 DVD 제작자 (메뉴, 그래픽, 모든 종류의 제작) 팀을 위해 몇 가지 성공을 거두었습니다. 필자가 작성한 도구는 PkZip의 원 클릭 래퍼였습니다. 얼마 전) 방금 작업 디렉토리를 압축하고 날짜 + 시간으로 아카이브 이름을 지정했습니다.
  3. 그들이 스스로 생산하는 것을 통제하십시오. 파일을 프로그래머에게 전달해야하며 프로그래머가 파일을 수락 할 때만 프로젝트의 일부가되어야합니다. 그런 다음 프로그래머는 파일을 버전 제어로 확인하고 컨텐츠는 전문적인 방식으로 관리됩니다.

개인적으로 저는 옵션 3이 최선의 방법이라고 생각합니다. 그것은 파일 배달을 가져 와서 체크인 해야하는 사람에게는 고통과 자극을 의미하지만 다른 옵션보다 적습니다.

또한 프로그래머가 아닌 사람은 생각할 수있는 오래된 파일 이름을 가진 파일을 제공 할 것입니다. 명명 규칙은 이상하게 외계인입니다. 그들은 당신에게 "Picture"라는 파일을 주거나 당신이 그들에게 잘못된 것을 말할 때 당신에게 "Picture_Final"이라는 파일을 줄 것입니다. 이 점을 지적하면 "Picture_NewFinal"이라는 다른 파일을 가져온 다음 "행운의 경우" "Picture_NewFinal2"를 얻을 수 있지만이 시점에서 역사적 발전에 대한 감각을 제압하고 "스패너 아이콘"이라고 부를 수 있습니다 의회".

다시 한 번 이름 지정 규칙을 적용하여 모든 파일을 무엇을 호출할지 미리 알려주 거나 시간을 보내면서 보낸 파일을 스크램블링하지 않고 이름을 바꿀 수 있습니다. 어쨌든 자신의 건강을 위해 스프레드 시트를 원한다고 말하면 따라갈 수 있도록하십시오. 그렇지 않을 때 놀라지 마십시오.

도움이 되길 바랍니다. 재미있게 보내십시오!


0

두 사람이 한 번에 동일한 대상에서 작업해야 할 가능성이 있고 텍스트 파일에서 모든 작업을 처리 할 수 ​​있으면 Google 문서 공유를 시도합니다.

지금까지 내가 본 것 중 최고의 멀티 에디터 / 협업 기능이 있습니다. 또한 정식 버전이며 텍스트 파일로 내보낼 수 있습니다.

그러나 이것들은 꽤 큰 두 가지 경우입니다.


0

평소처럼 파일을 저장하여 폴더에서 작업하게하십시오.

하루에 한 번 (또는 주 등) 해당 폴더의 내용을 backup_dd_mm_yyyy에 복사하십시오. 대부분의 시스템 소스 코드는 요즘 사용 가능한 공간이 주어지면 사소한 공간을 차지합니다.

복사는 귀하, 제 3 자, 도구 또는 스크립트에 의해 수행 될 수 있습니다.

이것은 손실을 하루로 제한하고 역사를 제공하며 투명합니다.

어느 당사자에게나 완벽하지는 않지만 중간 입장을 취하려는 답변입니다.

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