EN
RU
ES
ZH
FR
DE
PT
AR
HI
Git workflow for Swift developers: how not to go crazy and break production
Admit it honestly: how many times have you seen a commit with the message "fix" or "changes" in the shared branch? And how many times has a merge conflict taken an hour of your life because someone forgot to pull before committing? If you are a Swift developer working in a team — from a hobby project to a large app like "Tinkoff" or "Yandex.Maps" — sooner or later you will face chaos in Git.
The good news: a proper git workflow for Swift developers turns a repository from a battlefield into a well-organized system. In this article, we will break down which approaches actually work for iOS and macOS projects, how to set up code review without pain, and why CI/CD should be built into your process from day one.
Let's go!
1. Why the standard git workflow often breaks with Swift
Swift projects have their own specifics: Xcode projects, storyboards (or SwiftUI), Podfile / SPM dependencies, and binary assets (images, fonts). While in a typical web project a merge conflict can be resolved in 30 seconds, in iOS it can take half an hour due to .xcodeproj or .xcworkspace.
The main problems that a well-designed git workflow for Swift developers solves:
- Conflicts in .xcodeproj — when two developers add files simultaneously;
- Messy commit history — "WIP", "changes", "more changes";
- Lack of code review — bugs that get into main and break the build;
- Broken CI — tests fail, but nobody notices until release.
2. Git Flow vs GitHub Flow: what to choose for a Swift project?
The classic Git Flow (develop, release, hotfix, feature branches) is a powerful but heavyweight approach. It is ideal for large projects with clear release cycles, for example, when you are building an app for a bank with versions 1.0, 1.1, 2.0 and strict QA.
On the other hand, GitHub Flow (all changes via feature branches and Pull Requests into main) is a lightweight option for startups and teams that deploy every day. It also works for Swift projects, but with caveats: if you have storyboards or XIBs, the merge into main must be as clean as possible.
When to use Git Flow in Swift
- Large enterprise projects with long release cycles (e.g., banking, telemedicine);
- Multiple parallel versions (v1.0 in support, v2.0 in development);
- Strict requirements for the stability of the main branch.
When to use GitHub Flow in Swift
- Startups and medium projects with fast deployment;
- Teams of up to 10 people;
- Projects using SwiftUI (fewer conflicts in references).
Personally, I recommend a hybrid: Git Flow with a simplified develop branch — this is the ideal balance for medium-complexity Swift projects.
3. Setting up a feature branch: rules that will save your nerves
Each new feature is a separate branch from develop (or main, if you use GitHub Flow). Here is a simple template I use in my projects:
git checkout developgit pull --rebase origin developgit checkout -b feature/SPT-123-login-screenImportant: always rebase before creating a branch to avoid dragging old commits. And don't forget about prefixes: feature/, bugfix/, hotfix/, release/. This simplifies searching the history.
How often to sync with develop
Rebase once a day or before committing. This minimizes conflicts. The command:
git checkout feature/SPT-123-login-screengit rebase developIf conflicts are unavoidable (e.g., due to .xcodeproj), use git mergetool
Blogs
Book Recommendations
Read also
