Getting Changes


Once you've created and cloned a repo you might want to get new changes to the repository. This could happen if you're making changes to the repository from multiple machines, either as an individual or if multiple people from the same team are using the same repository to collaborate.

Pull before you push

If you're working as an individual, it's rare that you'll have to pull changes. If this is the case, you might want to skip ahead to the next section saving changes, and then come back to this section when you have collaborators.
However, these docs feature "getting changes" before "making changes" because you can't push changes to a repository if your local repository isn't up to date. As a mental model, you can think about this as Git wants you to know what you're updating before you're allowed to update it.

Pulling in Desktop App (no local changes)

Pulling changes in the Desktop App if you have no local changes is straightforward.
Press Fetch Origin to check the remote repository for changes. "Fetching" simply checks the repository, it doesn't pull in the remote changes.
Press Pull Origin to pull the changes from the remote repository. "Pulling" actually pulls the remote changes into your local repository (or file system)
You might notice some additional language here. Don't worry about that for now. This is more relevant if you are using the advanced feature, branching.

Pulling in Desktop App (with local changes)

In the case where you have made some change locally and someone has already made a change, the Desktop app is pretty smart and will do a lot of work for you.
Follow the normal steps to commit a change from saving changes. When the desktop app prompts you to pull in remote changes, click Pull Changes.
Then press Push Origin to push the changes to remote.
You'll notice an extra commit that records the fact that you "merged" the remote changes into local. Git is append-only, so no change happens without some record. This is a good feature, as it makes it much harder to break things.

Merge Conflicts

Sometimes when you attempt to pull, you'll discover that you've modified a file that someone else has already modified. You'll get the following warning.
You'll want to select your local version of the (the option NOT prefixed with origin/) and merge the files in. This will create a new commit. You can then go to the history tab to understand what you changed. We recommend you create another commit with the changes from remote you overrode before pushing.
However, we recognize this is kind of messy, and part of the reason we recommend that you begin to use branching and merging and the pull request flow, which makes it much cleaner to compare changes and resolve merge conflicts.