Difference between revisions of "DPS909 & OSD600 Fall 2019"

From CDOT Wiki
Jump to: navigation, search
(→‎Week 8)
(→‎Week 8)
Line 321: Line 321:
  
 
* Discussion of Labs for the rest of the term.
 
* Discussion of Labs for the rest of the term.
 +
** Every week you'll need to contribute in some way to our open source project.  This could be a small PR, reviewing code, adding some docs, writing a test, working in issues, doing research and writing background material, etc.
 +
** Your lab blog post each week should discuss what you did

Revision as of 15:18, 27 October 2019

Week 1

  • Course introduction
  • Labs
    • Weekly labs, typically done in class
    • Labs are due on the Friday of the week they are assigned by midnight
    • Marked using Pass/Fail scheme
    • All labs must be completed to pass the course
    • Lab 1 is available now
  • Releases
    • 4 releases, some with multiple bugs/PRs required, including participating in Hacktoberfest 2019
    • Due Dates: Sept 20, Oct 31, Nov 20, Dec 6
    • Chance to work on real code, real projects
    • Big learning curve, lots of time required
    • Amazing chance to gain experience, network, build your skills and resume
    • Work with new and emerging technologies, gain exposure to tech outside the classroom
  • Discussion/Readings
    • Copyright (Copyright in Canada video)
      • IANAL
      • Who created it, "owns" it.
      • Set of exclusive rights granted to the work's creator
      • "The right to copy," to produce or reproduce a work or substantial portion thereof
      • Copyright is automatic when a work is created, you don't have to register it.
      • Copyright in Canada
      • Copyright Guide
      • In a software project, there can be many copyright holders (e.g., many contributors), or all contributors may assign their copyright to the project (e.g., CLA, which we'll cover later)

Week 2

  • Licenses
    • Rights, privileges, responsibilities, etc. applicable to someone other than the work's creator
    • "Terms and Conditions"
    • These must be granted by a copyright holder

Week 3

  • Introducing git and GitHub
    • Content Addressable Filesystem and Snapshots
    • Distributed: Local vs. Remote development
    • .git directory
    • Content Integrity, SHAs (Secure Hash Algorithm)
      • git init
      • echo 'test content' | git hash-object -w --stdin
      • ls .git/objects
      • git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
    • Blobs, Trees, and Commits
    • Branches, master
    • Working Directory, Staging Area, Repository
    • What do these commands really do?
      • git clone url-to-git-repo
      • git add file.txt
      • git status
      • git rm file.txt
      • git commit -m "Added file.txt"
    • Remotes, origin, upstream

Week 4

Week 5

  • Forking vs. Merging
    • Anyone can fork, not everyone can get work merged back in
    • My Repo: my house my rules
    • Some famous Forks
      • Firefox from Mozilla Suite
      • WebKit from KDE's KHTML
      • Blink from WebKit
      • Ubuntu from Debian
      • Sun's StarOffice became OpenOffice became LibreOffice
      • WordPress from Cafelog
      • MariaDB from MySQL
      • FireOS (Amazon for Kindle) from Android
      • io.js from node.js, which eventually became the official node.js
    • Example Fork
      • Semantic UI
      • Fomantic UI - "Fomantic was created to continue active development of Semantic-UI and has the intent to be merged back into the master repository once active development can restart."
  • Merging with git
    • Where git branch splits histories apart, git merge brings them back together
    • Understanding DIFFs and Patch files
    • Types of Merges: Fast Forward, Recursive Merges are the most common
      • --ff-only to force a fast-forward (only the branch pointer is moved, no new commit is created)
      • 3-way merges: two branch commits with a common ancestor (new commit is created with multiple parents)
      • Can have any number of parents though: one of the larges is a 66 commit octopus merge in the Linux kernel
    • How to merge
      • start with a clean working directory
        • commit your work if you can; or
        • stash (git stash list, git stash show, git stash pop)
      • checkout the branch you want to merge into
      • git merge branch_to_merge_into_this_branch
    • Various flags and commands to know:
      • git merge --squash
      • git merge --abort
      • git merge --continue
      • git branch -d
    • Merge Conflicts
      • Conflict markers <<<<<<<<<, =============, >>>>>>>>>>>>
    • Doing big merges in git
  • TODO
    • Merging 3 PRs example
    • Release 0.2
    • Lab 4 - Complete your first Hacktoberfest PR, and write your first blog post about your fix. See guidelines in the Release 0.2 page. Place both links in a new section under the Submission section.

Week 6

  • 0.2 Updates
    • How's it Going?
      • Things I read in your blog posts:
        • Setting up projects takes time, research (Docker, Gatsby, Makefile, Gems, npm builds etc)
        • Trouble running projects
        • Watch Windows line ending issues
        • Need to fix things the way the project wants vs. how you want
        • Include links in your blog posts when you talk about things
    • Interesting projects you've found?
    • Stats for Week 1
      • 44 PRs: +3,358/-941 lines of code across 178 files in 37 repositories
      • 19 have already been merged
      • 21 people didn't get Lab 1 done (no PR/blog)
  • git commit --amend
    • Add to, correct, or otherwise alter your previous commit and/or comment message
    • Use --no-edit to leave the commit message alone
  • git rebase branch
    • Replay commits on a new base branch/commit
    • Process goes like this:
      • git finds a common ancestor commit of the branch you're on, and the one you're rebasing onto
      • git calculates DIFFs for each, saves them to disk
      • git checks out the commit you want to branch onto, and begins to replay those diffs one by one
      • if there is a merge conflict, the rebase pauses so you can fix things
      • use git rebase --continue or git rebase --abort to move forward after such a pause
      • use git rebase --skip to ignore the current commit and keep going
    • Never rebase commits that are shared publicly in another repo. Only do it on commits you own locally (e.g., a topic branch you are working on)
    • Don't use rebase to get rid of commits in a public branch, use git revert commit-sha instead to apply an inverse commit
    • If you rebase a branch you've pushed (e.g., for a pull request), when you push, use git push origin branch-name -f (f means force and will overwrite)
    • git rebase -i for interactive rebase
      • shows a script of all commits in reverse order (order they will be replayed). You can hand edit this to remove, re-order, or combine commits
    • You can squash on the same branch by rebasing on HEAD~n where n is how many commits back from HEAD to go
  • git cherry-pick SHA to add a commit to the current branch

Week 7

Week 8

  • Continue working on 0.2
  • Wrap-up and Discussion of Hacktoberfest 2019
  • Discussion of Labs for the rest of the term.
    • Every week you'll need to contribute in some way to our open source project. This could be a small PR, reviewing code, adding some docs, writing a test, working in issues, doing research and writing background material, etc.
    • Your lab blog post each week should discuss what you did
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909_%26_OSD600_Fall_2019&oldid=141457"