Skip to content

Instantly share code, notes, and snippets.

@cseeman

cseeman/GitHub-Forking.md

Forked from Chaser324/GitHub-Forking.md
Last active October 15, 2021 17:28
Download ZIP

Revisions

  1. cseeman revised this gist Oct 15, 2021. 1 changed file with 33 additions and 47 deletions.
    80 changes: 33 additions & 47 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,102 +1,88 @@
    Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
    A forking rebase wokflow with GitHub is a common Git workflow, whether you're trying to work on open source or collaborating on work projects or your own.

    In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
    Knowing how to properly fork and generate pull requests is _essential_.

    It is easy to make mistakes when you're learning the process. In an attempt to gather this information for myself and others, this short tutorial for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

    ## Creating a Fork

    Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line:
    On the GitHub page and click the "Fork" button. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line (my method of choice):

    ```shell
    # Clone your fork to your local machine
    # Clone your fork to your local machine using ssh credentials
    git clone git@github.com:USERNAME/FORKED-PROJECT.git
    ```

    ## Keeping Your Fork Up to Date

    While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:
    If you plan on doing anything more than just a quick fix, you'll want to make sure you keep your fork up to date by tracking the original repo that you forked. To do this, you'll need to check on your remote repo:

    ```shell
    # Add 'upstream' repo to list of remotes
    git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git

    # Verify the new remote named 'upstream'
    # Verify the new remote named 'origin'
    git remote -v
    ```

    Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:
    Whenever you want to update your fork with the latest changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:

    ```shell
    # Fetch from upstream remote
    git fetch upstream

    # View all branches, including those from upstream
    git branch -va
    ```
    # If you are also using a rebase workflow (instead of merging) you can pull --rebase to get
    # the newest changes on a remote branch
    git pull --rebase origin

    Now, checkout your own master branch and merge the upstream repo's master branch:

    ```shell
    # Checkout your master branch and merge upstream
    git checkout master
    git merge upstream/master
    # View all branches
    git branch -va
    ```

    If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - [see the next section](#doing-your-work), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
    If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - [see the next section](#doing-your-work), you may have to deal with conflicts. When doing so, be careful to respect the changes made remote.

    Now, your local master branch is up-to-date with everything modified upstream.
    Now, your local main branch is up-to-date with everything modified remote.

    ## Doing Your Work

    ### Create a Branch
    Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.
    Whenever you begin work on a new ticket, bugfix, or any old poking around, it's important to create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the main branch so that you can easily submit and manage multiple pull requests for every task you complete.

    To create a new branch and start working on it:

    ```shell
    # Checkout the master branch - you want your new branch to come from master
    git checkout master
    # Checkout the main branch - typically this is the main development branch with the most updated code
    git checkout main

    # Create a new branch named newfeature (give your branch its own simple informative name)
    git branch newfeature

    # Switch to your new branch
    git checkout newfeature
    # Switch and create to your new `newfeature` branch
    git checkout -b newfeature
    ```

    Now, go to town hacking away and making whatever changes you want to.
    Now, you are ready for whatever changes you want to create.

    ## Submitting a Pull Request

    ### Cleaning Up Your Work

    Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.
    Prior to submitting your pull request (PR), you can clean up your branch and make it as [atomic](https://tekin.co.uk/2021/01/how-atomic-commits-make-you-a-better-coder) as possible for the original repo's maintainer to test, accept, and accept your work.

    If any commits have been made to the upstream master branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
    If any commits have been made to the remote main branch, you should rebase your development branch so that it is up to date with the remote repo.

    ```shell
    # Fetch upstream master and merge with your repo's master branch
    git fetch upstream
    git checkout master
    git merge upstream/master

    # If there were any new commits, rebase your development branch
    git checkout newfeature
    git rebase master
    git pull --rebase main
    ```

    Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
    Now, it might be desirable to squash some of your smaller commits down into a small number of larger more atomic, manageable commits. You can do this with an interactive rebase:

    ```shell
    # Rebase all commits on your development branch
    git checkout
    git rebase -i master
    # Rebase all commits on your development branch, this ex is for 3 commits that you have locally
    # Change up that HEAD~3 to whatever your commit number is.
    git rebase -i HEAD~3
    ```

    This will open up a text editor where you can specify which commits to squash.
    This will open up a text editor where you can specify which commits to change.

    ### Submitting

    Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.
    Once you've committed and pushed all of your changes to GitHub, your fork or the remote repo and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.

    ## Accepting and Merging a Pull Request

    @@ -150,8 +136,8 @@ git branch -d newfeature


    **Copyright**

    Copyright 2017, Chase Pettit
    Copyright 2021, Chrisitne Seeman
    adapted from Copyright 2017, Chase Pettit

    MIT License, http://www.opensource.org/licenses/mit-license.php

  2. @Chaser324 Chaser324 revised this gist Jul 20, 2017. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -152,6 +152,7 @@ git branch -d newfeature
    **Copyright**

    Copyright 2017, Chase Pettit

    MIT License, http://www.opensource.org/licenses/mit-license.php

    **Additional Reading**
  3. @Chaser324 Chaser324 revised this gist Jul 20, 2017. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -147,6 +147,8 @@ Now that you're done with the development branch, you're free to delete it.
    git branch -d newfeature
    ```



    **Copyright**

    Copyright 2017, Chase Pettit
  4. @Chaser324 Chaser324 revised this gist Jul 20, 2017. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -148,6 +148,7 @@ git branch -d newfeature
    ```

    **Copyright**

    Copyright 2017, Chase Pettit
    MIT License, http://www.opensource.org/licenses/mit-license.php

  5. @Chaser324 Chaser324 revised this gist Jul 20, 2017. 1 changed file with 8 additions and 1 deletion.
    9 changes: 8 additions & 1 deletion GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -103,7 +103,7 @@ Once you've committed and pushed all of your changes to GitHub, go to the page f
    Take note that unlike the previous sections which were written from the perspective of someone that created a fork and generated a pull request, this section is written from the perspective of the original repository owner who is handling an incoming pull request. Thus, where the "forker" was referring to the original repository as `upstream`, we're now looking at it as the owner of that original repository and the standard `origin` remote.

    ### Checking Out and Testing Pull Requests
    Open up the `.git/config` file and add a new line under `[remote "orgin"]`:
    Open up the `.git/config` file and add a new line under `[remote "origin"]`:

    ```
    fetch = +refs/pull/*/head:refs/pull/origin/*
    @@ -147,6 +147,13 @@ Now that you're done with the development branch, you're free to delete it.
    git branch -d newfeature
    ```

    **Copyright**
    Copyright 2017, Chase Pettit
    MIT License, http://www.opensource.org/licenses/mit-license.php

    **Additional Reading**
    * [Atlassian - Merging vs. Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)

    **Sources**
    * [GitHub - Fork a Repo](https://help.github.com/articles/fork-a-repo)
    * [GitHub - Syncing a Fork](https://help.github.com/articles/syncing-a-fork)
  6. @Chaser324 Chaser324 revised this gist Dec 15, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -96,7 +96,7 @@ This will open up a text editor where you can specify which commits to squash.

    ### Submitting

    Once you've committed all of you're changes and pushed them to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.
    Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.

    ## Accepting and Merging a Pull Request

  7. @Chaser324 Chaser324 revised this gist Dec 15, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, when I started going through the process of forking and issuing pull requests, I had some trouble figuring out the proper method for doing so and made quite a few mistakes along the way. I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
    Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

    In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

  8. @Chaser324 Chaser324 revised this gist Dec 15, 2016. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -41,7 +41,7 @@ git checkout master
    git merge upstream/master
    ```

    If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - [see the next section](#Doing Your Work), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
    If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - [see the next section](#doing-your-work), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.

    Now, your local master branch is up-to-date with everything modified upstream.

  9. @Chaser324 Chaser324 revised this gist Dec 15, 2016. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -41,7 +41,7 @@ git checkout master
    git merge upstream/master
    ```

    If there are no unique commits locally, git will simply perform a fast-forward. However, if you have been making changes (in the vast majority of cases you probably shouldn't be), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
    If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - [see the next section](#Doing Your Work), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.

    Now, your local master branch is up-to-date with everything modified upstream.

    @@ -100,6 +100,8 @@ Once you've committed all of you're changes and pushed them to GitHub, go to the

    ## Accepting and Merging a Pull Request

    Take note that unlike the previous sections which were written from the perspective of someone that created a fork and generated a pull request, this section is written from the perspective of the original repository owner who is handling an incoming pull request. Thus, where the "forker" was referring to the original repository as `upstream`, we're now looking at it as the owner of that original repository and the standard `origin` remote.

    ### Checking Out and Testing Pull Requests
    Open up the `.git/config` file and add a new line under `[remote "orgin"]`:

  10. @Chaser324 Chaser324 revised this gist Jul 9, 2014. 1 changed file with 6 additions and 0 deletions.
    6 changes: 6 additions & 0 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -139,6 +139,12 @@ git merge newfeature
    git push origin master
    ```

    Now that you're done with the development branch, you're free to delete it.

    ```shell
    git branch -d newfeature
    ```

    **Sources**
    * [GitHub - Fork a Repo](https://help.github.com/articles/fork-a-repo)
    * [GitHub - Syncing a Fork](https://help.github.com/articles/syncing-a-fork)
  11. @Chaser324 Chaser324 revised this gist May 5, 2014. 1 changed file with 72 additions and 1 deletion.
    73 changes: 72 additions & 1 deletion GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -67,8 +67,79 @@ Now, go to town hacking away and making whatever changes you want to.

    ## Submitting a Pull Request

    ### Cleaning Up Your Work

    Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.

    If any commits have been made to the upstream master branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.

    ```shell
    # Fetch upstream master and merge with your repo's master branch
    git fetch upstream
    git checkout master
    git merge upstream/master

    # If there were any new commits, rebase your development branch
    git checkout newfeature
    git rebase master
    ```

    Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:

    ```shell
    # Rebase all commits on your development branch
    git checkout
    git rebase -i master
    ```

    This will open up a text editor where you can specify which commits to squash.

    ### Submitting

    Once you've committed all of you're changes and pushed them to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.

    ## Accepting and Merging a Pull Request

    ### Checking Out and Testing Pull Requests
    Open up the `.git/config` file and add a new line under `[remote "orgin"]`:

    ```
    fetch = +refs/pull/*/head:refs/pull/origin/*
    ```

    Now you can fetch and checkout any pull request so that you can test them:

    ```shell
    # Fetch all pull request branches
    git fetch origin

    # Checkout out a given pull request branch based on its number
    git checkout -b 999 pull/origin/999
    ```

    Keep in mind that these branches will be read only and you won't be able to push any changes.

    ### Automatically Merging a Pull Request
    In cases where the merge would be a simple fast-forward, you can automatically do the merge by just clicking the button on the pull request page on GitHub.

    ### Manually Merging a Pull Request
    To do the merge manually, you'll need to checkout the target branch in the source repo, pull directly from the fork, and then merge and push.

    ```shell
    # Checkout the branch you're merging to in the target repo
    git checkout master

    # Pull the development branch from the fork repo where the pull request development was done.
    git pull https://github.com/forkuser/forkedrepo.git newfeature

    # Merge the development branch
    git merge newfeature

    # Push master with the new feature merged into it
    git push origin master
    ```

    **Sources**
    * [GitHub - Fork a Repo](https://help.github.com/articles/fork-a-repo)
    * [GitHub - Syncing a Fork](https://help.github.com/articles/syncing-a-fork)
    * [GitHub - Syncing a Fork](https://help.github.com/articles/syncing-a-fork)
    * [GitHub - Checking Out a Pull Request](https://help.github.com/articles/checking-out-pull-requests-locally)
  12. @Chaser324 Chaser324 revised this gist May 3, 2014. 1 changed file with 22 additions and 4 deletions.
    26 changes: 22 additions & 4 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,10 +1,10 @@
    Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, when I started going through the process of forking and issuing pull requests, I had a decent amount of trouble. I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
    Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, when I started going through the process of forking and issuing pull requests, I had some trouble figuring out the proper method for doing so and made quite a few mistakes along the way. I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

    In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing pull requests, and merging that pull request back into the original project.
    In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

    ## Creating a Fork

    Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite Git client to clone your repo or just head straight to the command line:
    Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line:

    ```shell
    # Clone your fork to your local machine
    @@ -41,12 +41,30 @@ git checkout master
    git merge upstream/master
    ```

    If there are no unique commits locally, git will simply perform a fast-forward. However, if you've been making changes, you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
    If there are no unique commits locally, git will simply perform a fast-forward. However, if you have been making changes (in the vast majority of cases you probably shouldn't be), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.

    Now, your local master branch is up-to-date with everything modified upstream.

    ## Doing Your Work

    ### Create a Branch
    Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.

    To create a new branch and start working on it:

    ```shell
    # Checkout the master branch - you want your new branch to come from master
    git checkout master

    # Create a new branch named newfeature (give your branch its own simple informative name)
    git branch newfeature

    # Switch to your new branch
    git checkout newfeature
    ```

    Now, go to town hacking away and making whatever changes you want to.

    ## Submitting a Pull Request

    ## Accepting and Merging a Pull Request
  13. @Chaser324 Chaser324 revised this gist May 1, 2014. 1 changed file with 33 additions and 6 deletions.
    39 changes: 33 additions & 6 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -8,22 +8,49 @@ Just head over to the GitHub page and click the "Fork" button. It's just that si

    ```shell
    # Clone your fork to your local machine
    $ git clone git@github.com:USERNAME/FORKED-PROJECT.git
    git clone git@github.com:USERNAME/FORKED-PROJECT.git
    ```

    ## Keeping Your Fork Up to Date

    While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:

    ```shell
    # Add upstream repo to list of remotes
    $ git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git
    # Add 'upstream' repo to list of remotes
    git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git

    # Verify the new remote
    $ git remote -v
    # Verify the new remote named 'upstream'
    git remote -v
    ```

    Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:

    ```shell
    # Fetch from upstream remote
    git fetch upstream

    # View all branches, including those from upstream
    git branch -va
    ```

    Now, checkout your own master branch and merge the upstream repo's master branch:

    ```shell
    # Checkout your master branch and merge upstream
    git checkout master
    git merge upstream/master
    ```

    If there are no unique commits locally, git will simply perform a fast-forward. However, if you've been making changes, you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.

    Now, your local master branch is up-to-date with everything modified upstream.

    ## Doing Your Work

    ## Submitting a Pull Request

    ## Accepting and Merging a Pull Request

    **Sources**
    * [GitHub - Syncing a fork](https://help.github.com/articles/syncing-a-fork)
    * [GitHub - Fork a Repo](https://help.github.com/articles/fork-a-repo)
    * [GitHub - Syncing a Fork](https://help.github.com/articles/syncing-a-fork)
  14. @Chaser324 Chaser324 revised this gist May 1, 2014. 1 changed file with 16 additions and 2 deletions.
    18 changes: 16 additions & 2 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -6,10 +6,24 @@ In an attempt to coallate this information for myself and others, this short tut

    Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite Git client to clone your repo or just head straight to the command line:

    ```Shell
    ```shell
    # Clone your fork to your local machine
    $ git clone git@github.com:USERNAME/FORKED-PROJECT.git
    ```

    ## Keeping Your Fork Up to Date

    While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked.
    While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked. To do this, you'll need to add a remote:

    ```shell
    # Add upstream repo to list of remotes
    $ git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git

    # Verify the new remote
    $ git remote -v
    ```



    **Sources**
    * [GitHub - Syncing a fork](https://help.github.com/articles/syncing-a-fork)
  15. @Chaser324 Chaser324 created this gist May 1, 2014.
    15 changes: 15 additions & 0 deletions GitHub-Forking.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,15 @@
    Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, when I started going through the process of forking and issuing pull requests, I had a decent amount of trouble. I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

    In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing pull requests, and merging that pull request back into the original project.

    ## Creating a Fork

    Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite Git client to clone your repo or just head straight to the command line:

    ```Shell
    $ git clone git@github.com:USERNAME/FORKED-PROJECT.git
    ```

    ## Keeping Your Fork Up to Date

    While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repo that you forked.