APP DEVELOPMENT TERM
Git·GitHub
코드 변경 기록과 협업 저장소
Git은 소스코드가 언제 어떻게 바뀌었는지 기록하고 이전 상태를 찾게 하는 버전 관리 도구이고, GitHub는 Git 저장소를 온라인에서 보관하며 검토·권한·협업 기능을 제공하는 서비스입니다.
30초 이해
Git은 변경 이력을 관리하는 방식이고 GitHub는 그 이력을 팀이 함께 보관하고 검토하는 온라인 공간입니다
앱 소스코드는 한 번 완성하고 끝나는 파일이 아닙니다. 기능 추가와 오류 수정이 이어지므로 누가 무엇을 왜 바꿨는지 기록하고, 문제가 생겼을 때 직전 정상 상태를 찾을 수 있어야 합니다. Git이 이 변경 이력을 관리합니다.
GitHub는 Git 자체와 같은 말이 아닙니다. Git으로 관리하는 저장소를 온라인에 두고 브랜치, Pull Request, 코드 리뷰와 팀 권한을 연결하는 서비스입니다. 외주 개발을 맡겼다면 개인 계정에만 저장하지 말고 회사나 서비스 운영 주체가 저장소와 최고관리 권한을 보유해야 합니다.
한 장으로 이해
코드 변경이 Git 기록과 GitHub 협업 저장소에 남는 과정
파일을 수정한 뒤 의미 있는 변경으로 기록하고 온라인 저장소에 공유해 검토·통합·인수 가능한 상태로 관리합니다.
- 01
파일 변경
기능 추가나 오류 수정으로 소스코드와 설정이 바뀝니다.
- 02
Git 기록
관련 변경을 커밋으로 묶고 작성자·시점·이유를 남깁니다.
- 03
GitHub 공유
온라인 저장소에 올려 팀이 같은 이력과 코드를 봅니다.
- 04
검토·통합
권한에 따라 변경을 검토하고 운영 기준 코드에 합칩니다.
저장소 주소만 아는 것보다 소유 명의, 최고관리자, 접근 권한과 운영 중인 코드가 어느 저장소에 연결됐는지를 함께 확인해야 합니다.
언제 사용하는 개념인가요?
여러 사람이 함께 개발할 때
각자의 변경을 분리해 기록하고 충돌과 누락을 줄이며 하나의 기준 코드로 합칩니다.
오류 원인을 찾을 때
문제가 생기기 전후의 변경과 작성 이유를 비교해 원인 범위를 좁힙니다.
개발사를 바꾸거나 인수할 때
최신 소스뿐 아니라 전체 변경 이력과 저장소 관리 권한을 운영 주체로 이전합니다.
왜 중요한가요?
개발 결과물의 변경 이력을 보존합니다
최종 압축 파일 하나가 아니라 기능이 만들어지고 수정된 과정을 추적할 수 있습니다.
코드 검토와 배포의 출발점이 됩니다
검토된 변경만 합치고 자동 빌드·테스트·배포와 연결할 기준 저장소를 만듭니다.
업체 변경과 장기 운영 위험을 줄입니다
특정 개발자 개인 계정에 종속되지 않고 회사가 접근과 인수 권한을 통제할 수 있습니다.
실제 상황 예시
예약 앱 소스코드를 외부 개발팀과 관리한다면
회사가 저장소를 소유하고 개발자는 필요한 범위의 권한으로 작업하도록 구성합니다.
개발 시작 때 정할 기준
- 회사 명의 GitHub 조직과 비공개 저장소 생성
- 개발자별 개인 계정 초대와 역할 구분
- 기준 브랜치와 변경 검토 방식 합의
- 운영 서비스와 연결된 저장소·브랜치 기록
인수·운영 때 확인할 항목
- 퇴사자·종료 업체 권한 회수
- 최신 코드와 배포 버전 연결 확인
- 저장소 외 데이터·설정 별도 백업
- 소유자와 결제·보안 알림 수신자 점검
개발사가 만든 개인 저장소를 단순히 공유받기보다 운영 주체가 소유한 공간에 코드와 이력이 지속적으로 쌓이게 해야 합니다.
자주 하는 오해
“Git과 GitHub는 같은 프로그램이다”
Git은 변경 이력을 관리하는 도구이고 GitHub는 Git 저장소를 호스팅하며 협업 기능을 제공하는 서비스입니다.
“GitHub에 있으면 모두에게 공개된다”
저장소를 비공개로 만들고 사용자별 권한을 설정할 수 있습니다. 공개 여부와 초대된 계정을 확인해야 합니다.
“GitHub가 있으면 전체 서비스가 백업된다”
대개 소스코드 중심입니다. 데이터베이스, 사용자 파일, 운영 비밀값과 외부 서비스 계정은 별도로 백업·인수해야 합니다.
우리 서비스에 적용할 때 확인하세요
- 1저장소 소유 조직과 최고관리자는 회사 명의인가요?
- 2운영 중인 앱·서버가 어느 저장소와 브랜치에서 배포됐는지 아나요?
- 3각 개발자와 외부 업체의 권한이 역할에 맞게 제한됐나요?
- 4퇴사·계약 종료 시 접근 권한을 회수하는 절차가 있나요?
- 5데이터베이스·파일·환경 설정은 별도 백업하고 있나요?
공식 참고
서비스 기준은 공식 문서에서 다시 확인하세요
다음 자료
이해한 내용을 바로 적용해보세요
Git 기록을 실제 작업 단위로 나누는 브랜치·커밋과 변경을 검토해 합치는 Pull Request, 인수할 원본인 소스코드를 이어서 확인하세요.
회사 소유 저장소와 운영 코드의 연결부터 확인하세요
저장소 주소, 최고관리자, 개발자 권한과 실제 배포 기준 브랜치를 한 문서에 남기면 인수와 운영 위험을 줄일 수 있습니다.