Git Troubleshooting

Here are some common errors we see from folks trying to update the site and strategies for resolving them.

Diverged branch

Problem: you ran git status and you got output like this:

On branch new-branch
Your branch and 'origin/new-branch' have diverged,
and have 1 and 24 different commits each, respectively.
 (use "git pull" to merge the remote branch into yours)
Changes to be committed:
 (use "git reset HEAD <file>..." to unstage)

    modified:   _posts/2014-09-04-a-new-look-at-the-freedom-of-information-act.html
    modified:   _posts/2015-04-20-act-iac-event-on-devops-in-the-government.md
    new file:   _posts/2015-04-21-hackathons-not-just-for-folks-who-code.md
    new file:   _posts/2015-04-23-coming-soon-the-agile-delivery-services-soliciatation.md
    modified:   go

This is OK. Don't worry. This can happen sometimes when you have committed to a branch that has changed on GitHub. What that second line means is: your computer's copy of 18f.gsa.gov you have added one commit that you haven't pushed to GitHub, and somebody else added 24 commits that you haven't downloaded.

To fix it:

1. Run git pull origin new-branch to pull down the 24 commits on GitHub
2. Run git push to send your 1 commit back to GitHub

Related problems

• Merge conflicts

Failed to push some refs

Problem: you ran git push and got output like this:

To [email protected]:18F/18f.gsa.gov.git
! [rejected]        your-branch -> your-branch (non-fast-forward)
error: failed to push some refs to '[email protected]:18F/18f.gsa.gov.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

This is OK. Don't worry. It means someone else pushed a commit to the same branch you're pushing to but you don't have that commit on your laptop yet. This can happen if it's been a while since you ran git pull on a branch that many people contribute to (like staging).

To fix it:

1. Run git pull origin your-branch
2. Run git push origin your-branch

Failed to push

Problem: you ran git push and got this output:

warning: push.default is unset; its implicit value has changed in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the traditional behavior, use:

 git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

 git config --global push.default simple

When push.default is set to 'matching', git will push local branches
to the remote branches that already exist with the same name.

Since Git 2.0, Git defaults to the more conservative 'simple'
behavior, which only pushes the current branch to the corresponding
remote branch that 'git pull' uses to update the current branch.

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)

Wow! That's a lot of output! Let's break it down. Git can push your local copy to any website that will take it, not just GitHub. Each website you need to push to is called a "remote," and Git calls the one you cloned from "origin" by default. Each remote has it's own branches that get pushed from local copies. If it sounds complicated, it is. With this error, Git is intentionally being conservative in order to prevent you from making a mistake. git push can mean a lot of things depending on how it's configured, but by default it forces you to be explicit and spell out the remote and branch you want to push to.

To Fix It:

1. run git push origin branch (where branch is your current branch`)

Pro Tip

If you run git push --set-upstream origin branch you'll set a "remote tracking branch." This will force Git to remember the origin branch part and the next time you need to push you can simply type git push.

Merge conflicts

Problem: you ran git pull or git merge and got a message like this:

Removing assets/images/team/robert.jpg
Removing assets/images/team/michelle.jpg
Removing assets/images/team/greg.jpg
Auto-merging _data/team.json
CONFLICT (content): Merge conflict in _data/team.json
Auto-merging _data/projects.json
CONFLICT (content): Merge conflict in _data/projects.json
Auto-merging _data/pif_projects.json
CONFLICT (content): Merge conflict in _data/pif_projects.json
Auto-merging _config.yml
Auto-merging Gemfile.lock
CONFLICT (content): Merge conflict in Gemfile.lock
Auto-merging Gemfile
Automatic merge failed; fix conflicts and then commit the result.

Congratulations! You got a merge conflict! As with other errors: You're OK! Don't worry! Resolving merge conflicts is kind of a pain, but we all have to endure them eventually. They happen when the same part of the same file is edited by two different people. In this case it happened on the files _data/team.json, _data/projects.json, _data/pif_projects.json and Gemfile.lock, but in your situation it will be whatever files start are listed with CONFLICT at the beginning. If you're not sure, git status will list out the problem files and help figure out which need troubleshooting.

To Fix It:

1. Open each file in your text editor. Once you have it open you should see some strange markup in the file. Something like

   <<<<<<<< HEAD
   Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas eget magna non libero blandit ultrices in et tellus. Ut a
   tincidunt nisl. Mauris ornare viverra nisl ac sollicitudin. Duis quis odio nibh. Sed molestie purus eget velit sagittis, in lobortis
   ========
   Messenger bag Austin plaid beard ugh, small batch Kickstarter wayfarers kale 
   chips pop-up. Occupy crucifix lumbersexual Thundercats chambray kogi hashtag,
   >>>>>>>> c0022fdd9d5b3b4e0bc5fb41f7ee32a003636b67
   

   This is Git's way of showing you where the files are different. Git leaves it to you to figure out which is correct.

   The <<<<<<<< HEAD marks where your branch is right now, the >>>>>>>> c0022fdd9d5b3b4e0bc5fb41f7ee32a003636b67 marks the changes you're attempting to merge, and the =s are used to split them up. Unless you are absolutely sure you know all the differences and which are correct, review these carefully.

2. You can resolve these conflicts by deleting the goofy markup and leaving only the correct content. Only you and your collaborators know what "correct" means, this guide can't help you with that.

3. When you're finished, run git add the-file-you-just-fixed.md to add the fixed file to your commit

4. When you're finished with all the files run git commit to bring up the vim commit message screen. And type :wq

Pro Tip

• If you are absolutely sure you should accept all the changes from the merged branch, you can run git checkout --theirs <filename> (<filename> is the file you want to keep).
• If you are absolutely sure you should reject all the changes, you can run git checkout --ours <filename>
• More tips about resolving merge conflicts.