직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 git11 Git push는 성공했는데 태그가 없을 때: 브랜치와 태그 전송 구분 브랜치 push가 성공했다고 로컬 태그도 모두 원격에 전송됐다고 가정하지 마세요. 로컬 태그의 존재와 대상 커밋을 확인하고, 실제 push 옵션·설정이 태그를 포함했는지 나누어 확인해야 합니다.적용 환경: Git 명령행 저장소와 원격 태그 목록 조회 권한; 실제 저장소 폴더에서 실행, 아래 명령은 로컬 조회 예시이며 원격 push는 실행하지 않음. 자료 확인일: 2026-10-29. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 브랜치와 태그는 별도의 참조다Git Book은 기본 git push가 태그를 자동 전송하지 않는다고 설명합니다. 다만 실제 동작은 명령의 refspec과 push.followTags 같은 설정의 영향을 받습니다. 성공 메시지 하나로 무.. 2026. 10. 30. Git 과거 로그가 짧게 보일 때: shallow clone 여부부터 확인 CI나 새 복제본에서 과거 커밋이 보이지 않으면 먼저 shallow clone 여부를 확인하세요. 이력을 일부만 내려받은 상황은 커밋을 잃어버린 상황과 다르므로, 복구 명령보다 저장소와 조회 범위를 먼저 구분해야 합니다.적용 환경: Git의 --is-shallow-repository 옵션을 지원하는 로컬 저장소 또는 CI 체크아웃; 명령은 그 저장소 디렉터리에서 실행. 자료 확인일: 2026-10-28. 공식 문서와 별도 임시 저장소 시험을 구분해 안내합니다. 실제 운영·외부 원격 저장소에서 실행한 결과가 아닙니다.1. 원인: clone 깊이가 이력 탐색을 제한한다git clone --depth는 지정한 커밋 수로 이력을 제한하는 얕은 복제를 만듭니다. 기본적으로 단일 브랜치 복제를 함께 뜻하므로, 서버.. 2026. 10. 29. Git 브랜치가 다른 worktree에서 사용 중일 때: 강제 전환 전 확인 순서 브랜치가 다른 worktree에서 이미 체크아웃됐다는 오류가 나오면 먼저 git worktree list로 경로를 찾으세요. 강제 옵션이나 폴더 삭제부터 실행하지 말고, 그 경로에서 작업 중인 변경이 있는지 확인하는 것이 우선입니다.적용 환경: git worktree를 지원하는 Git 저장소; 연결된 작업 폴더 접근 가능. 자료 확인일: 2026-10-27. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 저장소 하나에 작업 폴더가 여러 개Git worktree는 한 저장소에 여러 작업 디렉터리를 연결할 수 있게 합니다. 이미 다른 작업 트리에서 체크아웃한 브랜치를 새 작업 트리에 사용하려 하면 기본적으로 거절됩니다.오류를 브랜치 손상으로 단정하지 마세요. IDE나 자동화가 만든 폴더가 .. 2026. 10. 28. git add를 취소하고 파일은 남기려면: restore --staged 확인 순서 git add만 취소하고 편집한 파일을 남기려면 작업 트리가 아니라 인덱스를 대상으로 해야 합니다. 커밋이 있는 저장소에서 git restore --staged로 특정 파일의 스테이징을 취소한 뒤, 파일 내용과 두 diff를 확인하세요.적용 환경: git restore를 지원하는 Git 2.23 이상, 커밋이 존재하는 로컬 저장소의 추적 파일. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 같은 restore라도 바꾸는 대상이 다름형태기본 대상과 주의restore --staged인덱스 복원; 기본 원본 HEADrestore작업 트리 복원; 미보존 편집 유실 위험--staged --worktree양쪽 변경; 단순 add 취소와 다름파일을 일부만 스테이징.. 2026. 10. 27. Git 커밋을 잃어버렸을 때: reflog 확인 후 복구 브랜치부터 만드는 순서 reset이나 rebase 뒤 커밋이 보이지 않으면 먼저 로컬 reflog에서 후보를 찾고 내용을 확인하세요. 바로 reset --hard를 실행하기보다 새 복구 브랜치를 만들어 후보 커밋을 보존하는 편이 현재 작업을 보호하기 쉽습니다.적용 환경: reflog와 해당 커밋 객체가 남아 있는 로컬 Git 저장소. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 현재 브랜치에서 안 보이는 것과 삭제는 다릅니다reflog는 로컬 참조가 이동한 기록입니다. HEAD 기록에는 브랜치 전환도 포함됩니다. 일반 커밋 이력과 다르며 원격 저장소와 같은 기록을 공유한다고 가정하면 안 됩니다.이 방법은 커밋 객체와 필요한 기록이 남아 있을 때의 경로입니다. 커밋하지 않은.. 2026. 10. 26. git stash 후 새 파일이 남을 때: 미추적 파일과 무시 파일 구분 git stash 뒤에 새 파일이 남는다면 먼저 미추적 파일인지, 무시된 파일인지 구분하세요. 기본 보관 범위에 새 파일이 모두 포함된다고 가정하면 작업을 잃을 수 있습니다.적용 환경: Git CLI; git --version과 설치된 git stash 도움말 확인. 공식 문서 확인일: 2026-10-23. 아래 내용은 문서 기반 점검 가이드이며 운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 파일 상태마다 포함 범위가 다릅니다파일 상태보관 옵션을 볼 때추적 중인 변경기본 stash 범위 확인미추적 파일-u 포함 여부 확인무시된 파일-u만으로 포함되지 않음status의 짧은 형식에서 ??는 미추적, --ignored로 표시한 !!는 무시된 경로입니다. 표시 범위를 좁혀 놓았다면 파일이 안 보일 수.. 2026. 10. 24. 이전 1 2 다음
