이미지를 git 저장소에 저장해야합니까? 이미지는 변경되지 않습니다.

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

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

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



답변

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

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

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

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

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


답변

왜 안돼? 🙂

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

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

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

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

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


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


답변

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

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

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)을 넣는 데 아무런 문제가 없었습니다.