</pre>
===Step 4: Syncing Pushing Changes Between to Remote Repositories===
Let's make a change to our cloned Spoon-Knife repo, then sync that change with our remote Github forked repository. We start by making a change locally.
My full commit is visible at https://github.com/humphd/Spoon-Knife/commit/57f7209f758c4ba32be537434196b9168b2d53dc
** Remotes*** origin, origin/''branch''*** git remote*** git remote add*** git fetch*** git pull*** git push** Github, Pull Requests===Step 5: Pulling and Fetching Changes from Remote Repositories===
** Just as we can send changes (i.e., commits) to a remote repository that we own (or have been granted write permission), we can can '''pull''' changes from any public, cloned repo, whether we own it or not: we don't need explicit permission. Earlier we '''forked''' the [https://github.com/twbs/bootstrap Bootstrap] repo. Let's '''clone''' it locally now, and setup our '''origin''' and '''upstream''' remotes: <pre>$ git clone git@github.com:humphd/bootstrap.gitCloning into 'bootstrap'...remote: Counting objects: 103419, done.remote: Compressing objects: 100% (2/2), done.gitignore** Branchesremote: Total 103419 (delta 0), reused 0 (delta 0), pack-reused 103417Receiving objects: 100% (103419/103419), 92.52 MiB | 1.40 MiB/s, done.*** HEADResolving deltas: 100% (69071/69071), masterdone.$ cd bootstrap$ git remote add upstream https://github.com/twbs/bootstrap.git$ git remote -vorigin git@github.com:humphd/bootstrap.git (fetch)origin git@github.com:humphd/bootstrap.git (push)upstream https://github.com/twbs/bootstrap.git (fetch)*** upstream https://github.com/twbs/bootstrap.git checkout(push)</pre> If we wanted to update our local clone to be in sync with the '''upstream''' Bootstrap repo, we'd do this: <pre>$ git checkout pull upstream v4-bdevFrom https://github.com/twbs/bootstrap *** branch v4-dev -> FETCH_HEADAlready up-to-date.</pre> Here we've asked git to '''pull''' all commits on the <code>v4-dev</code> '''branch'''. We'll be discussing '''branches''' in detail in the next walk-through, git but for now a branch is a line of commits with a friendly name: it's easier to remember <code>v4-dev</code> than <code>b47c252ee13c536205105dcb16029021118f989c</code>! Git responds by telling us that we're '''Already up-to-date''', which means there's nothing new. If you wait for awhile and try that again, you'll see that new changes are available, and will get added to our local repo. We should say something about git's <code>pull</code> command vs. <code>fetch</code>. When git branch -ddownloads all new commits from a remote repo, we call that a <code>fetch</code>. You can do it yourself: <pre>$ git branch fetch upstream</pre> In this case nothing got downloaded. A <code>fetch</code> is '''always''' safe to do, because it just downloads any new commits, but doesn't update your current work yet--you do that using git's <code>merge</code>. We'll discuss <code>merge</code> at length in the next walk-mergedthrough, but for now it's useful to understand that a merge connects two (or more) existing commits. When you do a <code>git pull</code>, it combines a <code>git fetch</code> and <code>git branch merge</code> in a single operation. ===Step 6: Creating Pull Requests (PRs)=== So far we've learned how to '''pull''' and '''fetch''' changes from remote repositories, and also how to '''push''' changes to remote repositories we own. This leaves the question of how to share changes with repositories that you don't own. How does one contribute a bug fix to a project for which they don't have write permissions? Github's answer to this question is the [https://help.github.com/articles/about-pull-containsrequests/ Pull Request], also known as a '''PR'''. A pull request is a commit (or set of commits) you've made that you want to have pulled into an upstream repository. A pull request provides code changes (commits), but also a forum for discussion, code review, and evolution of the changes. We've been discussing Bootstrap, so let's look at [https://github.com/twbs/bootstrap/pull/17821 a real pull request] (you can see all [https://github.com/twbs/bootstrap/pulls current pull requests as well]). This pull request was opened in October 2015, and provides a fix for [https://github.com/twbs/bootstrap/issues/17811 this issue] (note the presence of <code>fixes #17811</code>). Within this PR we can see a few things:*'''[https://github.com/twbs/bootstrap/pull/17821 Conversation]''' - a running discussion between developers about this change, including code review, new commits, and a history of different status and label changes*'''[https://github.com/twbs/bootstrap/pull/17821/commits Commits]''' - a list of all the commits in this PR. NOTE: you can always add more commits to a PR by pushing new commits to your remote, which we'll discuss in the next walk-through* git merge'''[https://github.com/twbs/bootstrap/pull/17821/files Files changed]''' - a complete DIFF of all the file changes, as well as specific code review comments on particular lines Github PRs make it easy for anyone to contribute to any public repository, and for project owners to easily discuss and manage changes from the community. Let's send a PR to the Spoon-Knife repo with our change from above. The steps to follow are outlined nicely in [https://help.github.com/articles/creating-a-pull-request-from-a-fork/ this Github help page]. Follow the steps to create a PR for your change, and open a PR with the upstream repo. Here's my change as a PR: https://github.com/octocat/Spoon-Knife/pull/12168 *** git rebaseIn the next [[DPS909 & OSD600 Winter 2017 - Git Walkthrough 3 | walk-through]], we'll look at branching, merging, and common workflows for contributing to any open source project.
