Skip to content

Instantly share code, notes, and snippets.

@dbc-challenges

dbc-challenges/gist:a574b84f95f4cf8f76e9 Secret

Last active December 20, 2015 21:58
Download ZIP

Revisions

  1. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 10 additions and 10 deletions.
    20 changes: 10 additions & 10 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -10,7 +10,7 @@ Git is a distributed version control system. Every Git working directory is a fu

    ### Creating a .gitignore

    By default git will try to track every file that exists in the working copy. Sometimes you'll have files that you don't want git to track, e.g. log files, OS files, etc. By creating a .gitignore file you can tell git that it should happily ignore these types of files. For more info: https://help.github.com/articles/ignoring-files)
    By default git will try to track every file that exists in the working copy. Sometimes you'll have files that you don't want git to track, e.g. log files, OS files, etc. By creating a .gitignore file you can tell git that it should happily ignore these types of files. For more info: https://help.github.com/articles/ignoring-files

    ### Creating a README

    @@ -54,23 +54,23 @@ This will change your working copy to reflect the contents of the `my-other-feat

    We said earlier that git is a *distributed* version control system. At the heart of this is the concept of remote repositories. A remote repository is a git repository that exists on another machine. When we're working on teams we are able to share code among our various development repositories by syncing with a shared remote repository. Github is a popular service that offers hosting for git repositories, and also adds a number of really nice features for working on software as a group. Here's how to get started with using Github as a remote for your existing local repository:

    ### Github repository set up:
    ### Github repository set up

    Create a new repository on Github. Github will create a url for you to use on other computers that want access the the repository on Github. Then do the following in your local repository:
    Create a new repository on Github (https://help.github.com/articles/create-a-repo). Github will give you a url, so that you can access the the repository on Github from other repositories. Then do the following in your local repository:

    git remote add origin https://url-from-github
    git push -u origin master

    1. `$ git remote add origin https://url-from-github` this tells your local git repository that there is a remote repository which we'll call "origin" which lives at "https://url-from-github".
    2. `$ git push -u origin master` this command will push a copy of our "master" branch to the remote named "origin" (ie. Github in our case), and the `-u` tells git that our master branch should be setup to track the master branch on origin. You can omit the `-u` on future pushes because our master branch will still be tracking origin/master.
    1. `$ git remote add origin https://url-from-github` this tells your local git repository that there is a remote repository that we'll call `origin` and lives at `https://url-from-github`.
    2. `$ git push -u origin master` this command will push a copy of our `master` branch to the remote named `origin` (ie. Github in our case), and the `-u` tells git that our master branch should be setup to track the master branch on origin. You can omit the `-u` on future pushes because our master branch will still be tracking origin/master.

    ### Setting up a local repository from an existing Github repository:
    ### Set up a local repository from an existing Github repository

    git clone https://url-from-github project-name

    This will download a copy of the repository that lives at "<https://url-from-github-goes-here>" and put it into a directory called "<project-name>" in your current directory. You can omit the "project-name" parameter if you don't want to rename the project locally.
    This will download a copy of the repository that lives at `https://url-from-github` and put it into a directory called `project-name` in your current directory. You can omit the `project-name` parameter if you want to use the same name as the remote repository in your local repository.

    ### Pushing a branch to a remote:
    ### Push a branch to a remote

    git push origin -u <local-branch-name>:<remote-branch-name>

    @@ -80,11 +80,11 @@ This is the full push command. It pushes the local-branch-name to origin, renami

    Without specifying a remote branch name, git assumes that it should name the remote branch the same name as your local branch. If you've previously set up tracking on this branch, git will push to the remote branch that local branch is tracking.

    ## Managing changes from other developers
    ## Collaboration

    In the course of collaborating with other developers, you'll likely want to get the changes that they've made into your own local repository. This is where most of the headaches of working with git (and other developers) come from.

    So, let's say that a teammate has pushed some changes that he made into the master branch of our remote repository. We'd like to get those changes into our repository and then use them in the branch we're working in (let's call it "my-feature").
    So, let's say that a teammate has pushed some changes that she made into the `master` branch of our remote repository. We'd like to get the changes into our local repository and then use them in the branch we're working in (let's call it `my-feature`).

    $ git checkout master
    $ git fetch origin
  2. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 14 additions and 8 deletions.
    22 changes: 14 additions & 8 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -28,25 +28,31 @@ One of the best features of git is that it allows you to forget that you are usi

    Let's walk through this step by step.

    1. ````git status```` allows you to see which files you've modified.
    2. ````git diff```` allows you to view a list of the modifications made to each file. Review the diff to make sure you haven't made any unintended changes.
    3. ````git add -u -p .```` allows you to pick which modifications you would like to add to the commit. You can omit the ````-p```` if you want to commit all the files that were modified in the ````git status```` command. Similarly, you can omit the ````-u```` if you have only made additive changes (ie. you didn't delete a file from the working directory).
    4. ````git diff --cached```` allows you to see the modifications that are currently waiting to be committed (ie. the contents of the git staging area).
    5. ````git commit -v```` allows you to specify a commit message and review the modifications that will be part of the commit.
    1. `git status` allows you to see which files you've modified.
    2. `git diff` allows you to view a list of the modifications made to each file. Review the diff to make sure you haven't made any unintended changes.
    3. `git add -u -p .` allows you to pick which modifications you would like to add to the commit. You can omit the `-p` if you want to commit all the files that were modified in the `git status` command. Similarly, you can omit the `-u` if you have only made additive changes (ie. you didn't delete a file from the working directory).
    4. `git diff --cached` allows you to see the modifications that are currently waiting to be committed (ie. the contents of the git staging area).
    5. `git commit -v` allows you to specify a commit message and review the modifications that will be part of the commit.

    ## Branches

    One of the other powerful features of git is it's branching mechanism. A branch in git is used to develop code independent from master, which is also a branch. The simplicity and ease of switching between branches in git is what makes it so incredibly powerful. As a result most developers choose to write most of their work outside of the master branch. This enables them to quickly switch tasks and work on different features in the same respository without having to juggle which commits make it into the master branch.

    Creating a branch from master:
    ### Creating a new branch

    git checkout -b my-feature

    This will create a new branch, named "my-feature", starting from the current branch. It will also change your current branch to the new branch. You usually want to start branches from the master branch.
    This will create a new branch, named `my-feature`, starting from the current branch. It will also change your current branch to the new branch. You usually want to start branches from the master branch.

    ### Changing to an existing branch

    git checkout my-other-feature

    This will change your working copy to reflect the contents of the `my-other-feature` branch. You should always change branches when your working copy is clean, ie. there are no modifications to files in the repository. You can verify this by running `git status`, which should report no outstanding changes.

    ## Remotes

    Remotes are at the heart of what makes git a "distributed" version control system. A remote is a git repository that exists on another machine. When we're working on teams we are able to share code among our various development repositories by syncing with a shared remote repository. Github is a popular service that offers hosting for git repositories, and also adds a number of really nice features for working on software as a group. Here's how to get started with using Github as a remote for your existing local repository:
    We said earlier that git is a *distributed* version control system. At the heart of this is the concept of remote repositories. A remote repository is a git repository that exists on another machine. When we're working on teams we are able to share code among our various development repositories by syncing with a shared remote repository. Github is a popular service that offers hosting for git repositories, and also adds a number of really nice features for working on software as a group. Here's how to get started with using Github as a remote for your existing local repository:

    ### Github repository set up:

  3. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 26 additions and 18 deletions.
    44 changes: 26 additions & 18 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,27 +4,27 @@ Git is a distributed version control system. Every Git working directory is a fu

    ## Getting Started

    Creating a repo on a local machine:
    ### Creating a repo on your machine

    $ git init

    Creating a .gitignore:
    ### Creating a .gitignore

    By default git will try to track every file that exists in the working copy. Sometimes you'll have files that you don't want git to track, e.g. log files, OS files, etc. By creating a .gitignore file you can tell git that it should happily ignore these types of files. For more info: https://help.github.com/articles/ignoring-files)

    Creating a README:
    ### Creating a README

    A README file helps communicate the intent of the project to people who later discover the project and want a higher level view of what it's about.

    ## A Typical Development Workflow

    One of the best features of git is that it allows you to forget that you are using source control while you are focused on development. Once you have some work to be put into source control it provides powerful tools to help you create a nice, curated set of commits that reflect the work you've done. The following is a typical workflow for using git:

    $ git status
    $ git diff
    $ git add -u -p .
    $ git diff --cached
    $ git commit -v
    git status
    git diff
    git add -u -p .
    git diff --cached
    git commit -v

    Let's walk through this step by step.

    @@ -40,29 +40,37 @@ One of the other powerful features of git is it's branching mechanism. A branch

    Creating a branch from master:

    1. ````git checkout -b <branch_name>```` will create a new branch starting from the current branch and change your working copy to work in that branch. You usually want to start branches from the master branch.
    git checkout -b my-feature

    This will create a new branch, named "my-feature", starting from the current branch. It will also change your current branch to the new branch. You usually want to start branches from the master branch.

    ## Remotes

    Remotes are at the heart of what makes git a "distributed" version control system. A remote is a git repository that exists on another machine. When we're working on teams we are able to share code among our various development repositories by syncing with a shared remote repository. Github is a popular service that offers hosting for git repositories, and also adds a number of really nice features for working on software as a group. Here's how to get started with using Github as a remote for your existing local repository:

    Getting a Github repository set up:
    ### Github repository set up:

    Create a new repository on Github. Github will create a url for you to use on other computers that want access the the repository on Github. Then do the following in your local repository:

    git remote add origin https://url-from-github
    git push -u origin master

    1. `$ git remote add origin https://url-from-github` this tells your local git repository that there is a remote repository which we'll call "origin" which lives at "https://url-from-github".
    2. `$ git push -u origin master` this command will push a copy of our "master" branch to the remote named "origin" (ie. Github in our case), and the `-u` tells git that our master branch should be setup to track the master branch on origin. You can omit the `-u` on future pushes because our master branch will still be tracking origin/master.

    1. Create a new repository on Github. Github will create a url for you to use on other computers that want access the the repository on Github.
    2. ````$ git remote add origin <https://url-from-github-goes-here>```` this tells your local git repository that there is a remote repository which we'll call "origin" which lives at "<https://url-from-github-goes-here>".
    3. ````$ git push origin -u master```` this command will push a copy of our "master" branch to the remote named "origin" (ie. Github in our case), and the ````-u```` tells git that our master branch should be setup to track the master branch on origin. You can omit the ````-u```` on future pushes because our master branch will still be tracking origin/master.
    ### Setting up a local repository from an existing Github repository:

    Setting up a local repository from an existing Github repository:
    git clone https://url-from-github project-name

    1. ````$ git clone <https://url-from-github-goes-here> <project-name>```` this will download a copy of the repository that lives at "<https://url-from-github-goes-here>" and put it into a directory called "<project-name>" in your current directory. You can omit the "project-name" parameter if you don't want to rename the project locally.
    This will download a copy of the repository that lives at "<https://url-from-github-goes-here>" and put it into a directory called "<project-name>" in your current directory. You can omit the "project-name" parameter if you don't want to rename the project locally.

    Pushing a branch to a remote:
    ### Pushing a branch to a remote:

    $ git push origin -u <local-branch-name>:<remote-branch-name>
    git push origin -u <local-branch-name>:<remote-branch-name>

    This is the full push command. It pushes the local-branch-name to origin, renaming it to remote-branch-name. It also sets up our local branch to track the remote branch. A shorter form is:

    $ git push origin <local-branch-name>
    git push origin <local-branch-name>

    Without specifying a remote branch name, git assumes that it should name the remote branch the same name as your local branch. If you've previously set up tracking on this branch, git will push to the remote branch that local branch is tracking.

  4. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 5 additions and 1 deletion.
    6 changes: 5 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -105,7 +105,11 @@ Removing branches from remote repositories:

    $ git push origin :my_feature

    You'll notice that this looks a lot like the normal push command (`git push origin local-branch-name:remote-branch-name`). That's because it _is_ the same command. In this case we just specify an "empty" branch for the local branch. This has the effect of pushing an empty branch to the repote repository, thus overwriting remote branch contents with an empty branch.
    You'll notice that this looks a lot like the normal push command:

    git push origin local-branch-name:remote-branch-name

    That's because it _is_ the same command. In this case we just specify an "empty" branch for the local branch. This has the effect of pushing an empty branch to the repote repository, thus overwriting remote branch contents with an empty branch.

    Removing dead references from your local repository:

  5. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 17 additions and 8 deletions.
    25 changes: 17 additions & 8 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -78,9 +78,11 @@ So, let's say that a teammate has pushed some changes that he made into the mast
    $ git checkout my-feature
    $ git rebase master

    1. `$git checkout master`

    $ git push origin my-feature
    1. `$ git checkout master` switch into the local master branch
    2. `$ git fetch origin` will fetch all of the changes that have been made to the remote repository. This only downloads the changes, it doesn't merge them into our local repo, though.
    3. `$ git rebase origin/master` in the previous step we fetched all the changes from origin, git now has references to the various branches from origin in the form of "<remote-name>/<remote-branch-name>". In this command we're telling git to rebase our current branch to start from origin's master branch. This effectively pulls in the changes from the origin to our branch.
    4. `$ git checkout my-feature` now switch back to our feature branch
    5. `$ git rebase master` and rebase it to our master branch, which now has the changes from origin/master from step 3.

    Issue a pull request (https://help.github.com/articles/creating-a-pull-request) and
    solicit feedback from your team. Once approved, merge the pull request
    @@ -98,8 +100,15 @@ Removing branches locally:
    $ git branch -d my-feature

    Sometimes you'll need to use `-D` instead of `-d`. `-D` is just a more dangerous form of the same method.
    $ git push origin :my_feature //
    Notice the :my_feature this will delete it from the origin repo.
    Your teammates should use
    $ git remote prune origin
    This will stop tracking dead branches.

    Removing branches from remote repositories:

    $ git push origin :my_feature

    You'll notice that this looks a lot like the normal push command (`git push origin local-branch-name:remote-branch-name`). That's because it _is_ the same command. In this case we just specify an "empty" branch for the local branch. This has the effect of pushing an empty branch to the repote repository, thus overwriting remote branch contents with an empty branch.

    Removing dead references from your local repository:

    $ git remote prune origin

    When you fetch/pull from a remote, your local repository will download references to all the branches the remote knows about. When a branch is removed from the remote, your local repository will still be holding onto a reference, even though the branch is now dead and gone. It's a good idea to periodically prune your local references using this command. This will remove all references that no longer exist on the given remote.
  6. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 67 additions and 49 deletions.
    116 changes: 67 additions & 49 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -7,79 +7,97 @@ Git is a distributed version control system. Every Git working directory is a fu
    Creating a repo on a local machine:

    $ git init

    Once you have some work to be committed, follow these steps:

    Creating a .gitignore:

    By default git will try to track every file that exists in the working copy. Sometimes you'll have files that you don't want git to track, e.g. log files, OS files, etc. By creating a .gitignore file you can tell git that it should happily ignore these types of files. For more info: https://help.github.com/articles/ignoring-files)

    Creating a README:

    A README file helps communicate the intent of the project to people who later discover the project and want a higher level view of what it's about.

    ## A Typical Development Workflow

    One of the best features of git is that it allows you to forget that you are using source control while you are focused on development. Once you have some work to be put into source control it provides powerful tools to help you create a nice, curated set of commits that reflect the work you've done. The following is a typical workflow for using git:

    $ git status
    $ git diff
    $ git add -p .
    $ git add -u -p .
    $ git diff --cached
    $ git commit -v

    Let's walk through this step by step.

    1. ````git status```` allows you to see which files you've modified.
    2. ````git diff```` this allows you to view a list of the modifications made to each file. Review the diff to make sure you haven't made any unintended changes.
    3. ````git add -p .```` this command will allow you to pick which modifications you would like to add to the commit. You can omit the ````-p```` if you want to commit all the files that were modified in the ````git status```` command.
    2. ````git diff```` allows you to view a list of the modifications made to each file. Review the diff to make sure you haven't made any unintended changes.
    3. ````git add -u -p .```` allows you to pick which modifications you would like to add to the commit. You can omit the ````-p```` if you want to commit all the files that were modified in the ````git status```` command. Similarly, you can omit the ````-u```` if you have only made additive changes (ie. you didn't delete a file from the working directory).
    4. ````git diff --cached```` allows you to see the modifications that are currently waiting to be committed (ie. the contents of the git staging area).
    5. ````git commit -v```` allows you to specify a commit message and review the modifications that will be part of the commit.

    ## Branches

    One of the other powerful features of git is it's branching mechanism. A branch in git is used to develop code independent from master, which is also a branch. The simplicity and ease of switching between branches in git is what makes it so incredibly powerful. As a result most developers choose to write most of their work outside of the master branch. This enables them to quickly switch tasks and work on different features in the same respository without having to juggle which commits make it into the master branch.

    Creating a branch from master:

    1. ````git checkout -b <branch_name>```` will create a new branch starting from the current branch and change your working copy to work in that branch. You usually want to start branches from the master branch.

    ## Remotes

    Remotes are at the heart of what makes git a "distributed" version control system. A remote is a git repository that exists on another machine. When we're working on teams we are able to share code among our various development repositories by syncing with a shared remote repository. Github is a popular service that offers hosting for git repositories, and also adds a number of really nice features for working on software as a group. Here's how to get started with using Github as a remote for your existing local repository:

    Getting the remote set up:

    1. Create a new repository on Github. Add a remote by
    using the url (this is only done on the initial remote creation, everyone else will
    simply clone the app that will have the remote set).
    $ git remote add origin https://url-from-github-goes-here
    Check your .gitignore to make sure you don't add any files that you do not want
    the repository to track. (https://help.github.com/articles/ignoring-files) This is
    also a good time to add a README file to help communicate the intent of the
    project.
    Make your initial commit:
    $ git add .
    $ git commit -m "initial commit - sinatra skeleton"
    Cloning the Repo
    As a team member you will clone the existing repository:
    $ git clone https://url-from-github-goes-here
    Change into that directory and make your feature branch:
    $ cd project_name$ git checkout -b my_feature
    Make all your commits in this branch while working on this feature. You can use the
    -v command while committing to look at all the changes that have been staged.
    $ git add file_or_directory
    $ git commit -v
    Leaving off the -m option to the commit will also cause your text editor to pop up.
    The first line is your commit message. This should be a quick description of what
    the commit is changing. This of this as the subject line to an email, or the title of a
    post.
    Leave a blank line, and then add additional details (if needed) about the changes
    made in this commit.
    At any point in time you can start pushing your branch to the remote repository.
    $ git push origin my_feature
    If the branch does not already exist, it will create it on the remote repo, and all
    subsequent pushes to this branch simply adds to it.
    When the feature is complete update your master branch to pull in changes made
    by your team (they may have finished their feature first).
    $ git checkout master
    $ git fetch origin
    $ git rebase origin/master
    $ git checkout my_feature
    $ git rebase master
    If there are conflicts, we will find the in this step. Resolve the conflicts in your
    feature branch and then push to origin.
    $ git push origin my_feature
    Getting a Github repository set up:

    1. Create a new repository on Github. Github will create a url for you to use on other computers that want access the the repository on Github.
    2. ````$ git remote add origin <https://url-from-github-goes-here>```` this tells your local git repository that there is a remote repository which we'll call "origin" which lives at "<https://url-from-github-goes-here>".
    3. ````$ git push origin -u master```` this command will push a copy of our "master" branch to the remote named "origin" (ie. Github in our case), and the ````-u```` tells git that our master branch should be setup to track the master branch on origin. You can omit the ````-u```` on future pushes because our master branch will still be tracking origin/master.

    Setting up a local repository from an existing Github repository:

    1. ````$ git clone <https://url-from-github-goes-here> <project-name>```` this will download a copy of the repository that lives at "<https://url-from-github-goes-here>" and put it into a directory called "<project-name>" in your current directory. You can omit the "project-name" parameter if you don't want to rename the project locally.

    Pushing a branch to a remote:

    $ git push origin -u <local-branch-name>:<remote-branch-name>

    This is the full push command. It pushes the local-branch-name to origin, renaming it to remote-branch-name. It also sets up our local branch to track the remote branch. A shorter form is:

    $ git push origin <local-branch-name>

    Without specifying a remote branch name, git assumes that it should name the remote branch the same name as your local branch. If you've previously set up tracking on this branch, git will push to the remote branch that local branch is tracking.

    ## Managing changes from other developers

    In the course of collaborating with other developers, you'll likely want to get the changes that they've made into your own local repository. This is where most of the headaches of working with git (and other developers) come from.

    So, let's say that a teammate has pushed some changes that he made into the master branch of our remote repository. We'd like to get those changes into our repository and then use them in the branch we're working in (let's call it "my-feature").

    $ git checkout master
    $ git fetch origin
    $ git rebase origin/master
    $ git checkout my-feature
    $ git rebase master

    1. `$git checkout master`

    $ git push origin my-feature

    Issue a pull request (https://help.github.com/articles/creating-a-pull-request) and
    solicit feedback from your team. Once approved, merge the pull request
    (https://help.github.com/articles/merging-a-pull-request). This will merge your
    feature with master on the origin, which puts your master out of date.
    Update your copy of master
    $ git fetch origin$ git rebase origin/master
    Remove dead branches (the branches you will no longer be working in)
    $ git branch -d my_feature

    ## Keeping git clean - Removing dead branches

    In the process of working in branches and merging pull requests, your local and remote repositories will build up branches that have already been merged, and are no longer needed. A dirty remote or local repository will slow you and your team down, as your repository is at the heart of communication about the state of the code (ie. what is in progress).

    Removing branches locally:

    $ git branch -d my-feature

    Sometimes you'll need to use `-D` instead of `-d`. `-D` is just a more dangerous form of the same method.
    $ git push origin :my_feature //
    Notice the :my_feature this will delete it from the origin repo.
    Your teammates should use
  7. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 7 additions and 1 deletion.
    8 changes: 7 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -11,12 +11,18 @@ Creating a repo on a local machine:
    Once you have some work to be committed, follow these steps:

    $ git status
    $ git diff
    $ git add -p .
    $ git diff --cached
    $ git commit -v

    Let's walk through this step by step.

    1. ````git status````
    1. ````git status```` allows you to see which files you've modified.
    2. ````git diff```` this allows you to view a list of the modifications made to each file. Review the diff to make sure you haven't made any unintended changes.
    3. ````git add -p .```` this command will allow you to pick which modifications you would like to add to the commit. You can omit the ````-p```` if you want to commit all the files that were modified in the ````git status```` command.
    4. ````git diff --cached```` allows you to see the modifications that are currently waiting to be committed (ie. the contents of the git staging area).
    5. ````git commit -v```` allows you to specify a commit message and review the modifications that will be part of the commit.



  8. dbc-challenges revised this gist Aug 10, 2013. 1 changed file with 13 additions and 1 deletion.
    14 changes: 13 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,9 +4,21 @@ Git is a distributed version control system. Every Git working directory is a fu

    ## Getting Started

    Creating a repo on a local machine
    Creating a repo on a local machine:

    $ git init

    Once you have some work to be committed, follow these steps:

    $ git status
    $ git add -p .
    $ git commit -v

    Let's walk through this step by step.

    1. ````git status````



    ## Remotes

  9. dbc-challenges created this gist Aug 10, 2013.
    69 changes: 69 additions & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,69 @@
    # Git: Working with Teams

    Git is a distributed version control system. Every Git working directory is a full-fledged repository with complete history and full version tracking capabilities, not dependent on network access or a central server.

    ## Getting Started

    Creating a repo on a local machine

    $ git init

    ## Remotes

    Remotes are at the heart of what makes git a "distributed" version control system. A remote is a git repository that exists on another machine. When we're working on teams we are able to share code among our various development repositories by syncing with a shared remote repository. Github is a popular service that offers hosting for git repositories, and also adds a number of really nice features for working on software as a group. Here's how to get started with using Github as a remote for your existing local repository:

    Getting the remote set up:

    1. Create a new repository on Github. Add a remote by
    using the url (this is only done on the initial remote creation, everyone else will
    simply clone the app that will have the remote set).
    $ git remote add origin https://url-from-github-goes-here
    Check your .gitignore to make sure you don't add any files that you do not want
    the repository to track. (https://help.github.com/articles/ignoring-files) This is
    also a good time to add a README file to help communicate the intent of the
    project.
    Make your initial commit:
    $ git add .
    $ git commit -m "initial commit - sinatra skeleton"
    Cloning the Repo
    As a team member you will clone the existing repository:
    $ git clone https://url-from-github-goes-here
    Change into that directory and make your feature branch:
    $ cd project_name$ git checkout -b my_feature
    Make all your commits in this branch while working on this feature. You can use the
    -v command while committing to look at all the changes that have been staged.
    $ git add file_or_directory
    $ git commit -v
    Leaving off the -m option to the commit will also cause your text editor to pop up.
    The first line is your commit message. This should be a quick description of what
    the commit is changing. This of this as the subject line to an email, or the title of a
    post.
    Leave a blank line, and then add additional details (if needed) about the changes
    made in this commit.
    At any point in time you can start pushing your branch to the remote repository.
    $ git push origin my_feature
    If the branch does not already exist, it will create it on the remote repo, and all
    subsequent pushes to this branch simply adds to it.
    When the feature is complete update your master branch to pull in changes made
    by your team (they may have finished their feature first).
    $ git checkout master
    $ git fetch origin
    $ git rebase origin/master
    $ git checkout my_feature
    $ git rebase master
    If there are conflicts, we will find the in this step. Resolve the conflicts in your
    feature branch and then push to origin.
    $ git push origin my_feature
    Issue a pull request (https://help.github.com/articles/creating-a-pull-request) and
    solicit feedback from your team. Once approved, merge the pull request
    (https://help.github.com/articles/merging-a-pull-request). This will merge your
    feature with master on the origin, which puts your master out of date.
    Update your copy of master
    $ git fetch origin$ git rebase origin/master
    Remove dead branches (the branches you will no longer be working in)
    $ git branch -d my_feature
    $ git push origin :my_feature //
    Notice the :my_feature this will delete it from the origin repo.
    Your teammates should use
    $ git remote prune origin
    This will stop tracking dead branches.