직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 git11 git diff가 비어 있는데 변경이 남을 때: 작업 트리·인덱스·HEAD 비교 git add 뒤 일반 git diff가 비어 있다면 변경이 사라졌다고 판단하지 말고 git diff --cached를 확인하세요. 기본 diff는 작업 트리와 인덱스를, --cached는 인덱스와 HEAD를 비교합니다. 먼저 상태와 비교 범위를 읽고 되돌리기 명령은 사용하지 않는 것이 안전합니다.원인: diff가 비교하는 두 상태를 놓친다같은 파일도 작업 트리, 스테이징 영역인 인덱스, 마지막 커밋인 HEAD에 서로 다른 내용이 있을 수 있습니다. git add는 이후 커밋할 내용을 인덱스에 올립니다. 그 뒤 작업 파일을 다시 바꾸지 않았다면 기본 diff는 비어 있을 수 있지만, 인덱스와 HEAD의 차이는 남습니다.조회 명령비교 범위읽을 의미git diff작업 트리 ↔ 인덱스아직 스테이징하지 않은 수.. 2026. 10. 23. gitignore가 적용되지 않을 때: 추적 파일과 규칙 일치를 따로 확인 이미 Git이 추적하는 파일에는 .gitignore를 추가해도 추적이 자동 해제되지 않습니다. 먼저 git ls-files로 추적 상태를 보고, git check-ignore로 규칙을 확인하세요. 두 질문을 섞으면 정상 동작을 캐시 오류로 오해하기 쉽습니다.원인: 추적 상태와 무시 규칙은 다른 문제다무시 규칙은 의도적으로 추적하지 않을 파일에 사용합니다. 이미 인덱스에 있는 파일을 계속 수정하고 있다면 규칙을 추가해도 변경이 보일 수 있습니다. 먼저 저장소 루트와 대상 경로를 확인하고, 파일 내용에 비밀값이 있으면 출력이나 화면 공유에 포함하지 마세요.관찰확인할 질문다음 단계ls-files에 파일 표시이미 추적 중인가추적 유지 필요성 검토미추적인데 규칙 불일치패턴·위치가 맞나check-ignore 진단규.. 2026. 10. 22. Git unrelated histories 해결: 원격 주소와 공통 조상부터 확인 refusing to merge unrelated histories는 두 이력의 공통 조상을 찾지 못한 상황에서 나타날 수 있습니다. 먼저 저장소·원격 주소·비교 대상이 맞는지 확인하세요. 의도적으로 독립된 이력을 합치는 경우에만 --allow-unrelated-histories를 검토하고, 원본 보존과 충돌 검토를 먼저 준비합니다.원인: 같은 파일이 있어도 같은 커밋 이력은 아니다로컬과 원격에서 각각 새 저장소를 초기화했거나 다른 저장소를 연결하면 파일 이름이 비슷해도 이력이 독립적일 수 있습니다. 오류를 없애기 위해 곧바로 강제 푸시하거나 .git을 삭제하면 보존해야 할 기록을 잃을 수 있습니다.상태우선 확인피할 조치원격 주소 불일치저장소 선택무조건 병합이력 제한 가능clone 범위독립 이력 단정독립.. 2026. 10. 21. Git detached HEAD 해결: 브랜치 이동 전에 커밋을 보존하는 순서 detached HEAD는 저장소가 고장 났다는 뜻이 아닙니다. 브랜치 이름 대신 특정 커밋을 보고 있는 상태입니다. 그 상태에서 만든 커밋을 남기려면 다른 브랜치로 이동하기 전에 현재 커밋에 새 브랜치를 붙이세요. 이미 이동했다면 reflog에서 실제 커밋을 확인한 뒤 복구 브랜치를 만듭니다.원인: 브랜치가 아니라 커밋을 체크아웃했다태그나 커밋 ID로 이전 버전을 확인하면 현재 위치가 브랜치와 떨어질 수 있습니다. 이 상태에서도 커밋은 만들 수 있지만 새 커밋이 원래 브랜치를 자동으로 앞으로 이동시키지는 않습니다. CI가 특정 커밋을 정확히 빌드하려고 이런 상태를 만드는 경우도 있으므로 경고만 보고 수정할 필요는 없습니다.상태먼저 할 일피할 일현재 detached 커밋 유지새 브랜치 생성먼저 다른 곳 .. 2026. 10. 19. Docker·CI Git dubious ownership 해결: UID·마운트·safe.directory 점검 Docker나 CI에서 detected dubious ownership in repository가 나오면 Git 실행 사용자와 저장소의 실제 소유자를 먼저 비교하세요. UID·GID와 마운트 설계를 맞추는 것이 우선이며, 의도적으로 공유하는 신뢰된 저장소만 정확한 경로의 safe.directory 예외로 검토합니다. 모든 저장소를 신뢰하는 와일드카드 설정은 사용하지 않습니다. 이 글은 Git 소유권 검사이며 Docker 소켓 권한이나 파일 쓰기 권한 오류와는 별도입니다.원인: 쓰기 권한과 저장소 소유권 검사는 다르다호스트의 저장소를 컨테이너에 bind mount하면 컨테이너가 보는 경로와 실행 사용자가 호스트 작업 환경과 다를 수 있습니다. 파일을 읽거나 쓸 수 있어도 Git이 다른 소유자의 저장소를 신.. 2026. 10. 16. 이전 1 2 다음
