Git and Version Control in Mobile Development: What It Is, Basic Commands and How It Works

Version Control and Git: What Is It?

Git is a distributed version control system (VCS) created by Linus Torvalds in 2005 for Linux kernel development. Unlike centralized systems (SVN, CVS), Git stores a complete copy of the project history on every developer's computer. This means you can make commits, browse history, and create branches even without internet access.

Git works with snapshots — each commit saves the state of all project files at the time of saving. If a file hasn't changed, Git creates a reference to the previous version, saving space. According to GitHub analysis (2025), the average repository contains 1,200 commits and 15 branches.

At IT Sectr, we have been using Git since 2017 across all projects. Our experience shows that proper Git configuration from day one saves the team up to 30% of time on merging and resolving conflicts. Git has become the de facto standard — it is supported by all modern IDEs (Android Studio, Xcode, VS Code) and CI/CD systems.

# Basic Git setup
git config --global user.name "Your Name"
git config --global user.email "your@email.com"

# Creating a new repository
git init my-project
cd my-project

# Adding files and committing
git add README.md
git commit -m "Initial commit"

# Working with a remote repository
git remote add origin https://github.com/user/my-project.git
git push -u origin main

The code above shows the basic sequence: initializing a repository, first commit, and publishing to a remote server. The git init command creates a hidden .git folder that will store the entire project history. Each git commit creates a restore point you can return to at any time.

Basic Concepts: Repository, Branch, Commit

Understanding the three basic concepts — Repository, Branch, and Commit — is essential for working with any version control system. A repository is a container for the entire project. A commit is a saved state of files. A branch is a separate line of development.

Repository can be local (on your computer) or remote (on a GitHub, GitLab server). Each developer clones the remote repository to their machine and works with a local copy. Changes are synchronized via push (send) and pull (fetch). In distributed version control, each developer stores a complete copy of the history.

Branch is a pointer to one of the commits. Branches allow parallel development: one developer works on a new feature (feature branch), another fixes a bug (hotfix branch), a third prepares a release (release branch). According to GitLab Flow (2025), the average project has 3–5 active branches simultaneously.

Commit is a unit of change. Each commit contains a unique hash (SHA-1), a message, an author, and a timestamp. Good practice is to make small meaningful commits with descriptive messages — this simplifies Code Review and rollback. Version control through commits gives you the complete project history.

Feature Branch

Feature Branch is a temporary branch created from develop or main for developing a specific task. After completing the work, the branch is merged back via Pull Request and deleted. This practice allows isolating changes without disrupting the stability of the main codebase.

Typical workflow: create branch feature/add-login → make several commits → create Pull Request → go through Code Review → merge into develop. At IT Sectr we use exactly this approach: each Jira task corresponds to a separate feature branch. This simplifies change tracking and rollback if needed.

Rebase vs Merge

Merge creates a merge commit that combines two branches. It preserves the full history, including parallel development lines. Rebase rewrites history: it takes commits from one branch and "reapplies" them on top of another, creating a linear history.

Merge is better suited for public branches and large teams where chronology matters. Rebase is convenient for personal feature branches before creating a PR — it makes history cleaner and more understandable. However, rebase should never be applied to branches others are working on, as it rewrites history.

# Creating and switching to a feature branch
git checkout -b feature/add-login main

# Working in the branch
git add login-screen/
git commit -m "Add login screen layout"

# Rebase onto latest main before PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push to remote repository
git push origin feature/add-login

This example shows a typical workflow: creating a feature branch from main, several commits, and rebase to get a clean linear history before sending for review. This approach minimizes merge conflicts.

Git Flow vs Trunk-Based Development

Git Flow and Trunk-Based Development are two main version control strategies that determine how a team organizes work with Git. The choice depends on team size, release frequency, and stability requirements.

Git Flow is a strict model with multiple permanent branches: main (release code), develop (current development), feature/* (new features), release/* (release preparation) and hotfix/* (urgent fixes). This model is good for projects with clear release cycles (e.g., mobile apps with versions 1.0, 2.0).

Trunk-Based Development is an approach with a single main branch (trunk/main) where all developers merge changes several times a day. Feature flags are used to hide incomplete features. This approach is popular in web development and startups where delivery speed matters.

Git Flow

Git Flow, proposed by Vincent Driessen in 2010, remains one of the most popular models. Its main advantage is strict code separation by lifecycle stages. The main branch contains only release code, develop contains current development, and feature branches isolate new features from each other.

Hotfix branches are created from main for urgent fixes and after merging are merged back into both main and develop. Release branches are created from develop when the team is ready for a release. Only bug fixes and metadata (version, build) are added to them. After release, the release branch is merged into main and develop. According to a JetBrains survey (2024), Git Flow is used by 37% of teams. This version control model remains the standard for projects with fixed releases.

# Git Flow example: starting work on a release
git checkout -b release/1.2.0 develop

# Fixing bugs in the release branch
git commit -m "Fix login button crash"

# Completing the release — merge into main and 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

# Deleting the release branch
git branch -d release/1.2.0

The code illustrates creating a release branch, stabilizing it, and merging into the main branches. The --no-ff flag guarantees a merge commit, preserving information that the changes came from the release branch.

Pull Request and Code Review

Pull Request (PR) is a mechanism by which a developer proposes changes from their branch to the main branch. PR is a key element of version control in team work — it is not just a way to merge code, but a process of discussion, review, and quality checking. In GitLab, the similar mechanism is called Merge Request (MR), but the essence is the same: notify the team about changes and get approval.

A good PR should be small (up to 300 lines of code), focused on a single task, and contain a description of what was done and why. According to a Google study (2025), PRs over 400 lines take twice as long to review, and the probability of detecting bugs decreases by 30%. Code Review is code checking by another developer before merging.

At IT Sectr, we practice mandatory Code Review for every PR. This not only improves code quality but also helps spread knowledge within the team. Code Review checks: whether the code follows architectural principles, whether there are bugs, whether there are enough tests, whether variables are properly named. All comments are discussed in the PR until merging.

Platforms: GitHub, GitLab, Bitbucket

Git is a protocol, but for collaboration you need a version control platform that provides a web interface, access management, CI/CD, and review tools. Three platforms dominate the market: GitHub, GitLab, and Bitbucket.

GitHub is the largest platform with over 56 million developers. Owned by Microsoft, it offers Actions (CI/CD), Pages (hosting), Discussions, and Copilot. The free plan includes unlimited private repositories for teams of up to 3 people. GitHub is popular in the open-source community.

GitLab is a full DevOps platform with integrated CI/CD, container registry, and infrastructure management. Unlike GitHub, GitLab can be installed on your own server (Self-Managed). Bitbucket by Atlassian is tightly integrated with Jira and Confluence, making it the choice for teams already using the Atlassian ecosystem.