{"id":11973,"date":"2016-05-16T06:00:00","date_gmt":"2016-05-16T13:00:00","guid":{"rendered":"https:\/\/www.sapien.com\/blog\/?p=11973"},"modified":"2016-05-16T12:25:30","modified_gmt":"2016-05-16T19:25:30","slug":"github-how-to-update-your-fork","status":"publish","type":"post","link":"https:\/\/dev.sapien.com\/blog\/2016\/05\/16\/github-how-to-update-your-fork\/","title":{"rendered":"GitHub: How to update your fork"},"content":{"rendered":"

Like almost everyone in the DevOps world, I use GitHub, not because I like it, but because everyone uses it. In fact, I dislike it, because it\u2019s confusing by design. Its misleading language excludes users, rather than welcoming them. To use it, you have to forget the actual meaning of words in English, or even their technical meaning, and use them as though they are arbitrary strings.<\/p>\n

Worst of all, because most people memorize a command sequence without fully understanding how it works, when something goes wrong, it\u2019s almost impossible to troubleshoot.<\/p>\n

Okay, enough ranting.<\/p>\n

I just discovered a solution to one of the problems I encounter frequently, so I want to share it with you. My utmost thanks to PowerShell MVP and Principal Engineer – Community Engineering for Chef, Steven Murawski<\/a> for showing me the solution and letting me try it by myself (twice) while he was standing nearby in case of disaster. If this solution works for you, tweet your thanks to Steven.<\/p>\n

Your Fork is Outdated<\/h1>\n

Here\u2019s the problem. You create a fork (an online copy) of a repository and a clone (a local copy on disk) of your fork. You spend some time examining the files and interpreting the code. Then, when you\u2019re ready to work, you notice the message on your fork.<\/p>\n

“This branch is n<\/i> commits behind (source-repo).”<\/p>\n

\"clip_image001\"<\/a><\/p>\n

That makes sense. While you were working, other people were working, too. So, you want to synchronize your branch of your fork (the online copy) and its clone (the disk copy) with the files in the source repository.<\/p>\n

This happens so often and it’s so predictable that you’d think there would be a Sync button or something like it, but there’s not.<\/p>\n

Also, if you try something rational, like opening your Git Shell (I use Git for Windows with posh-git) and trying to fetch\/merge or pull (or push or anything else you can think of), that won’t work, because, by default, those commands synchronize your clone (on disk) with your fork (online) and they’re already in sync. You need to synchronize your fork\/clone with their source.<\/p>\n

Remote: A link to the Source<\/h1>\n

One solution, the one I had been using, is to copy any files you’ve changed to a different directory, delete your fork, delete your clone, then re-fork and re-clone, and move the changed files back in. Yes, I’ve done this. Whatever it takes.<\/p>\n

The correct Steven-Murawski-approved solution is to create a remote<\/i><\/b>, that is, a named link to the source repository, in your clone (on disk). This lets you get and send things from your clone to the source repo.<\/p>\n

A remote is just another name, alias, or nickname for the URL to an online repository. In any command that you use the name of the remote, you can use the URL, and vice versa. <\/p>\n

Actually, you already have one remote; a remote to the fork, although you might not have noticed. When you clone (make a disk copy) an online repo, the clone command automatically creates a remote to the repository that you cloned, typically your fork. That remote is named origin<\/b>.<\/p>\n

To see your remotes, use git remote<\/b>.<\/p>\n

C:\\Github\\dbatools [master]> git remote\r\norigin\r\n<\/pre>\n
To see the URL of the remote, add -v (for verbose). These are remotes to my fork, so they have my username, juneb, in the URL.<\/p>\n
C:\\Github\\dbatools [master]> git remote -v\r\norigin https:\/\/github.com\/juneb\/dbatools.git (fetch)\r\norigin https:\/\/github.com\/juneb\/dbatools.git (push)\r\n<\/pre>\n
By default, when you use git fetch<\/b>, git merge<\/b>, git pull<\/b>, or git push<\/b>, git uses the origin<\/b> remote. As a result, it gets stuff from or sends stuff to the fork that you cloned.<\/p>\n
So, to get or send to the source repo, you need another remote.<\/p>\n
Update your clone and fork<\/h1>\n
To get all changed files from a source repository and copy them to the clone, and then to the fork.<\/p>\n
    \n
  1. On GitHub.com, on the page for the source repository (not your fork), copy the URL of the source repo. It’s the same URL that you would use to clone the source repo.\n
    \"clip_image003\"<\/a>
    \n \n<\/li>\n
  2. In your shell, navigate to the directory with the clone, and use the following command to create a remote to the source repo.\n<\/p>\n
    git remote add <name> <copiedURL><\/pre>\n
    For example:<\/p>\n
    git remote add upstream https:\/\/github.com\/ctrlbold\/dbatools.git<\/pre>\n
    The name is arbitrary. You can use any valid string for the name of your remote. The traditional name of a remote to the source repository is ‘upstream’<\/b> which makes about as much sense as the rest of the words in GitHub. In this use, it is a proper noun, not a direction. Regardless, I use it, because people recognize it.\n<\/li>\n
  3. Get (fetch) and merge changes from the source repo to your clone. All names, including the remote name and branch name, are case-sensitive.\n<\/p>\n
    git fetch <nameOfRemote>\r\ngit merge <nameOfRemote>\\<branch><\/pre>\n
    For example,<\/p>\n
    git fetch upstream\r\ngit merge upstream\\master<\/pre>\n<\/li>\n
  4. Send the changes from your clone (on disk) to your fork (online). You don’t need to qualify this command with a remote, because the “origin” remote is the default.\n<\/p>\n
    git push<\/pre>\n<\/li>\n<\/ol>\n
    Now, your clone and fork have the same content:<\/p>\n
    C:\\Github\\dbatools [master]> git status\r\nOn branch master\r\nYour branch is up-to-date with 'origin\/master'.\r\n\r\nnothing to commit, working directory clean\r\n<\/pre>\n
    And, miraculously, your branch is “even with master”.<\/p>\n
    \"clip_image004\"<\/a><\/p>\n
    Thanks, Steven! It works!<\/p>\n
    To sync again<\/h3>\n
    If you continue to work on this project and your fork becomes outdated again, you already have a remote to the source repo. So, just repeat the fetch, merge, and push. There’s no need to recreate or update the link to the remote repo.<\/p>\n
    git fetch upstream\r\ngit merge upstream\\master\r\ngit push<\/pre>\n
    Not too tough. Having this solution makes my GitHub live a lot easier. I still don’t like it, but I use it.<\/p>\n
    June Blender is a technology evangelist at SAPIEN Technologies, Inc. and a Windows PowerShell MVP. You can reach her at <\/em>juneb@sapien.com,<\/a><\/em> follow her on Twitter at <\/em>@juneb_get_help<\/em><\/a>, and find her GitHub repos at https:\/\/github.com\/juneb<\/a>.<\/i><\/p>\n","protected":false},"excerpt":{"rendered":"
    Like almost everyone in the DevOps world, I use GitHub, not because I like it, but because everyone uses it. In fact, I dislike it, because it\u2019s confusing by design. Its misleading language excludes users, rather than welcoming them. To use it, you have to forget the actual meaning of words in English, or even […]<\/p>\n","protected":false},"author":31,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[932,1107,1108,283],"tags":[786,896,934],"class_list":["post-11973","post","type-post","status-publish","format-standard","hentry","category-beginners","category-git","category-github","category-howto","tag-git","tag-github","tag-juneb"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/comments?post=11973"}],"version-history":[{"count":24,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11973\/revisions"}],"predecessor-version":[{"id":12055,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/11973\/revisions\/12055"}],"wp:attachment":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/media?parent=11973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/categories?post=11973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/tags?post=11973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}