Everything you have done so far — initializing a repository, staging files, making commits — has happened entirely on your own machine. To collaborate with a team (or even just back up your work), you need to sync your local commits with a remote server like GitHub, GitLab, or Bitbucket.
Syncing revolves around two core operations: git pull downloads commits made by others into your local branch, and git push uploads your local commits to the remote. Together they form the communication channel between your machine and the rest of the world.
Think of it like email. git pull is checking your inbox — you receive what others have sent. git push is hitting send — you share your work with the team.
Understanding remotes
A remote is simply a bookmark to another copy of your repository, usually hosted on a server. When you clone a repository, Git automatically creates a remote called origin pointing to the URL you cloned from.
Terminal
If you started your project locally with git init and want to connect it to a remote server, you need to add the remote manually:
Terminal
$ git remote add origin https://github.com/...
Hover over each part to see what it does
Remote-tracking branches
When you fetch or pull from a remote, Git stores a local copy of each remote branch. These are called remote-tracking branches and follow the naming convention origin/main, origin/feature/login, etc. You cannot commit directly to them — they are read-only snapshots of where the remote branches were the last time you synced.
If you see origin/main in git log or in a tool like Komitly, it means "where the main branch was on the remote the last time I fetched or pulled."
git fetch: Downloading without merging
git fetch is the safe version of syncing. It downloads all new commits, branches, and tags from the remote, but it does not modify your working files or your current branch. Your code stays exactly as it was.
Terminal
$ git fetch origin
Hover over each part to see what it does
After fetching, git status tells you how your branch compares to the remote. In the example above, your local main is 3 commits behind origin/main. You can inspect these commits with git log origin/main before deciding to merge them.
This is what the commit graph looks like after fetching — your local branch has not moved, but the remote-tracking branch origin/main is ahead:
Komitly - Commit Graph (after fetch)
a9b0c1dUpdate API endpointsorigin/main
98a0b1cAdd rate limiting middleware
87f9a0bRefactor error handling
d6a7b8cFix responsive layoutmain
c5d6e7fAdd user authentication
When to use fetch
You want to see what the team has been working on without touching your code.
You are in the middle of something and do not want to deal with potential merge conflicts yet.
You want to inspect the incoming commits before integrating them.
git pull: Fetch and merge in one step
git pull is the command you will use most often. It combines git fetch and git merge into a single step — it downloads the latest commits from the remote and immediately integrates them into your current branch.
Terminal
$ git pull origin main
Hover over each part to see what it does
Here is a side-by-side comparison of fetch vs pull, so you can see exactly where they differ:
git fetch vs git pull
git fetch git pull
│ │
▼ ▼
Download new Download new
commits from commits from
remote remote
│ │
▼ ▼
Update remote Update remote
tracking branches tracking branches
(origin/main) (origin/main)
│ │
▼ ▼
STOP ✓ Merge into your
current branch
│
▼
DONE ✓
After a successful pull, your local main branch and the remote-tracking origin/main point to the same commit:
Komitly - Commit Graph (after pull)
a9b0c1dUpdate API endpointsmainorigin/main
98a0b1cAdd rate limiting middleware
87f9a0bRefactor error handling
d6a7b8cFix responsive layout
c5d6e7fAdd user authentication
Pull with rebase
By default, git pull creates a merge commit when your local branch has diverged from the remote. If you prefer a clean, linear history, use the --rebase flag. Instead of merging, it replays your local commits on top of the remote changes:
Terminal
$ git pull --rebase origin main
From https://github.com/yourname/my-project
* branch main -> FETCH_HEAD
Successfully rebased and updated refs/heads/main.
$ git pull --rebase origin main
Hover over each part to see what it does
Many teams configure git pull --rebase as the default. You can set this globally with git config --global pull.rebase true. It keeps the history clean and avoids the "Merge branch main of ..." noise commits.
git push: Uploading your commits
Once you have committed your work locally, it is invisible to the rest of the team until you push. The git push command uploads your local commits to the remote repository.
Before pushing, this is what your graph looks like — your local main is 2 commits ahead of origin/main:
Komitly - Commit Graph (before push)
f8a9b0cAdd search componentmain
e7b8c9dUpdate navigation styles
d6a7b8cFix responsive layoutorigin/main
c5d6e7fAdd user authentication
b4c5d6eInitial commit
Terminal
$ git push origin main
Hover over each part to see what it does
Pushing a new branch
When you create a branch locally, it only exists on your machine. To share it with the team (or to open a pull request), you need to push it to the remote. The -u flag sets up upstream tracking so future pushes and pulls just work:
Terminal
$ git push -u origin feature/add-search
Hover over each part to see what it does
After running this once, you can simply use git push and git pull without specifying the remote and branch name every time.
Syncing in Komitly
Komitly turns the fetch-pull-push workflow into a visual, one-click experience. No commands to remember, no flags to look up — just buttons.
Toolbar buttons
The commit graph toolbar has dedicated Fetch, Pull, and Push buttons. Click Fetch to update your remote-tracking branches, Pull to integrate remote changes, or Push to upload your local commits. If your branch is behind, Komitly shows the count directly in the graph so you always know where you stand.
Ahead / behind indicators
Komitly shows you at a glance how many commits you are ahead (local commits not yet pushed) and behind (remote commits not yet pulled). This is the visual equivalent of running git status and checking the "Your branch is ahead/behind" message — except it is always visible.
The Dashboard
If you manage multiple repositories, the Dashboard gives you a bird's-eye view of every project at once. Each repository card is color-coded by status:
Green — Clean, everything is in sync.
Orange — Uncommitted local changes.
Yellow — Unpushed commits waiting to be shared.
Blue — Behind the remote, needs a pull.
Purple — Diverged (ahead and behind at the same time).
Red — Merge conflicts that need resolution.
You can select multiple repos and Fetch All, Pull All, or Push All in a single bulk operation — with a progress indicator for each repo.
Keyboard shortcuts
For even faster syncing, Komitly has keyboard shortcuts: Ctrl+Shift+F to fetch all remotes, Ctrl+Shift+P to pull, and Ctrl+Shift+U to push. You can customize these in the settings.
Komitly also manages remotes visually. Press Ctrl+R to open the Manage Remotes dialog where you can add, edit, or remove remotes without typing any commands.
Common problems and fixes
Push rejected: "fetch first"
This is the most common issue for beginners. It happens when someone else has pushed commits to the remote since your last pull. Git refuses to push because it would overwrite their work:
Terminal
$ git push origin main
To https://github.com/yourname/my-project.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/yourname/my-project.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. Integrate the remote changes (e.g., 'git pull') before pushing.
# Fix: pull first, then push
$ git pull --rebase
Successfully rebased and updated refs/heads/main.
$ git push origin main
To https://github.com/yourname/my-project.git
d4e5f6a..f8a9b0c main -> main
The fix is simple: pull first (with or without --rebase), then push again. In Komitly, the app detects this automatically and suggests pulling before pushing.
Merge conflicts during pull
If you and a teammate modified the same lines in the same file, Git cannot merge automatically. You will see conflict markers in the affected files:
Terminal
$ git pull
Auto-merging src/utils/helpers.ts
CONFLICT (content): Merge conflict in src/utils/helpers.ts
Automatic merge failed; fix conflicts and then commit the result.
# 1. Open the file and resolve the conflict markers
# 2. Stage the resolved file
$ git add src/utils/helpers.ts
# 3. Complete the merge
$ git commit -m "Resolve merge conflict in helpers"
[main 1a2b3c4] Resolve merge conflict in helpers
In Komitly, conflicts are resolved visually using the 3-way merge editor. You see your version on one side, their version on the other, and the merged result at the bottom. Click "Accept Yours," "Accept Theirs," or "Accept Both" — or edit the result manually, line by line.
The daily workflow
Following this four-step pattern will keep you in sync with the team and avoid most problems:
Terminal
$ git pull
Already up to date.
Terminal
$ git add src/components/Search.tsx
$ git commit -m "Add search component"
[main f8a9b0c] Add search component
1 file changed, 42 insertions(+)
Terminal
$ git pull
Already up to date.
Terminal
$ git push
To https://github.com/yourname/my-project.git
d6a7b8c..f8a9b0c main -> main
Summary
git pull and git push are the bridge between your local work and the rest of the team. Here is a quick recap:
A remote (usually called origin) is a bookmark to a server copy of your repository.
git fetch downloads new commits without modifying your branch. Safe to run at any time.
git pull fetches and merges in one step. Use --rebase for a linear history.
git push uploads your local commits to the remote. Use -u the first time to set upstream tracking.
If a push is rejected, pull first, resolve any conflicts, then push again.
In Komitly, syncing is one click away — with Fetch, Pull, and Push buttons in the toolbar, ahead/behind indicators, a color-coded Dashboard for multi-repo management, and a visual 3-way merge editor for conflicts.
With pull and push in your toolkit, you are fully equipped to collaborate. Next, learn how to handle the trickiest part of collaboration — resolving merge conflicts.