667
edits
Changes
Created page with "=Git Walkthrough: Working Remote= In the previous walk-through, we looked at the basics of using git for revision control. This time we we'..."
=Git Walkthrough: Working Remote=
In the [[DPS909 & OSD600 Winter 2017 | previous walk-through]], we looked at the basics of using git for revision control. This time we we'll learn how to use git in a distributed workflow, and how to interact with remote repositories, such as those on Github.
===Step 1: Using Git with Github===
For this walkthrough, we'll need [https://help.github.com/articles/signing-up-for-a-new-github-account/ an account on Github]. Think of a Github account like a driver's license: it's what allows you to participate in many open source projects. If you haven't done so before, take a few minutes to do the following:
# [https://github.com/join create an account]
# [https://help.github.com/articles/verifying-your-email-address/ verify your email address]
# [https://help.github.com/articles/about-two-factor-authentication/ consider enabling two-factor authentication]
# [https://help.github.com/articles/adding-a-bio-to-your-profile/ add info to your account bio]
# [https://help.github.com/articles/setting-your-profile-picture/ consider changing your profile picture]
We'll also need to do a bit more [https://help.github.com/articles/set-up-git/ setup with git]. Specifically, we need to set some global <code>config</code> options, SSH keys, etc:
# [https://help.github.com/articles/setting-your-username-in-git/ set your username locally]
# [https://help.github.com/articles/setting-your-email-in-git/ set your email address locally]
# [https://help.github.com/articles/dealing-with-line-endings/ set your line endings]
# [https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup consider setting other global defaults while you're at it (e.g., your default editor)]
# [https://help.github.com/articles/connecting-to-github-with-ssh/ set up SSH keys]
===Step 2: Clones and Forking===
Git is a '''distributed''' revision control system, which means that unlike client/server systems, git has no concept of a central server that we work against. Instead, everyone who works on a repository first creates his or her own copy. If I want to work with a repository that you made, my first task is to make my own personal copy, then work on that directly.
Git calls this copy of a repository a '''clone'''. One of the great advantages of having your own local clone of a repository is that you don't need a network connection in order to work with it (i.e., everything is local), and you have complete control over everything you do (i.e., you don't need permission to commit changes). Cloning a repository copies '''every''' commit and version of '''every''' file in the original project's history. As a result, git clones can take a lot of disk space.
Every git developer works directly with his or her own local clone of a repository, then uses a combination of git's '''push''' and '''pull''' commands to sync their work with remote repositories--we'll do this below. Because its so common to want to share our local repositories with one another, and to clone each other's repositories locally, we use Github as a public host.
It's possible with git to clone repositories from a USB key, or copy entire repos across a shared drive. But it's not realistic to do this with people on the other side of the world. Instead, it's more convenient to use the Internet and a shared hosting platform.
Every Github user can have an unlimited number of open source repositories (private/closed source repositories cost money). Because the default workflow with git is to clone a repository before we use it, Github includes this as a central feature, which it calls '''forking'''.
What Github calls a '''fork''' is really just another name for a '''clone'''. You'll see both '''fork''' and '''clone''' used on Github, and you can think of the difference this way:
* '''fork''': copy an existing Github repository to your Github account. This forked copy will live on Github's servers, but you will have full ownership over it. It's typical to '''fork''' any repository to which you want to contribute.
* '''clone''': create a local copy of a repository on Github on your computer. It's typical to '''clone''' repositories that you have previously '''forked'''.
Let's fork a repository. Follow the instructions in [https://help.github.com/articles/fork-a-repo/ Fork a Repo] to fork the [https://github.com/octocat/Spoon-Knife Spoon-Knife] repository.
While we're at it, let's also fork the [https://github.com/twbs/bootstrap Bootstrap repository], so we can carry on with things we were trying in our earlier walkthrough.
===Step 3: Cloning a Forked Repository===
* Client Server (SVN) and Distributed (Git)
* Snapshots vs. versioned files.
** Walkthrough -
** Checksums, SHA-1 ([http://www.miraclesalad.com/webtools/sha1.php try online])
** Starting a Git Repo:
*** git init
*** git clone
** File States:
*** Untracked (not known to git)
*** Tracked: modified, staged, committed
** The staging area
* Basic Git Commands and Concepts
** git help ''<command>''
** git add
** git commit, git commit -m, git commit -a
** git rm
** git mv
** git status
** git log
** git diff, git diff --staged
** .gitignore
** Branches
*** HEAD, master
*** git checkout, git checkout -b
*** git branch, git branch -a, git branch -d, git branch --merged, git branch --contains
*** git merge
*** git rebase
** Remotes
*** origin, origin/''branch''
*** git remote
*** git remote add
*** git fetch
*** git pull
*** git push
** Github, Pull Requests
In the [[DPS909 & OSD600 Winter 2017 | previous walk-through]], we looked at the basics of using git for revision control. This time we we'll learn how to use git in a distributed workflow, and how to interact with remote repositories, such as those on Github.
===Step 1: Using Git with Github===
For this walkthrough, we'll need [https://help.github.com/articles/signing-up-for-a-new-github-account/ an account on Github]. Think of a Github account like a driver's license: it's what allows you to participate in many open source projects. If you haven't done so before, take a few minutes to do the following:
# [https://github.com/join create an account]
# [https://help.github.com/articles/verifying-your-email-address/ verify your email address]
# [https://help.github.com/articles/about-two-factor-authentication/ consider enabling two-factor authentication]
# [https://help.github.com/articles/adding-a-bio-to-your-profile/ add info to your account bio]
# [https://help.github.com/articles/setting-your-profile-picture/ consider changing your profile picture]
We'll also need to do a bit more [https://help.github.com/articles/set-up-git/ setup with git]. Specifically, we need to set some global <code>config</code> options, SSH keys, etc:
# [https://help.github.com/articles/setting-your-username-in-git/ set your username locally]
# [https://help.github.com/articles/setting-your-email-in-git/ set your email address locally]
# [https://help.github.com/articles/dealing-with-line-endings/ set your line endings]
# [https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup consider setting other global defaults while you're at it (e.g., your default editor)]
# [https://help.github.com/articles/connecting-to-github-with-ssh/ set up SSH keys]
===Step 2: Clones and Forking===
Git is a '''distributed''' revision control system, which means that unlike client/server systems, git has no concept of a central server that we work against. Instead, everyone who works on a repository first creates his or her own copy. If I want to work with a repository that you made, my first task is to make my own personal copy, then work on that directly.
Git calls this copy of a repository a '''clone'''. One of the great advantages of having your own local clone of a repository is that you don't need a network connection in order to work with it (i.e., everything is local), and you have complete control over everything you do (i.e., you don't need permission to commit changes). Cloning a repository copies '''every''' commit and version of '''every''' file in the original project's history. As a result, git clones can take a lot of disk space.
Every git developer works directly with his or her own local clone of a repository, then uses a combination of git's '''push''' and '''pull''' commands to sync their work with remote repositories--we'll do this below. Because its so common to want to share our local repositories with one another, and to clone each other's repositories locally, we use Github as a public host.
It's possible with git to clone repositories from a USB key, or copy entire repos across a shared drive. But it's not realistic to do this with people on the other side of the world. Instead, it's more convenient to use the Internet and a shared hosting platform.
Every Github user can have an unlimited number of open source repositories (private/closed source repositories cost money). Because the default workflow with git is to clone a repository before we use it, Github includes this as a central feature, which it calls '''forking'''.
What Github calls a '''fork''' is really just another name for a '''clone'''. You'll see both '''fork''' and '''clone''' used on Github, and you can think of the difference this way:
* '''fork''': copy an existing Github repository to your Github account. This forked copy will live on Github's servers, but you will have full ownership over it. It's typical to '''fork''' any repository to which you want to contribute.
* '''clone''': create a local copy of a repository on Github on your computer. It's typical to '''clone''' repositories that you have previously '''forked'''.
Let's fork a repository. Follow the instructions in [https://help.github.com/articles/fork-a-repo/ Fork a Repo] to fork the [https://github.com/octocat/Spoon-Knife Spoon-Knife] repository.
While we're at it, let's also fork the [https://github.com/twbs/bootstrap Bootstrap repository], so we can carry on with things we were trying in our earlier walkthrough.
===Step 3: Cloning a Forked Repository===
* Client Server (SVN) and Distributed (Git)
* Snapshots vs. versioned files.
** Walkthrough -
** Checksums, SHA-1 ([http://www.miraclesalad.com/webtools/sha1.php try online])
** Starting a Git Repo:
*** git init
*** git clone
** File States:
*** Untracked (not known to git)
*** Tracked: modified, staged, committed
** The staging area
* Basic Git Commands and Concepts
** git help ''<command>''
** git add
** git commit, git commit -m, git commit -a
** git rm
** git mv
** git status
** git log
** git diff, git diff --staged
** .gitignore
** Branches
*** HEAD, master
*** git checkout, git checkout -b
*** git branch, git branch -a, git branch -d, git branch --merged, git branch --contains
*** git merge
*** git rebase
** Remotes
*** origin, origin/''branch''
*** git remote
*** git remote add
*** git fetch
*** git pull
*** git push
** Github, Pull Requests