축소 된 CSS를 Git에 저장해야합니까?

Gulp를 사용하여 작업중 인 프로젝트의 SASS 코드에서 축소 된 CSS를 생성합니다.

Git에서 라이브로 푸시 할 때이 축소 된 CSS를 재생성하는 것이 모범 사례로 간주되는지 궁금합니다 ...

또는

축소 된 CSS 파일을 Git에 저장하여 서버 측에서 더 이상 작업하지 않고 프로덕션에 자동으로 푸시됩니까?

이것에 대한 사람들의 아이디어에 감사드립니다. 감사!

— 코너 거니
소스

css / js / etc를 축소 한 곳은 한 곳뿐입니다. 저장해야합니다 : /dev/null.

— R .. GitHub 중지 지원 얼음

(이것은 귀하의 웹 서버가 gzipped 전송을 완벽하게 사용할 수 있기 때문입니다.)

— R .. GitHub 중지 도움말 얼음

압축 된 CSS와 압축되지 않은 CSS를 모두 저장하면 동일한 버전의 두 가지 버전이 있습니다. 정식 버전은 무엇입니까? 한 개발자가 압축 CSS를 업데이트하고 다른 사람이 압축되지 않은 CSS를 업데이트하는 시나리오를 쉽게 상상할 수 있습니다. 두 자산이 분산되었습니다. 물론 프로세스는 이것을 막아야하지만 팀의 새로운 개발자와 같은 현실적인 전망을해야합니다.

— Qwerky

답변:

"때에 따라 다르지." 일반적인 개발 추적의 경우 아니요. 그러나 클라우드 및 DevOps 배포의 경우 종종 편리하거나 필요합니다.

대부분 @ptyx는 정확합니다 . 실제로, 그의 "아니오"는 다소 강조 될 수있다. "No. No! OMG NO! " 와 같은 것

Git과 같은 소스 제어 시스템에 축소 또는 압축 자산을 저장하지 않는 이유는 무엇입니까?

소스 코드에서 빌드 프로세스를 통해 거의 사소하게 재생성 할 수 있습니다. 압축 자산 저장은 기본적으로 동일한 논리 컨텐츠를 두 번 저장합니다. "반복하지 마십시오"(일명 DRY ) 원칙을 위반합니다 .
덜 철학적이지만 더 실용적인 이유는 최소화 / 최적화 된 자산이 Git에 저장 될 때 압축성이 매우 낮기 때문입니다. 소스 제어 시스템은 저장된 각 파일의 다른 버전 간의 변경 ( "델타")을 인식하여 작동합니다. 이를 위해 최신 파일을 이전 버전과 "차이"로 만들고이 델타를 사용하여 파일의 모든 버전의 전체 사본을 저장하지 않습니다. 그러나 최소화 / 최적화 단계에서 수행 된 변환은 종종 diff / delta 알고리즘이 사용 하는 유사점과 중간 점을 제거합니다 . 가장 간단한 예는 줄 바꿈 및 기타 공백을 제거하는 것입니다. 결과 자산은 종종 하나의 긴 줄입니다. 웹 빌드 프로세스의 많은 부분 (예 : Babel , UglifyJS , Browserify ,Less 및 Sass / SCSS 는 자산을 공격적으로 변환합니다. 그들의 결과물은 교란 할 수있다. 작은 입력 변경으로 인해 출력이 크게 변경 될 수 있습니다. 결과적으로, diff-algorithm은 매번 거의 완전히 다른 파일을 본다고 종종 믿습니다. 결과적으로 리포지토리가 더 빨리 커집니다. 디스크가 충분히 클 수 있고 네트워크가 충분히 빠르기 때문에 큰 걱정거리는 아닙니다. 특히 축소 / 최적화 된 자산을 두 번 저장할 가치가있는 경우 (포인트 1 기준) 여분의 사본은 100 % 무의미 할 수 있습니다 고창증.

그러나 DevOps / 클라우드 배포 에는 예외가 있습니다. 많은 클라우드 공급 업체 및 DevOps 팀은 Git 및 유사 기능을 사용하여 개발 업데이트를 추적 할뿐만 아니라 애플리케이션 및 자산을 테스트 및 프로덕션 서버에 적극적으로 배치합니다. 이 역할에서 Git의 "변경된 파일"을 효율적으로 결정할 수있는 능력 "각 파일에서 변경된 내용"을 결정하는보다 세부적인 기능만큼 중요합니다. Git이 최소화 / 최적화 된 자산에 대해 거의 전체 파일 사본을 수행해야하는 경우, 그렇지 않은 경우보다 약간 오래 걸리지 만 여전히 각 프로젝트에서 "모든 파일"의 사본을 피하는 데 도움이되는 훌륭한 작업을 수행하므로 큰 문제가되지 않습니다. 배포주기.

Git을 배포 엔진으로 사용하는 경우 Git에 축소 / 최적화 된 자산을 저장하면 "아니오"로 전환 될 수 있습니다. 바람직하다. 실제로 배포 할 서버 / 서비스에 대한 강력한 빌드 / 사후 처리 기회가없는 경우 필요할 수 있습니다. (이 경우 개발 및 배포 자산을 분할하는 방법은 별도의 웜 캔입니다. 지금은 단일 통합 리포지토리, 여러 분기, 하위 리포지토리 또는 여러 개의 중복 리포지토리를 포함하여 여러 가지 방법으로 관리 할 수 있음을 알 수 있습니다. )

— 조나단 유니스
소스

감사합니다! 매우 감사. 더 잘 설명 된 것처럼 이것을 대신 답변으로 표시했습니다.

— 코너 거니

git은 델타 만 저장하지 않습니다. SVN 은하지만 git은 파일을 저장하기 위해 훨씬 더 복잡한 메커니즘을 사용합니다. 어떤 사람들은 모든 파일의 전체 사본을 저장한다고 말하지만, 내가 이해 한 바에 따르면 이것은 잘못된 것입니다. 나는 그것에 대해 완전히 명확하지 않기 때문에 그것이하는 일에 들어 가려고하지 않을 것입니다.

— jpmc26

"새로운 델타 만 저장하십시오"라는 줄을 따라 변경하여 뉘앙스를 얻을 수 있다고 생각합니다. "이 델타를 사용하여 모든 버전의 파일 사본을 완전히 저장하지 마십시오." 그것은 당신의 요점을 만들고, 사실이 정확하며, 주어진 소스 제어 시스템에 대해 그것이 어떻게 수행되는지에 대한 문제를 파헤 치지 않을 것입니다.

— jpmc26

DevOps가 git hooks를 사용하여 배포 된 서버에서 최소화를 자동으로 트리거하여 두 가지 이점을 모두 활용할 수 있습니까?

— Buttle Butkus

@ButtleButkus 배포 된 서버에 따라 다릅니다. 포스트 후크에 의존하려면 대상에 적절한 트랜스 필러, 축소 기 및 옵티마이 저가 있다고 가정하거나 포스트 후크를 실행하기 전에로드해야합니다. 1 /는 멍청이입니다. 2 /는 모든 배포에로드 비용 / 지연을 부과합니다. 또한 새로운 가능한 실패 모드와 원격의 불투명 한 일시적 환경에서 포스트 후크를 디버깅하기위한 요구 사항을 소개합니다. 이상적이지 않습니다. 따라서 고리는 은색 총알이 아닙니다. 사전 변환 / 최적화 자산은 우아하지 않지만 강력하고 실용적입니다.

— Jonathan Eunice

아니.

소스 컨트롤은 소스 만 포함해야합니다. 소스에서 생성 된 경우 소스에 속하지 않으며 빌드 프로세스에서 생성해야합니다.

중간 빌드 아티팩트를 소스 제어하지 않으려는 근본적인 이유는 실행하는 경우 방금 수정 한 소스 또는 다시 빌드하지 못한 중간 제품에서 실행중인 것이 무엇인지 신뢰할 수 없기 때문입니다. .

— ptyx
소스

실행 코드를 생각하는 방식으로 생성 된 코드를 생각하십시오.

— candied_orange

이 원칙이 항상 사실은 아닙니다. 헤비급 도구로 생성 된 파일이있는 경우 사용자가 가질 것으로 예상 할 수없는 경우 생성 된 파일을 git에 넣는 것이 좋습니다. 많은 사람들 configure이 이런 이유로 생성 된 autoconf 스크립트를 git에 넣습니다 .

— R .. GitHub 중지 지원 얼음

@R .. : 이상적으로는 그러한 것들에 대해 별도의 아티팩트 저장소를 유지하지만 현실은 거의 이상적이지 않습니다.

— Kevin

@R 당신은 타협 할 수 있습니다 – 그러나 그것은 단지 그것입니다. CSS 축소의 경우 도구가 '무거운'또는 '느린'또는 '불편'한 것으로 생각되지 않습니다. 또한 잘 작동하고 소스 컨트롤에 생성 된 코드를 넣을 필요가없는 대체 종속성 주입 메커니즘 (maven, ivy ...)이 있습니다.

— ptyx

@ButtleButkus 나는 devops 사례에 대해 많은 전문 지식이 없습니다. 내가 본 것은 git은 순전히 소스 제어가 아닌 (매우 편리하고 유연한) 전송 / 릴리스 / 배포 메커니즘으로 사용됩니다. 'source'git과 'delivery'git이 분리되어 있지 않으면 (별도의 repos 또는 별도의 분기) 소스-> 빌드-> 제공 가능한 체인을 다소 손상시켜야합니다. 예를 들어 소스 코드가있는 프로덕션으로 끝납니다 추가 브랜치가 있고 사용되지 않는 바이너리 제품으로 개발되었습니다. 실용적인 타협이지만 가능할 때 분리하는 것을 선호합니다.

— ptyx