문제

물론 GIT (Mercurial, SVN 등)와 같은 소스 제어 도구는 소스 코드 관리에 큰 도움이 될 수 있습니다.그러나 이러한 도구가 Photoshop PSD 및 Illustrator AI 파일과 같은 파일 사본을 저장하는 데 사용될 때 개발자에게 이점을 제공 하는가?이러한 종류의 파일에 이러한 도구를 사용하는 것이 합리적입니까?이 모든 파일의 파일 크기의 합보다 저장소에 저장을 덜 저장합니까?이 파일의 파일 형식은 기계를 읽을 수 있지만, 그러한 애플리케이션에서, 특히 래스터 그래픽보다는 벡터를 처리 할 때 이러한 파일의 작은 부분이 변경 될 것이며 나머지의 대부분은 동일하게 유지 될 것으로 기대합니다. .

귀하의 통찰력에 감사드립니다.

도움이 되었습니까?

해결책 2

이것은 매우 의견이 많은 문제이지만, 적어도 git에게는 거절합니다.

  • GIT는 저장 솔루션으로 만들어지지 않았습니다.
  • 이미지 파일을 병합 할 방법이 없습니다.
  • 따라서 분기는 의미가 없습니다.이 분기를 함께 병합하는 유일한 방법은 어떤 버전이 올바른지 선택하는 것이라면 파일을 즉시 교체하는 것이 좋습니다.
  • Git Gui 도구는 콘솔보다 열등하며 간단하지 않습니다. 당신은 당신의 미술 팀을 가르치고 싶습니까?
  • git repo를 확인하면 체크 아웃합니다 전체 역사 모든 파일 중에서 초기 커밋부터 시작합니다. 이진 파일에서 충분히 오래 작업하면 크기가 엄청납니다.
  • GitHub와 같은 많은 GIT 호스팅 사이트는 개별 파일 크기에 제한이 있습니다.

나는 당신이 Dropbox로 훨씬 나아질 것이라고 생각합니다.

다른 팁

Git 자체는 너무 크거나 많지 않은 한 모든 종류의 데이터를 관리할 수 있습니다.
보다 "대용량 파일이 있는 git"(크기나 숫자에 있어서 "큰").

그림/그래픽 비교는 Git에서 기본적으로 지원하는 기능은 아니지만 Git 저장소 호스팅 서비스는 웹 GUI를 확장하여 이러한 지원을 제공할 수 있습니다.

GitHub가 방금 발표했습니다(2014년 6월).ePSD 보기 및 비교", 이는 " 이미지 보기 및 비교" (11월.2011)

저장소의 모든 PSD 자산은 이미지처럼 처리됩니다. 즉, 해당 자산을 인라인으로 볼 수 있고 세 가지 이미지 보기 모드를 사용하여 커밋에서 변경된 사항을 확인할 수 있습니다.

마하 2022 업데이트:이것은 더 이상 지원되지 않습니다.
보다 "코드가 아닌 파일 작업" diff가 지원되는 파일의 경우.

https://cloud.githubusercontent.com/assets/2546/3165594/55f2798a-eb56-11e3-92e7-b79ad791a697.gif

"아니오"에 대답하는 사람들은 아주 좋은 이유가 있지만 불가능하지는 않습니다.

GitHub를 사용하여 관리합니다 오픈 소스 프로젝트 수백 개의 일러스트 레이터 파일과 PDF (및 일부 코드와 텍스트, 그러나 이는 비교할 때 작은 블립입니다). 리포는 약 8GB로 나옵니다. 내가 너무 미쳤던 일을하는 이유는 일러스트 레이터 파일이 제품의 핵심이기 때문입니다. 원천 프로젝트의 - 그리고 나는 그것이 오픈 소스를 유지하기를 원했기 때문입니다.

몇 가지 고집 지점과 알아야 할 것들이있었습니다. 내가 제안 할게:

  • 당신이 git에 익숙하지 않으면 이것을 시도하지 마십시오. 갈등과 분기 문제를 해결하면 실제로 가시가 생길 수 있으며, repo를 행복하게 유지하기 위해 예쁜 비전적인 작업을 수행해야 할 수도 있습니다. 아무도 당신이 git의 모든 구석 구석을 알기를 기대하지는 않지만 (나는 제정신이 할 수 있을지 확신 할 수는 없지만) 나머지는 구글을 할 수 있다는 것을 충분히 알고 있습니다.

  • 명령 줄에서 GIT를 사용하는 것이 편안한 지 확인하십시오. GUI 도구는 복잡성에서 벗어날 수 있지만 커버 아래에서 무슨 일이 일어나고 있는지 완전히 이해하지 못하게합니다. 그런 이해를 얻으면 95%의 시간 동안 GUI를 자유롭게 사용할 수 있습니다.

  • 가능하면 분기를 피하십시오. 이진 파일은 코드가하는 방식을 병합하지 않으므로 지점을 모으면 지저분하고 힘들 수 있습니다.

  • 레포의 크기와 복잡성을 관리하는 데 도움이되는 GIT의 특정 기능에 대해 알아보십시오 : 부분 체크 아웃, 태그, git gc, 등

  • 미리 계획을 세우십시오. 프로젝트를 둘 이상의 GIT 저장소로 분리하거나 다른 서비스와 결합하여 혜택을 볼 수 있습니다.

  • 호스팅 서비스를 사용하는 경우 REPO에 어떤 한계가 부과되는지 알아야합니다. 예를 들어, Github는 100MB 이상의 파일에 대해 불평합니다. 다음은 바이너리에 대한 권장 지침입니다.

아니요, 버전 추적에는 git, svn 등을 사용하지 않는 것이 좋습니다. 놀라운 양의 라인은 간신히 변경된 버전의 Adobe 파일 사이에서 변경 될 것입니다. Diff 비교를 통해 직접 확인하십시오. 이는 일러스트 레이터에서 기본 파일 압축과 같은 옵션이 켜질 때 특히 그렇습니다.

레이어, 링크 및 이정표 버전의 파일 저장을 신중하게 사용하면 SVN이 기본 Adobe 파일에 제공 할 수있는 것보다 훨씬 더 효율적으로 스토리지를 사용하게됩니다.

내가 생각할 수있는 예외는 Pure-Vector SVG와 같은 XML 기반 파일에 대한 것입니다.

간단한 UI를 사용하여 간단한 버전 관리가 필요하다면 Subversion은 이러한 파일을 관리하는 데 매우 효과적입니다. 그것은 쉘 통합을 통해 좋은 GUI 지원 (예 : SmartSVN 또는 TortoisesVN)을 가지고 있습니다. 필요한 파일 만 선택적으로 확인하는 것이 훨씬 쉽습니다.

파일의 크기가 큰 문제라고 지적하면서 여러분 모두에게 git-lfs 그 문제를 해결하기 위해 온다.

설치 및 사용이 쉽고 다음과 같은 인기있는 플랫폼 github, gitlab 또는 비트 버킷 아무런 문제없이 지원하십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top