이 질문을 해결하기 위해 단톡방에 물었다. 답은 여럿이었고 공통된 답으로 받은 내용은 이 통째로 보관된 결과물을 Git에 올리게 된다면 변경사항을 업로드하거나 내려받을 때 시간이 오래 걸릴거고, 작업 폴더 안 .git 폴더의 용량도 크게 늘게 될 것이라는 것이다. 다른 이유로는 보안상의 이유, 난독화된 것을 무엇하러 올리나? 등이 있다. 무엇보다 GPT에게 물어보니 정확한 답변을 얻을 수 있었다.
누군가가 GitHub에 빌드된 파일을 업로드하지 않기로 결정하는 데에는 여러 가지 이유가 있을 수 있습니다.
파일 크기: 빌드된 파일은 소스 코드 자체보다 클 수 있으며, 특히 컴파일된 언어나 이미지 및 비디오와 같은 자산이 포함된 프로젝트에서는 더욱 그렇습니다. GitHub에 대용량 파일을 업로드하면 많은 저장 공간을 소비할 수 있으며 리포지토리 성능이 저하될 수 있습니다.
버전 제어: Git과 같은 버전 제어 시스템은 주로 소스 코드 파일의 변경 사항을 추적하도록 설계되었습니다. 버전 제어에 빌드된 파일을 포함하면 저장소 기록이 복잡해지고 의미 있는 변경 사항을 추적하기가 더 어려워질 수 있습니다.
재현성: 개발자는 빌드된 파일을 포함하지 않음으로써 저장소를 복제하는 사람은 누구나 소스 코드에서 프로젝트를 쉽게 빌드할 수 있도록 보장합니다. 이는 재현성을 촉진하고 다양한 시스템에서 일관된 개발 환경을 허용합니다.
보안: 리포지토리에 빌드된 파일을 포함하면 특히 해당 파일에 하드코딩된 비밀이나 구성 설정이 포함된 경우 중요한 정보나 자격 증명이 실수로 노출될 수 있습니다.
그러나 정적 웹 사이트를 배포하거나 컴파일된 소프트웨어를 배포하는 경우와 같이 빌드된 파일을 포함해야 하는 상황이 있습니다. 이러한 경우에는 장단점을 고려하고 대규모 바이너리 파일에 Git LFS(대형 파일 저장소)를 사용하거나 종속성 관리를 위해 패키지 관리자를 활용하는 등 빌드된 아티팩트를 관리하기 위한 모범 사례를 구현하는 것이 중요합니다.
There could be several reasons why someone might choose not to upload built files to GitHub:
File size: Built files can often be larger than the source code itself, especially in projects involving compiled languages or assets like images and videos. Uploading large files to GitHub can consume a lot of storage space and may slow down the repository's performance.
Version control: Version control systems like Git are primarily designed to track changes to source code files. Including built files in version control can clutter the repository history and make it harder to track meaningful changes.
Reproducibility: By not including built files, developers ensure that anyone cloning the repository can easily build the project from the source code. This promotes reproducibility and allows for consistent development environments across different machines.
Security: Including built files in a repository may inadvertently expose sensitive information or credentials, especially if those files contain hardcoded secrets or configuration settings.
However, there are situations where including built files might be necessary, such as when deploying static websites or distributing compiled software. In such cases, it's important to consider the trade-offs and implement best practices for managing built artifacts, such as using Git LFS (Large File Storage) for large binary files or leveraging package managers for dependency management.
그리고 외주를 받은 프로젝트를 깃으로 관리할 때는 보통 프라이빗 레포를 쓴다고들 한다.
'형상관리 Git' 카테고리의 다른 글
깃(git)기본 설정 관련 crlf (0) | 2024.10.03 |
---|---|
로컬에 대응하는 원격 브랜치, HEADER에 대하여 (0) | 2024.05.27 |
[Workout프로젝트 깃 일지] 변경된 로컬의 develop브랜치의 내용 원격의 main브랜치에 반영하기 (0) | 2024.03.23 |
[Workout프로젝트 깃 일지] 원격에 새로운 브랜치(develop) 생성후 로컬에서 develop브랜치로 push하기 (1) | 2024.03.23 |
git merge와 rebase에 대하여 (0) | 2024.03.21 |