Difference between revisions of "DPS909 & OSD600 Winter 2017"

From CDOT Wiki
Jump to: navigation, search
(→‎Week 4)
(→‎Week 4)
Line 108: Line 108:
 
** <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.
 
** <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.
 
** If you need to squash the last few commits, you can use <code>git rebase -i HEAD~2</code> for example.
 +
* conflicts while merging, rebasing
 +
** Git compares files at the line level: if two commits both change the same line(s), there will be a conflict
 +
** Git can't automatically resolve two competing changes to the same line(s), since it isn't clear which one is right--you have to do it manually
 +
** Using <code>git status</code> to discover which files have conflicts
 +
** Examining, understanding, and working with conflict markers ">>>>" and "<<<<"
 +
** <code>git add</code> and <code>git commit</code>
 +
** Here's a [https://www.youtube.com/watch?v=4dJcsF6hgS4&index=5&list=PLDshL1Z581YYxLsjYwM25HkIYrymXb7H_ video demo] of resolving merge conflicts manually
 +
** Various visual tools exist for doing this, too:
 +
*** [http://meldmerge.org/ Meld]
 +
*** [http://naleid.com/blog/2013/10/29/how-to-use-p4merge-as-a-3-way-merge-tool-with-git-and-tower-dot-app p4merge]
 +
*** [https://developer.atlassian.com/blog/2015/12/tips-tools-to-solve-git-conflicts/ others discussed here]
 
* gh-pages
 
* gh-pages
 
** Great for hosting static web content associated with a project
 
** Great for hosting static web content associated with a project

Revision as of 16:21, 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.
  • conflicts while merging, rebasing
    • Git compares files at the line level: if two commits both change the same line(s), there will be a conflict
    • Git can't automatically resolve two competing changes to the same line(s), since it isn't clear which one is right--you have to do it manually
    • Using git status to discover which files have conflicts
    • Examining, understanding, and working with conflict markers ">>>>" and "<<<<"
    • git add and git commit
    • Here's a video demo of resolving merge conflicts manually
    • Various visual tools exist for doing this, too:
  • gh-pages


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