Difference between revisions of "DPS909 & OSD600 Winter 2019"
(→Week 6) |
|||
(6 intermediate revisions by the same user not shown) | |||
Line 137: | Line 137: | ||
* [[DPS909/OSD600 Winter 2019 Lab 2|Lab 2]] | * [[DPS909/OSD600 Winter 2019 Lab 2|Lab 2]] | ||
+ | |||
+ | == Week 4 == | ||
+ | |||
+ | * Learning Licenses: MIT | ||
+ | ** [https://choosealicense.com/licenses/mit/ MIT License] | ||
+ | ** [https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html The MIT License, Line by Line] | ||
+ | ** One of the most widely used licenses in Open Source | ||
+ | ** Like the BSD License, nothing about patents (created before software was patentable in the US) | ||
+ | ** Example software projects licensed under the BSD License: | ||
+ | *** [https://expressjs.com/ ExpressJS] | ||
+ | *** [http://rubyonrails.org/ Ruby on Rails] | ||
+ | *** [https://angularjs.org/ AngularJS] | ||
+ | *** [https://atom.io/ Atom], [https://electron.atom.io/ Electron] | ||
+ | *** [http://getbootstrap.com/ Bootstrap] | ||
+ | *** [https://nodejs.org/ node.js] | ||
+ | *** [https://github.com/photonstorm/phaser Phaser] | ||
+ | *** [https://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] | ||
+ | *** [https://socket.io/ Socket.IO] | ||
+ | |||
+ | * More Git | ||
+ | ** Understanding how git works | ||
+ | *** SHAs | ||
+ | *** commits, trees, blobs | ||
+ | *** branches | ||
+ | *** Working Directory vs. Staging Area vs. HEAD | ||
+ | ** [https://wiki.cdot.senecacollege.ca/wiki/DPS909_%26_OSD600_Fall_2017_-_Git_Walkthrough Git Walkthrough Part I] | ||
+ | ** [[DPS909 & OSD600 Winter 2017 - Git Walkthrough 2| Git Walkthrough Part II]] | ||
+ | ** Some basic git commands you should make sure you know how to use: | ||
+ | ***<code>git clone</code> - clone an existing repository (i.e., one you've forked on GitHub) | ||
+ | ***<code>git status</code> - check what's happening with your repo, working directory, branch info | ||
+ | ***<code>git add</code> - add a file, files, or folder(s) of file(s) | ||
+ | ***<code>git commit</code> - commit changes in the staging area | ||
+ | ***<code>git log</code> - look back at existing commits | ||
+ | ***<code>git diff</code> - look at the difference between what's in the working directory and staging area, or between two commits | ||
+ | ***<code>git rm</code> - remove a file | ||
+ | ***<code>git mv</code> - move or rename a file | ||
+ | ***<code>git reset</code> - update the staging area, and perhaps working directory, with files from another commit (e.g., HEAD) | ||
+ | ***<code>git checkout</code> - switch to a branch or commit, or create, or get files from a branch/commit | ||
+ | |||
+ | * [[DPS909/OSD600 Winter 2019 Lab 3|Lab 3]] | ||
+ | |||
+ | == Week 5 == | ||
+ | |||
+ | * Finish Lab 3, [https://blog.humphd.org/browsing-open-source-projects/ Example: 3 projects I found recently] | ||
+ | ** Also, see [https://docs.brew.sh/Linuxbrew Linuxbrew for Windows 10] | ||
+ | * [[OSD & DPS909 Winter 2019 Release 0.2|Release 0.2]] | ||
+ | ** Lab 4 - first PR and Status update blog post (Friday Feb 15) | ||
+ | |||
+ | * Merging with git | ||
+ | ** Where <code>git branch</code> splits histories apart, <code>git merge</code> brings them back together | ||
+ | ** Understanding DIFFs and Patch files | ||
+ | *** <code>git diff</code>, <code>git show</code>, <code>git log -p</code>, etc. to show DIFFs | ||
+ | *** [https://github.com/filerjs/filer/pull/395 Pull Requests] also have links to get the raw [https://patch-diff.githubusercontent.com/raw/filerjs/filer/pull/395.diff .diff] and [https://patch-diff.githubusercontent.com/raw/filerjs/filer/pull/395.patch .patch] | ||
+ | *** [https://blog.humphd.org/vocamus-906/ How to read a DIFF file] | ||
+ | ** Types of Merges: Fast Forward, Recursive Merges are the most common | ||
+ | *** <code>--ff-only</code> 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 | ||
+ | **** <code>commit</code> your work if you can; or | ||
+ | **** <code>stash</code> (<code>git stash list</code>, <code>git stash show</code>, <code>git stash pop</code>) | ||
+ | *** checkout the branch you want to merge '''into''' | ||
+ | *** <code>git merge branch_to_merge_into_this_branch</code> | ||
+ | ** Various flags and commands to know: | ||
+ | *** <code>git merge --squash</code> | ||
+ | *** <code>git merge --abort</code> | ||
+ | *** <code>git merge --continue</code> | ||
+ | *** <code>git branch -d</code> | ||
+ | ** Merge Conflicts | ||
+ | *** Conflict markers <code><<<<<<<<<</code>, <code>=============</code>, <code>>>>>>>>>>>>></code> | ||
+ | ** [https://blog.humphd.org/fearless-merges/ Doing big merges in git] | ||
+ | |||
+ | == Week 6 == | ||
+ | |||
+ | * 0.2 Updates | ||
+ | ** Interesting projects you've found? | ||
+ | ** https://codetribute.mozilla.org/ | ||
+ | ** Update your Info on the 0.2 wiki with status blog post, PR(s) | ||
+ | |||
+ | * <code>git rebase branch</code> | ||
+ | ** 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 <code>git rebase --continue</code> or <code>git rebase --abort</code> to move forward after such a pause | ||
+ | *** use <code>git rebase --skip</code> 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 <code>git revert commit-sha</code> instead to apply an inverse commit | ||
+ | ** If you rebase a branch you've pushed (e.g., for a pull request), when you push, use <code>git push origin branch-name -f</code> (f means force and will overwrite) | ||
+ | ** <code>git rebase -i</code> 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 <code>HEAD~n</code> where n is how many commits back from HEAD to go | ||
+ | * <code>git cherry-pick SHA</code> to add a commit to the current branch |
Revision as of 14:32, 13 February 2019
Week 1
- Releases
- 4 releases, some with multiple bugs/PRs required
- 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
- Discussion/Readings
- Copyright (Copyright in Canada video)
- https://twitter.com/stan_sdcollins/status/1079395470731030528
- 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)
- Copyright (Copyright in Canada video)
- What is Open Source?
- First open technologies and projects we'll be using:
Week 2
- Release 0.1 Overview
- Due Wed Jan 30th
- node fs module vs. filer
- 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
- No License
- What can you do with code you find that has no license?
- what can I, can't I do?
- Public Domain
- SQLite, which is now used by literally everybody, see http://www.sqlite.org/famous.html
- Unlicense
- BSD License
- Family of Licenses, including 2-Clause BSD, 3-Clause BSD (aka New BDS), 4-Clause BSD
- "Why you should use a BSD style license for your Open Source Project"
- BSD Licenses code is usually compatible with other open/closed code, when you want to mix them.
- Example software projects licensed under the BSD License:
- Summary:
- You need to retain the license and copyright notice
- You can use it commercially or non-commercially (privately)
- You can distribute it freely
- You can modify it freely
- Open Source and Code Reading
- truncate
-
echo "data" > file
-
> file
-
-
fs.truncate()
- A great blog doing something similar: Deep Dive on the node fs module and fs.access() by Safia Abdalla
- truncate
Week 3
- Readings/Resources
- Filing and Fixing a bug: a cookbook approach
- set up git and GitHub
- https://help.github.com/ has lots of great articles to help you. You can also view video guides or read the printed guides
- setup your username in git
- setup your email address in git
- specify which editor git should use, for example you can use vscode
- setup line endings (CRLF vs. LF) in git, extra notes for Windows users
- setup ssh keys for GitHub
- In GitHub, create a fork of the repo you want to work on
- On your computer, clone your forked repo
- On your computer, add a remote named "upstream" for the original repo (vs. your fork)
- On GitHub, find or create an Issue for the change you want to make
- On your computer, create and checkout a branch for your work, e.g., issue-1234 for Issue #1234
- On your computer, make code changes, test them, add, and commit on your branch. Repeat as necessary.
- On your computer, push your changes (commits) to your fork (origin)
- On GitHub, create a Pull Request for your changes to get sent to the upstream repo
- On your computer, fix any problems pointed out by your reviewer(s), add the file(s), commit, and push again to update your pull request
- set up git and GitHub
- Real world example, fixing a bug in Filer
- https://github.com/filerjs/filer/issues/628 - Add tests for fs.writeFile to increase coverage
Week 4
- Learning Licenses: MIT
- MIT License
- The MIT License, Line by Line
- One of the most widely used licenses in Open Source
- Like the BSD License, nothing about patents (created before software was patentable in the US)
- Example software projects licensed under the BSD License:
- More Git
- Understanding how git works
- SHAs
- commits, trees, blobs
- branches
- Working Directory vs. Staging Area vs. HEAD
- Git Walkthrough Part I
- Git Walkthrough Part II
- Some basic git commands you should make sure you know how to use:
git clone
- clone an existing repository (i.e., one you've forked on GitHub)git status
- check what's happening with your repo, working directory, branch infogit add
- add a file, files, or folder(s) of file(s)git commit
- commit changes in the staging areagit log
- look back at existing commitsgit diff
- look at the difference between what's in the working directory and staging area, or between two commitsgit rm
- remove a filegit mv
- move or rename a filegit reset
- update the staging area, and perhaps working directory, with files from another commit (e.g., HEAD)git checkout
- switch to a branch or commit, or create, or get files from a branch/commit
- Understanding how git works
Week 5
- Finish Lab 3, Example: 3 projects I found recently
- Also, see Linuxbrew for Windows 10
- Release 0.2
- Lab 4 - first PR and Status update blog post (Friday Feb 15)
- Merging with git
- Where
git branch
splits histories apart,git merge
brings them back together - Understanding DIFFs and Patch files
-
git diff
,git show
,git log -p
, etc. to show DIFFs - Pull Requests also have links to get the raw .diff and .patch
- How to read a DIFF file
-
- 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
- start with a clean working directory
- Various flags and commands to know:
-
git merge --squash
-
git merge --abort
-
git merge --continue
-
git branch -d
-
- Merge Conflicts
- Conflict markers
<<<<<<<<<
,=============
,>>>>>>>>>>>>
- Conflict markers
- Doing big merges in git
- Where
Week 6
- 0.2 Updates
- Interesting projects you've found?
- https://codetribute.mozilla.org/
- Update your Info on the 0.2 wiki with status blog post, PR(s)
-
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
orgit 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