이미지를 git 저장소에 저장해야합니까?

Git 및 Github를 버전 제어로 사용하는 분산 팀의 경우 이미지도 git 저장소에 저장해야합니까?

대부분의 경우 이미지는 변경되지 않습니다. 이미지가 추가되면 폴더가 포함 된 폴더의 크기 만 커집니다. 큰 이미지 또는 많은 이미지의 조합으로 인해 이미지 폴더가 시간이 지남에 따라 큰 크기로 커질 수 있습니다.

이것이 모범 사례로 간주됩니까? 분산 된 팀이 쉽게 액세스 할 수있는 프로젝트에 필요한 이진 파일을 공유하기위한 다른 대안은 무엇입니까?

이미지가 독창적으로 작동합니까 아니면 다른 곳에서 복구 (보증) 할 수 있습니까? 소스로 구축 된 소프트웨어 유닛을 배송해야합니까? 원본 인 경우 백업이 필요합니다. 변경하지 않으면 공간 페널티는 백업과 동일하며 필요한 곳에 있습니다.

실수로 또는 의도적으로 소프트웨어의 모양을 변경하도록 편집 할 수 있습니까? 예-그렇다면 어떻게 든 수정 제어해야합니다. 이미 완벽한 솔루션이있을 때 다른 방법을 사용해야하는 이유는 무엇입니까? 암흑기부터 "복사 및 이름 바꾸기"버전 제어를 도입하는 이유는 무엇입니까?

나는 그래픽 디자이너의 MacBook 하드 드라이브가 죽었을 때 전체 프로젝트의 원래 작품이 "가짜"가되는 것을 보았습니다. 그 이유는 무한한 지혜를 가진 누군가가 "이진은 rev 컨트롤에 속하지 않는다"고 그래픽 디자이너 (최소한 하나는이 작품은 아닙니다) )는 백업에 좋지 않은 경향이 있습니다.

위의 기준에 맞는 모든 바이너리 파일에도 동일하게 적용됩니다.

하지 않는 유일한 이유는 디스크 공간입니다. 나는 테라 바이트 당 $ 100가 무서워서, 그 변명은 약간 얇아지고있다.

왜 안돼? :)

바이너리를 저장하는 것은 나쁜 습관으로 간주되지만 이미지에 대해 너무 걱정하지 마십시오.

최악의 경우 톤이있는 경우 다른 곳에 저장하거나 외부 또는 바이너리 지원을위한 확장을 사용하십시오. 그리고 이미지가 자주 바뀌지 않는다면 문제는 어디에 있습니까? 뚱뚱한 델타를 얻지 못할 것입니다. 그리고 시간이 지남에 따라 제거되면 서버 만 기록을 저장하는 데 어려움을 겪지 만 클라이언트는 아무것도 볼 수 없습니다.

제 생각에는 GB를 저장하지 않기 때문에 걱정할 필요가 없습니다.

당신은 무엇을 할 수 있지만 일은, 단지 저장 "소스"이미지입니다 : 등 SVGs, 고무 매크로, ... 그리고 빌드 시스템에 의해 생성 된 최종 이미지를 가지고있다. 가능하다면 더 좋을 것입니다. 그렇지 않다면 귀찮게하지 마십시오.

(Git은 텍스트 파일에는 빛을 발하지만 사진에 가장 적합한 VCS는 아닙니다. 가능하면 더 많은 컨텍스트와 메트릭을 제공하십시오)

자세한 내용은 다음 Q & A를 참조하십시오.

• SubVersion / Git에 이미지 파일 저장
• 텍스트 파일이 아닌 Git vs SVN
• Git 및 Git 하위 모듈로 큰 이진 파일 관리

이 질문은 꽤 오래되었지만 이것은 Git을 다룰 때 발생하는 일반적인 질문이며 마지막 답변 이후 Git 저장소에 큰 파일을 저장하는 현대적인 솔루션에 대한 진전이 있습니다.

Git에 큰 파일을 저장하기 위해 다음 프로젝트가 있습니다.

• git-annex- 이것은 잠시 동안 있었지만 솔직히 복잡해졌습니다.
• git-media- 이것에 대한 개인적인 경험이 없습니다. 상당히 복잡한 것 같습니다.
• git-fit- 더 간단한 플러그인을 만들려고합니다. S3 스토리지가 필요합니다. 플러그인에 대한 나의 주요 관심사는 단순성에 감사하지만, 1 명의 개인에 의해 상당히 알려지지 않고 유지된다는 것입니다 (완전한 공개, 나는 현재 유일한 다른 커미터이며 사소한 문제였습니다).
• git-lfs- 이것을 광범위하게 사용하지는 않았지만 성배 인 것처럼 보입니다. Github의 지원을받으며 2015 년 10 월 현재 모든 리포지토리에서 사용할 수 있으며 리포지토리를 저장하는 사이트에서 파일 관리가 복잡해집니다. 유일한 단점은 있지만 많은 지원이,이없는 Github에서 넘어 때문에이 상당히 새로운 점이다 Gitlab도 지원을하고 , Gitea을처럼 , 그리고 의 Bitbucket 미래에 지원을 언급했다 .

TLDR : 가능하다면 git-lfs 를 사용 하여 이미지 나 다른 바이너리 파일을 git에 저장하십시오.

전체 "소스 제어에 바이너리를 저장하지 마십시오"는 다음과 같은 특정 이유로 설명됩니다. 컴파일하는 소스 코드가있는 경우 실제 컴파일은 저장하지 말고 소스 코드 만 저장하십시오. 이미지 및 시각적 자산에는 "소스"가 없으므로 버전 관리에서 추적 해야 합니다.

Git의 권장 방법은 기본적으로 기본 모듈과 관련된 별도의 저장소 인 하위 모듈 (Git 1.5.3에서 도입 됨)을 사용하는 것입니다. 하위 모듈에 이미지 및 기타 이진 자산을 저장합니다. 그런 다음 기본 리포지토리에서 체크 아웃하거나 필요한 항목에 따라 남겨 둘 수 있습니다.

에서 http://book.git-scm.com/5_submodules.html

"깃의 서브 모듈 지원은 저장소가 외부 프로젝트의 체크 아웃을 서브 디렉토리로 포함 할 수있게한다. 서브 모듈은 자신의 고유성을 유지한다; 서브 모듈 지원은 서브 모듈 저장소 위치와 커밋 ID를 저장하기 때문에 포함하는 프로젝트를 복제하는 다른 개발자들 (" superproject ")를 사용하면 동일한 버전으로 모든 하위 모듈을 쉽게 복제 할 수 있습니다. 수퍼 프로젝트의 일부 체크 아웃이 가능합니다. Git에 하위 모듈 중 일부 또는 전부를 복제하지 않도록 지시 할 수 있습니다."

또한 이미지가 자주 바뀌지 않는 경우 크기는 큰 문제가되지 않습니다. 다음과 같이 크기를 제거 / 감소하는 명령을 실행할 수도 있습니다.

git gc
git gc-aggressive
git prune

예 .

소프트웨어 버전 1.0을 출시한다고 가정하겠습니다. 버전 2.0의 경우 모든 그림을 그림자와 함께 다시 실행하기로 결정했습니다. 따라서이 작업을 수행하고 2.0을 릴리스하십시오. 그런 다음 1.0을 사용하고 2.0으로 업그레이드 할 수없는 일부 고객은 다른 언어로 프로그램을 원한다고 결정합니다. 그들은 당신에게 그것을하기 위해 당신에게 $ 1G를 주므로, 당신은 확실히 말한다. 그러나 다른 문화권에서는 일부 그림이 이해가되지 않으므로 변경해야합니다 ...

이미지를 소스 제어 상태로 유지하려면 1.0을 기반으로 이미지를 변경하고 (빌드, 릴리스) 쉽게 수행 할 수 있습니다. 소스 컨트롤에 이러한 이미지가 없으면 이전 이미지를 찾아서 변경 한 다음 빌드해야하므로 시간이 훨씬 더 어려워집니다.

프로젝트의 일부인 경우 VCS에 있어야합니다 . 최선을 다하는 방법은 VCS 또는 프로젝트 구성 방법에 따라 달라질 수 있습니다. 아마도 디자이너를위한 리포지토리와 코더 리포지토리의 결과 또는 '이미지 소스'만 있습니다 (한 번 .svg 파일이있는 프로젝트와 make / inscape cli를 통해 생성 된 이미지가 있음).

그러나 VCS가 처리 할 수 ​​없거나 사용할 수 없게되면 작업에 적합한 도구가 아니라고 말할 수 있습니다.

지금까지 git의 웹 프로젝트에 '일반적인'양의 그래픽 (mockups, concepts 및 page graphics)을 넣는 데 아무런 문제가 없었습니다.

SCM에 이미지를 저장해야합니까? 의심없이.

git에 이미지를 저장하면 더 까다로워집니다.

git은 텍스트 파일에 매우 좋지만 본질적으로 바이너리로는 너무 뜨겁지 않습니다. 복제하거나 푸시 할 때 전송되는 데이터 크기에 문제가 있으며 .git 디렉토리가 커지고 병합으로 인해 혼란에 빠질 수 있습니다 (예 : 2 개의 이미지를 병합하는 방법!)

하나의 대답은 서브 모듈을 사용하는 것입니다. 이는 프로젝트와 이미지 사이의 링크가 약해 짐을 의미하므로 이미지를 소스의 일부인 것처럼 관리하지 않아도 이미지를 제어하면서 계속 관리 할 필요는 없습니다. 하위 프로젝트가 일반적인 개발 프로세스 동안 동일한 변동을 거치지 않는 '평평한'데이터 저장소라고 가정하면 분기에 대한 걱정.

다른 대답은 프로젝트를 다른 프로젝트에 배치하고 분기하지 말고 프로젝트에 참여하는 모든 사람이 즉시 업스트림으로 푸시하도록 보장하는 것입니다. 두 사람이 같은 버전의 파일을 변경하지 못하게하십시오. git as aspect는 비 분산 워크 플로우를 위해 설계되지 않았습니다. 이 규칙을 적용하려면 구식 통신 방법을 사용해야합니다.

세 번째 답변은 이미지 작업에 더 적합한 다른 SCM에 배치하는 것입니다.

@haylem의 대답에 덧붙여서 크기가 큰 영향을 미친다는 점에 유의하십시오. VCS에 따라 많은 이미지에서 제대로 작동하지 않을 수 있습니다. 클론이나 큰 푸시가 밤새 걸리기 시작하면 모든 이미지가 이미 저장소에 있으므로 너무 늦습니다.

큰 그림과 미래의 성장을 계획하십시오. 이 프로젝트에 2 년이 걸리지 않기를 원하며 "아마도, 레포가 너무 큽니다."

기술적으로 경제적으로 저장하는 것이 가능하다는 데 동의합니다. 질문 "이 이미지는 배송 제품의 일부 또는 배송 제품 내용의 일부입니까?" GIT (또는 다른 VCS)에 콘텐츠를 저장할 수는 없지만 별도의 VCS에 대해서는 별도의 문제입니다.