Difference between revisions of "DPS909 & OSD600 Fall 2018"
(→Week 5) |
|||
Line 200: | Line 200: | ||
*** Conflict markers <code><<<<<<<<<</code>, <code>=============</code>, <code>>>>>>>>>>>>></code> | *** Conflict markers <code><<<<<<<<<</code>, <code>=============</code>, <code>>>>>>>>>>>>></code> | ||
** [https://blog.humphd.org/fearless-merges/ Doing big merges in git] | ** [https://blog.humphd.org/fearless-merges/ Doing big merges in git] | ||
+ | |||
+ | == Week 6 == | ||
+ | |||
+ | * Hacktoberfest Updates | ||
+ | ** Add any interesting projects you find/work on to [https://github.com/humphd/hacktoberfest-at-seneca-2018/wiki/Interesting-Open-Source-Projects this list on the wiki] | ||
+ | ** Update your Info on the [https://github.com/humphd/hacktoberfest-at-seneca-2018/wiki/Student-Submissions submissions wiki page] by Monday: | ||
+ | *** Add your Name beside your GitHub username | ||
+ | *** New Pull Request | ||
+ | *** New Blog Post | ||
+ | *** Any Issues you're working on | ||
+ | ** [https://github.com/humphd/hacktoberfest-at-seneca-2018/blob/master/data/week01.md Week 1 Summary] | ||
+ | |||
+ | * <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 | ||
+ | ** 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 | ||
+ | |||
+ | * PRs needing a Rebase | ||
+ | ** https://github.com/filerjs/filer/pull/496 | ||
+ | ** https://github.com/filerjs/filer/pull/437 | ||
+ | ** https://github.com/filerjs/filer/pull/439 | ||
+ | ** https://github.com/filerjs/filer/pull/468 | ||
+ | ** https://github.com/filerjs/filer/pull/545 |
Revision as of 15:25, 10 October 2018
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)
- 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)
- What is Open Source?
- Microsoft buys GitHub for 7.5 Billion - "We're all in on open source"
- Julia Evans, "How to teach yourself hard things"
- Copyright (Copyright in Canada video)
- First open technologies and projects we'll be using:
Week 2
- Release 0.1 Overview
- Due Friday Sept 28th
- node.js
- node fs module vs. filer
- synchronous vs. asynchronous functions in JavaScript
- node's callback function pattern vs. Promises
- 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
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
- 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 examples:
- Filing, Fixing a bug in Filer
- Adding a new Feature, Tests, and Docs to Filer - support node's new recursive fs.mkdir in Filer
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
- 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
Week 5
- Release 0.2: Hacktoberfest
- For Tuesday October 9th (Lab 3)
- First (of 5) PR completed with a Blog Post
- Submit via https://github.com/humphd/hacktoberfest-at-seneca-2018/wiki/Student-Submissions
- Add projects that you think are good for other students to https://github.com/humphd/hacktoberfest-at-seneca-2018/wiki/Interesting-Open-Source-Projects
- For Tuesday October 9th (Lab 3)
- 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
- Hacktoberfest Updates
- Add any interesting projects you find/work on to this list on the wiki
- Update your Info on the submissions wiki page by Monday:
- Add your Name beside your GitHub username
- New Pull Request
- New Blog Post
- Any Issues you're working on
- Week 1 Summary
-
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
- 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