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)
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
git diff, git show, git log -p, etc. to show DIFFs
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
Continue working on 0.2
Discussion of any issues/questions you have
End of Week 2 Stats:
+15,819/-8,733 LOC in 414 files across 116 PRs to 89 Repos. 62 merged (53%) already
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
Cross-platform, high performance, in-memory, key/value, data structure database server. Written in mostly in C, as well as Tcl and Lua, with front-ends in just about every language and platform.
"[W]riting comments is of paramount importance in order to produce good code, that is maintainable in the long run and understandable by others and by the authors during modifications and debugging activities."
"So comments can be, for me, a tool for lowering the cognitive load of the reader."
His YouTube channel has more video discussions of the code in Redis
PRs must have a title that explains the fix, links to an Issue #
PRs must have a full description. If this is UI code, show a screenshot, or explain the fix, talk about how to review it, how to test it, what's not done, what's going to happen in further PRs, etc.
All PRs must pass CI: eslint, stylelint, unit tests
Don't let people land code with unrelated commits (e.g., merges with master)
Ask people to update their master with upstream, and rebase
Don't let people land code with changes to unrelated lines/files (e.g., package.json, whitespace changes)
Make sure one PR doesn't undo the work of another (e.g., bad merge, erasing existing code)
Ask yourself how we'll test every piece of code we take. We need to be able to trust it going forward.
Make sure your PRs, Issues, and Blog posts are posted on the 0.3 page. I'll mark 0.3 and 0.4 together, in case you're still cleaning up work from the past week (you have time).
Over 100 Pull Requests, 67% are already merged
476 commits to 325 files totaling more than 20K lines of code edited/added
Top Repos: Telescope! followed by Microsoft, Mozilla, Facebook, Uber, Zeit, Elastic, GatsbyJS, .NET, and 100 others