모바일 개발에서 Git 및 버전 관리: 개념, 기본 명령어 및 작동 방식

버전 관리 및 Git: 무엇인가?

Git은 2005년 리누스 토르발스가 Linux 커널 개발을 위해 만든 분산 버전 관리 시스템(VCS)입니다. 중앙 집중식 시스템(SVN, CVS)과 달리 Git은 각 개발자의 컴퓨터에 프로젝트 기록의 전체 복사본을 저장합니다. 즉, 인터넷 연결 없이도 커밋, 기록 탐색 및 브랜치 생성이 가능합니다.

Git은 스냅샷으로 작동합니다 — 각 커밋은 저장 시점의 모든 프로젝트 파일 상태를 저장합니다. 파일이 변경되지 않은 경우 Git은 이전 버전에 대한 참조를 생성하여 공간을 절약합니다. GitHub 분석(2025)에 따르면 평균 저장소에는 1,200개의 커밋과 15개의 브랜치가 있습니다.

IT Sectr에서는 2017년부터 모든 프로젝트에서 Git을 사용하고 있습니다. 우리의 경험에 따르면 첫날부터 적절한 Git 구성을 통해 팀의 병합 및 충돌 해결 시간을 최대 30%까지 절약할 수 있습니다. Git은 사실상의 표준이 되었으며 모든 최신 IDE(Android Studio, Xcode, VS Code) 및 CI/CD 시스템에서 지원됩니다.

# 기본 Git 설정
git config --global user.name "이름"
git config --global user.email "your@email.com"

# 새 저장소 만들기
git init my-project
cd my-project

# 파일 추가 및 커밋
git add README.md
git commit -m "Initial commit"

# 원격 저장소 작업
git remote add origin https://github.com/user/my-project.git
git push -u origin main

위 코드는 기본 시퀀스를 보여줍니다: 저장소 초기화, 첫 번째 커밋, 원격 서버에 게시.git init 명령어는 전체 프로젝트 기록을 저장할 숨겨진 .git 폴더를 만듭니다. 각 git commit은 언제든지 돌아갈 수 있는 복원 지점을 만듭니다.

기본 개념: Repository, Branch, Commit

세 가지 기본 개념 — Repository, Branch, Commit — 을 이해하는 것은 모든 버전 관리 시스템 작업에 필수적입니다. 저장소는 전체 프로젝트의 컨테이너입니다. Commit은 파일의 저장된 상태입니다. Branch는 별도의 개발 라인입니다.

Repository(저장소)는 로컬(컴퓨터) 또는 원격(GitHub, GitLab 서버)일 수 있습니다. 각 개발자는 원격 저장소를 자신의 컴퓨터에 복제하고 로컬 복사본으로 작업합니다. 변경 사항은 push(보내기) 및 pull(가져오기)을 통해 동기화됩니다. 분산 버전 관리에서 각 개발자는 기록의 전체 복사본을 저장합니다.

Branch(브랜치)는 커밋 중 하나를 가리키는 포인터입니다. 브랜치는 병렬 개발을 가능하게 합니다: 한 개발자는 새 기능(feature branch)을 작업하고, 다른 개발자는 버그를 수정(hotfix branch)하며, 세 번째 개발자는 릴리스를 준비(release branch)합니다. GitLab Flow(2025)에 따르면 평균 프로젝트에는 동시에 3~5개의 활성 브랜치가 있습니다.

Commit(커밋)은 변경 단위입니다. 각 커밋에는 고유한 해시(SHA-1), 메시지, 작성자 및 타임스탬프가 포함됩니다. 좋은 방법은 설명적인 메시지와 함께 작고 의미 있는 커밋을 만드는 것입니다 — 이렇게 하면 코드 리뷰와 변경 롤백이 간소화됩니다. 커밋을 통한 버전 관리는 완전한 프로젝트 기록을 제공합니다.

Feature Branch

Feature Branch(기능 브랜치)는 특정 작업 개발을 위해 develop 또는 main에서 생성되는 임시 브랜치입니다. 작업 완료 후 브랜치는 Pull Request를 통해 병합되고 삭제됩니다. 이 방법은 주요 코드베이스의 안정성을 방해하지 않고 변경 사항을 격리할 수 있게 해줍니다.

일반적인 워크플로: feature/add-login 브랜치 생성 → 여러 커밋 → Pull Request 생성 → 코드 리뷰 통과 → develop에 병합. IT Sectr에서는 정확히 이 방식을 사용합니다: 각 Jira 작업은 별도의 feature 브랜치에 해당합니다. 이렇게 하면 변경 추적과 필요시 롤백이 간편해집니다.

Rebase vs Merge

Merge는 두 브랜치를 결합하는 병합 커밋을 만듭니다. 병렬 개발 라인을 포함한 전체 기록을 보존합니다. Rebase는 기록을 다시 씁니다: 한 브랜치에서 커밋을 가져와 다른 브랜치 위에 "재적용"하여 선형 기록을 만듭니다.

Merge는 연대순이 중요한 공개 브랜치와 대규모 팀에 더 적합합니다.Rebase는 PR을 만들기 전 개인 기능 브랜치에 편리합니다 — 기록을 더 깔끔하고 이해하기 쉽게 만듭니다. 그러나 rebase는 기록을 다시 쓰기 때문에 다른 개발자가 작업 중인 브랜치에는 절대 적용해서는 안 됩니다.

# 기능 브랜치 생성 및 전환
git checkout -b feature/add-login main

# 브랜치에서 작업
git add login-screen/
git commit -m "Add login screen layout"

# PR 전 최신 main으로 Rebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# 원격 저장소에 Push
git push origin feature/add-login

이 예제는 일반적인 워크플로를 보여줍니다: main에서 기능 브랜치 생성, 여러 커밋, 리뷰 제출 전 깔끔한 선형 기록을 위한 rebase. 이 방식은 병합 충돌을 최소화합니다.

Git Flow vs Trunk-Based Development

Git Flow와 Trunk-Based Development는 팀이 Git 작업을 구성하는 방식을 결정하는 두 가지 주요 버전 관리 전략입니다. 선택은 팀 규모, 릴리스 빈도 및 안정성 요구 사항에 따라 달라집니다.

Git Flow는 여러 영구 브랜치가 있는 엄격한 모델입니다: main(릴리스 코드), develop(현재 개발), feature/*(새 기능), release/*(릴리스 준비) 및 hotfix/*(긴급 수정). 이 모델은 명확한 릴리스 주기가 있는 프로젝트(예: 버전 1.0, 2.0이 있는 모바일 앱)에 적합합니다.

Trunk-Based Development는 모든 개발자가 하루에 여러 번 변경 사항을 병합하는 단일 메인 브랜치(trunk/main) 접근 방식입니다. 미완성 기능을 숨기기 위해 기능 플래그가 사용됩니다. 이 접근 방식은 납기 속도가 중요한 웹 개발 및 스타트업에서 인기가 있습니다.

Git Flow

Git Flow는 2010년 Vincent Driessen이 제안했으며 여전히 가장 인기 있는 모델 중 하나입니다. 주요 장점은 수명 주기 단계별로 코드를 엄격하게 분리하는 것입니다. main 브랜치에는 릴리스 코드만 포함되고, develop에는 현재 개발이 포함되며, 기능 브랜치는 새 기능을 서로 분리합니다.

Hotfix 브랜치는 긴급 수정을 위해 main에서 생성되며 병합 후 main과 develop 모두에 다시 병합됩니다.Release 브랜치는 팀이 릴리스 준비가 되었을 때 develop에서 생성됩니다. 버그 수정 및 메타데이터(버전, 빌드)만 추가됩니다. 릴리스 후 release 브랜치는 main과 develop에 병합됩니다. JetBrains 설문조사(2024)에 따르면 팀의 37%가 Git Flow를 사용합니다. 이 버전 관리 모델은 고정 릴리스가 있는 프로젝트의 표준으로 남아 있습니다.

# Git Flow 예: 릴리스 작업 시작
git checkout -b release/1.2.0 develop

# release 브랜치에서 버그 수정
git commit -m "Fix login button crash"

# 릴리스 완료 — main과 develop에 병합
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# release 브랜치 삭제
git branch -d release/1.2.0

코드는 release 브랜치 생성, 안정화 및 메인 브랜치에 병합을 보여줍니다. --no-ff 플래그는 병합 커밋을 보장하여 변경 사항이 release 브랜치에서 왔다는 정보를 보존합니다.

Pull Request 및 코드 리뷰

Pull Request(PR)는 개발자가 자신의 브랜치에서 메인 브랜치로 변경 사항을 제안하는 메커니즘입니다. PR은 팀 작업에서 버전 관리의 핵심 요소입니다 — 단순히 코드를 병합하는 방법이 아니라 논의, 검토 및 품질 확인의 과정입니다. GitLab에서는 유사한 메커니즘을 Merge Request(MR)이라고 하지만 본질은 동일합니다: 팀에 변경 사항을 알리고 승인을 받는 것입니다.

좋은 PR은 작고(최대 300줄), 단일 작업에 집중하며, 수행된 작업과 이유에 대한 설명을 포함해야 합니다. Google 연구(2025)에 따르면 400줄이 넘는 PR은 검토 시간이 두 배로 걸리고 버그 발견 확률이 30% 감소합니다. 코드 리뷰(Code Review)는 병합 전에 다른 개발자가 코드를 확인하는 것입니다.

IT Sectr에서는 모든 PR에 대해 필수 코드 리뷰를 시행합니다. 이는 코드 품질을 향상시킬 뿐만 아니라 팀 내 지식 공유에도 도움이 됩니다. 코드 리뷰는 다음을 확인합니다: 코드가 아키텍처 원칙을 따르는지, 버그가 없는지, 충분한 테스트가 있는지, 변수 이름이 적절한지. 모든 의견은 병합될 때까지 PR에서 논의됩니다.

플랫폼: GitHub, GitLab, Bitbucket

Git은 프로토콜이지만 협업을 위해서는 웹 인터페이스, 액세스 관리, CI/CD 및 검토 도구를 제공하는 버전 관리 플랫폼이 필요합니다. 시장을 지배하는 세 가지 플랫폼은 GitHub, GitLab 및 Bitbucket입니다.

GitHub는 5,600만 명 이상의 개발자를 보유한 가장 큰 플랫폼입니다. Microsoft 소유로 Actions(CI/CD), Pages(호스팅), Discussions 및 Copilot을 제공합니다. 무료 요금제는 최대 3명 팀의 무제한 개인 저장소를 포함합니다. GitHub는 오픈 소스 커뮤니티에서 인기가 있습니다.

GitLab은 통합 CI/CD, 컨테이너 레지스트리 및 인프라 관리를 갖춘 완전한 DevOps 플랫폼입니다. GitHub와 달리 GitLab은 자체 서버에 설치할 수 있습니다(Self-Managed). Atlassian의 Bitbucket은 Jira 및 Confluence와 긴밀하게 통합되어 있어 이미 Atlassian 생태계를 사용하는 팀에게 적합합니다.