Difference between revisions of "DPS909 & OSD600 Winter 2017"

From CDOT Wiki
Jump to: navigation, search
(→‎Week 4)
(→‎Week 4)
Line 64: Line 64:
  
 
* Working with git Branches
 
* Working with git Branches
−
** Lightweight, movable, reference (or pointer) to a commit
 
−
** Series of commits: a branch is the furthest tip of a line of commits
 
−
** It is always safe to branch, it won't change the code in any way
 
−
** Relationship of <code>git commit</code> with branches
 
−
*** commit SHA: <code>e0ee2b5acd01acbe5b0bc1ee24b73e5d53a1fd70</code> or shortened to <code>e0ee2b5</code>
 
−
*** <code>HEAD</code>: the most recent commit (NOTE: you can also do <code>HEAD~2</code> to mean 2 commits older than <code>HEAD</code> or <code>HEAD~5</code> to mean 5 commits older than <code>HEAD</code>),
 
−
*** branch: an easy to remember name we give to the current commit, e.g., <code>master</code>
 
−
*** <code>master</code> branch vs. "Topic Branches": '''all work happens on a new branch'''
 
−
** creating, switching between, updating
 
−
*** <code>git branch <branch name></code>: <code>-d</code> (maybe delete), <code>-D</code> (force delete), <code>-m</code> (rename), <code>-a</code> (list all)
 
−
*** <code>git checkout <branch name | commit SHA></code>, discussion of "detached HEAD"
 
−
*** <code>git checkout -b <branch name> [<base commit> | HEAD]</code>(create if doesn't exist, checkout new branch)
 
−
*** <code>git checkout -B <branch name> [<base commit> | HEAD]</code> (create or reset, checkout new branch)
 
−
** local vs. remote, tracking branches
 
−
*** Branches are '''always local''' to your current repo
 
−
*** <code>git branch -a</code> will show all of your branches, and any/all '''remote branches''' (i.e., branches in remote repos your repo knows about via <code>git fetch</code>)
 
−
*** Example: <code>git checkout -b bug123 friend-repo/bug123</code> will create a branch '''bug123''' locally that is pointing at the same commit as the remote repo '''friend-repo''''s '''bug123''' branch.
 
−
*** Any branch you check out that is based on a remote branch will be '''tracked''' by git, and any commits they have ahead of you, or you have ahead of them, will get reported
 
−
** common workflow
 
−
*** <code>git checkout master</code> - switch to master branch
 
−
*** <code>git pull upstream master</code> - pull in any new commits from the upstream/master branch
 
−
*** <code>git checkout -b issue-1234</code> - create a topic branch for your work, named with bug #
 
−
*** <code>git add files</code> - edit files, add to staging area
 
−
*** <code>git commit -m "Fix #1234: ..."</code> - commit changes, referencing bug # in commit message
 
−
*** <code>git push origin issue-1234</code> - push your topic branch (and all commits) to your origin repo
 
−
*** create pull request
 
−
** merging
 
−
*** A merge in git is a way of combining branches into a single branch/history
 
−
*** We always fix bugs and add features on '''new branches''', but then we need to '''merge''' them back into the main '''master''' branch
 
−
*** Merging doesn't change any of the branches it combines, it simply connects them.
 
−
*** <code>git merge <branch name></code> merges <code><branch name></code> '''into''' the currently checked out branch
 
−
*** Different merge algorithms
 
−
**** fast-forward merge - given identical histories, move the branch ahead in the history to the new tip
 
−
**** 3-way merge - divergent histories, use common ancestor commit (commit 1), and two branch tops (2, 3)
 
−
*** recall that <code>git pull</code> does a <code>git fetch</code> and <code>git merge</code> in one step
 
−
** rebasing
 
−
*** Replay a series of commits on a different branch vs. the current one, rewriting its history
 
−
*** Often done with '''squashing''' (combining multiple commits into a single commit) on topic branches before merging with <code>master</code> to simplify the history
 
−
*** Because it rewrites history, you shouldn't do it on branches shared with other developers
 
−
*** <code>git rebase <new-base></code>
 
−
*** After a rebase, it's easy to do '''fast-forward''' merges
 
−
*** <code>git rebase -i</code> starts an interactive rebase, and lets you specify what to do with each commit.  <code>git rebase --abort</code> let's you stop it mid-way through.
 
−
*** If you need to squash the last few commits, you can use <code>git rebase -i HEAD~2</code> for example.
 
−
** gh-pages
 
  
 +
* Lightweight, movable, reference (or pointer) to a commit
 +
* Series of commits: a branch is the furthest tip of a line of commits
 +
* It is always safe to branch, it won't change the code in any way
 +
* Relationship of <code>git commit</code> with branches
 +
** commit SHA: <code>e0ee2b5acd01acbe5b0bc1ee24b73e5d53a1fd70</code> or shortened to <code>e0ee2b5</code>
 +
** <code>HEAD</code>: the most recent commit (NOTE: you can also do <code>HEAD~2</code> to mean 2 commits older than <code>HEAD</code> or <code>HEAD~5</code> to mean 5 commits older than <code>HEAD</code>),
 +
** branch: an easy to remember name we give to the current commit, e.g., <code>master</code>
 +
** <code>master</code> branch vs. "Topic Branches": '''all work happens on a new branch'''
 +
* creating, switching between, updating
 +
** <code>git branch <branch name></code>: <code>-d</code> (maybe delete), <code>-D</code> (force delete), <code>-m</code> (rename), <code>-a</code> (list all)
 +
** <code>git checkout <branch name | commit SHA></code>, discussion of "detached HEAD"
 +
** <code>git checkout -b <branch name> [<base commit> | HEAD]</code>(create if doesn't exist, checkout new branch)
 +
** <code>git checkout -B <branch name> [<base commit> | HEAD]</code> (create or reset, checkout new branch)
 +
* local vs. remote, tracking branches
 +
** Branches are '''always local''' to your current repo
 +
** <code>git branch -a</code> will show all of your branches, and any/all '''remote branches''' (i.e., branches in remote repos your repo knows about via <code>git fetch</code>)
 +
** Example: <code>git checkout -b bug123 friend-repo/bug123</code> will create a branch '''bug123''' locally that is pointing at the same commit as the remote repo '''friend-repo''''s '''bug123''' branch.
 +
** Any branch you check out that is based on a remote branch will be '''tracked''' by git, and any commits they have ahead of you, or you have ahead of them, will get reported
 +
* common workflow
 +
** <code>git checkout master</code> - switch to master branch
 +
** <code>git pull upstream master</code> - pull in any new commits from the upstream/master branch
 +
** <code>git checkout -b issue-1234</code> - create a topic branch for your work, named with bug #
 +
** <code>git add files</code> - edit files, add to staging area
 +
** <code>git commit -m "Fix #1234: ..."</code> - commit changes, referencing bug # in commit message
 +
** <code>git push origin issue-1234</code> - push your topic branch (and all commits) to your origin repo
 +
** create pull request
 +
* merging
 +
** A merge in git is a way of combining branches into a single branch/history
 +
** We always fix bugs and add features on '''new branches''', but then we need to '''merge''' them back into the main '''master''' branch
 +
** Merging doesn't change any of the branches it combines, it simply connects them.
 +
** <code>git merge <branch name></code> merges <code><branch name></code> '''into''' the currently checked out branch
 +
** Different merge algorithms
 +
*** fast-forward merge - given identical histories, move the branch ahead in the history to the new tip
 +
*** 3-way merge - divergent histories, use common ancestor commit (commit 1), and two branch tops (2, 3)
 +
** recall that <code>git pull</code> does a <code>git fetch</code> and <code>git merge</code> in one step
 +
* rebasing
 +
** Replay a series of commits on a different branch vs. the current one, rewriting its history
 +
** Often done with '''squashing''' (combining multiple commits into a single commit) on topic branches before merging with <code>master</code> to simplify the history
 +
** Because it rewrites history, you shouldn't do it on branches shared with other developers
 +
** <code>git rebase <new-base></code>
 +
** After a rebase, it's easy to do '''fast-forward''' merges
 +
** <code>git rebase -i</code> starts an interactive rebase, and lets you specify what to do with each commit.  <code>git rebase --abort</code> let's you stop it mid-way through.
 +
** If you need to squash the last few commits, you can use <code>git rebase -i HEAD~2</code> for example.
 +
* gh-pages
 +
** Great for hosting static web content associated with a project
 +
** https://pages.github.com/
 +
** Once enabled for a project, you can use a special <code>gh-pages</code> branch
 +
** Pushing commits to this branch will cause web content to get hosted at '''http://username.github.io/repository'''
  
 
<!--  
 
<!--  

Revision as of 15:45, 30 January 2017

Resources for DPS909 & OSD600

Week 1

  • Course introduction
  • Some questions:
    • What was the first video game you ever played?
    • What are your main technical strengths, which technologies do you know well and enjoy?
    • Which (new) technologies are you excited to learn and try?
    • When you hear "open source," what comes to mind?
    • Do you have any hesitation, fears, or anxieties about working in open source projects?
  • How to have Success in this course:
    • Willingness to be lost and not panic
    • Willingness to put yourself out there, jump in
    • Curiosity
    • Being driven, persistence
    • Willingness to ask for help
    • Willingness to give others help
    • Independent learning
    • Doing more than the bare minimum

Week 2

Week 3

Week 4

  • Working with git Branches
  • Lightweight, movable, reference (or pointer) to a commit
  • Series of commits: a branch is the furthest tip of a line of commits
  • It is always safe to branch, it won't change the code in any way
  • Relationship of git commit with branches
    • commit SHA: e0ee2b5acd01acbe5b0bc1ee24b73e5d53a1fd70 or shortened to e0ee2b5
    • HEAD: the most recent commit (NOTE: you can also do HEAD~2 to mean 2 commits older than HEAD or HEAD~5 to mean 5 commits older than HEAD),
    • branch: an easy to remember name we give to the current commit, e.g., master
    • master branch vs. "Topic Branches": all work happens on a new branch
  • creating, switching between, updating
    • git branch <branch name>: -d (maybe delete), -D (force delete), -m (rename), -a (list all)
    • git checkout <branch name | commit SHA>, discussion of "detached HEAD"
    • git checkout -b <branch name> [<base commit> | HEAD](create if doesn't exist, checkout new branch)
    • git checkout -B <branch name> [<base commit> | HEAD] (create or reset, checkout new branch)
  • local vs. remote, tracking branches
    • Branches are always local to your current repo
    • git branch -a will show all of your branches, and any/all remote branches (i.e., branches in remote repos your repo knows about via git fetch)
    • Example: git checkout -b bug123 friend-repo/bug123 will create a branch bug123 locally that is pointing at the same commit as the remote repo friend-repo's bug123 branch.
    • Any branch you check out that is based on a remote branch will be tracked by git, and any commits they have ahead of you, or you have ahead of them, will get reported
  • common workflow
    • git checkout master - switch to master branch
    • git pull upstream master - pull in any new commits from the upstream/master branch
    • git checkout -b issue-1234 - create a topic branch for your work, named with bug #
    • git add files - edit files, add to staging area
    • git commit -m "Fix #1234: ..." - commit changes, referencing bug # in commit message
    • git push origin issue-1234 - push your topic branch (and all commits) to your origin repo
    • create pull request
  • merging
    • A merge in git is a way of combining branches into a single branch/history
    • We always fix bugs and add features on new branches, but then we need to merge them back into the main master branch
    • Merging doesn't change any of the branches it combines, it simply connects them.
    • git merge <branch name> merges <branch name> into the currently checked out branch
    • Different merge algorithms
      • fast-forward merge - given identical histories, move the branch ahead in the history to the new tip
      • 3-way merge - divergent histories, use common ancestor commit (commit 1), and two branch tops (2, 3)
    • recall that git pull does a git fetch and git merge in one step
  • rebasing
    • Replay a series of commits on a different branch vs. the current one, rewriting its history
    • Often done with squashing (combining multiple commits into a single commit) on topic branches before merging with master to simplify the history
    • Because it rewrites history, you shouldn't do it on branches shared with other developers
    • git rebase <new-base>
    • After a rebase, it's easy to do fast-forward merges
    • git rebase -i starts an interactive rebase, and lets you specify what to do with each commit. git rebase --abort let's you stop it mid-way through.
    • If you need to squash the last few commits, you can use git rebase -i HEAD~2 for example.
  • gh-pages


Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909_%26_OSD600_Winter_2017&oldid=122953"