You have spent the whole weekend on your app and you are proud and tired. You decide to move one button a little to the right. You change a few lines, save, refresh, and everything is broken. Ctrl+Z doesn’t help, it is 2 a.m., and you can’t remember what you changed. This is the problem Git and GitHub solve. This guide explains both in simple words and shows how mobile app developers use them to track changes, work in a team and never lose working code.
Why app developers need Git
Imagine two friends building a college project. You wrote 4,000 lines of code and your friend wrote 1,000. In front of the professor, your friend claims they wrote the 4,000. How do you prove who wrote what? The same question appears in companies, where thousands of people write code together.
Git answers it. It is a version control system: it tracks your code and records who changed which line, with their name and email. It also lets you go back in time. Add a payment gateway, find it doesn’t work, and one command takes you back to the last good version instead of hunting through many files by hand.
Git is free and open source, fast, and works for small and large projects alike. Teams at companies like Google and Netflix use it every day, and open-source projects like Linux, React and Python are built by thousands of contributors through GitHub.
Git vs GitHub
They are different things:
- Git is a tool that runs on your computer. It tracks every change, like saving checkpoints along the way.
- GitHub is a website where you store that code online, share it and collaborate with others. GitLab is an equivalent website.
Think of an Instagram profile: GitHub is where you show your work. Developers put their GitHub link on their resume so recruiters can check real projects. A project folder on GitHub is called a repository, or “repo” for short.
Commits: saving checkpoints
A commit is a checkpoint, a snapshot of your code at one moment. Write the header, commit. Add the body, commit. Add the footer, commit. If the next feature breaks things, you jump back to the last good snapshot.
The three steps: add, commit, push
Saving a change takes two steps on your computer and a third to share it. A fun way to remember it: add is the engagement, commit is the wedding. You can think of staging as collecting changes in a shopping cart before you check out.
Here is the workflow you will use 90% of the time. First tell Git who you are (once per computer):
git config --global user.name "Your Name"
git config --global user.email "you@example.com"Then, in your project folder:
git init # start tracking this folder
git status # what changed?
git add . # stage all changes
git commit -m "Add login page" # save a checkpoint
git remote add origin <repo-url>
git push -u origin main # send it to GitHubWrite meaningful commit messages, such as “Add Apple login option” or “Fix crash on startup”, so your history is useful later.
git status shows each file as untracked (new, Git doesn’t know it yet), modified (changed), or staged (added and ready to commit). After a commit, the files are clean again. A hidden .git folder inside your project is where Git keeps all this history.
About the word origin: a remote is a nickname for an online copy of your repo. “origin” is the common name for the one on GitHub. (You could call it anything, but your teammates would be confused.)
Branches and merging
A branch is a parallel universe of your project. You can experiment on it without touching your main version. If the experiment fails, delete the branch. If it works, merge it into main.
Branches also let a team work at the same time: one developer builds a feature, another fixes a bug, and nobody waits for the others.
git branch # list branches
git checkout -b feature-1 # create and switch to a new branch
git checkout main # switch back
git merge feature-1 # bring feature-1 into main (run on main)
git branch -d feature-1 # delete a branch you no longer needNew repositories on GitHub use main as the default branch name. Older setups used master. Rename yours with git branch -m main if needed.
Merge conflicts
A conflict happens when two branches change the same line of the same file. Git can’t tell which version to keep, so it asks you. Your editor (such as VS Code) marks the clash and offers buttons: accept current change, accept incoming change or accept both. Delete the conflict markers, keep what you want, then add and commit.
Using GitHub with your team
- Clone:
git clone <url>copies a repo from GitHub to your computer. Using the HTTPS link is the easiest way to start. - Push: send your commits to GitHub. Pull:
git pull origin mainbrings your teammates’ changes down. - Pull request (PR): a request to merge your branch into main. A senior developer reviews it, can comment, and then accepts or rejects it. Merging the PR creates its own commit.
- Fork: your own copy of someone else’s repo on your GitHub account, useful for contributing to open source. Only open a pull request when you have a useful change.
- README.md: a file that explains what your project is and how to use it.
Tips for mobile projects
Git works the same for Flutter, React Native, Android and iOS apps. A few habits help mobile teams in particular:
- One branch per feature, such as push notifications, login or offline mode, so a broken experiment never reaches main.
- Commit before risky changes, like upgrading Gradle, a plugin or a state management package. If the build fails, you can go back.
- Keep secrets out of Git. Signing keystores, Apple
.p8keys, service account files and API keys should never be committed, especially to a public repo. - Use a
.gitignorefile to skip generated folders such asbuild/andnode_modules/.
Undoing mistakes
| Situation | Command |
|---|---|
| You staged a file by mistake | git reset <file> (or git reset for everything) |
| Undo the last commit, keep your changes | git reset HEAD~1 |
| Go back to a specific commit | git log, copy the hash, then git reset <hash> |
| Go back and also discard changes in your files | git reset --hard <hash> |
| See what differs between branches | git diff main |
Careful with --hard. It removes your uncommitted changes from your files for good. Also avoid rewriting history that you have already pushed and shared with teammates.
FAQ
What is the difference between Git and GitHub?
Git is a tool on your computer that tracks changes. GitHub is a website that stores your Git repositories online so you can share and collaborate.
Do I need GitHub to use Git?
No. Git works fully on your own computer. GitHub is for sharing, backup and teamwork.
What is a commit?
A saved snapshot of your project at one moment, with a message that says what changed.
What is a pull request?
A request to merge your branch into another branch (usually main), so teammates can review the change first.
How do I fix a merge conflict?
Open the conflicted file, choose which lines to keep, remove the conflict markers, then add and commit.
Should I use Git for a small project?
Yes. Even small projects benefit from history and backups, and it is a skill every developer is expected to have.
Conclusion
Git keeps the history of your code, GitHub lets you share it, and together they let mobile app developers experiment safely, work in teams and recover from mistakes in seconds. Start small: git init, git add, git commit and git push cover most of your daily work. Add branches when you start building features, and pull requests when you work with others. Once these habits are in place, a broken 2 a.m. build stops being a disaster and becomes one command away from fixed.