A "course plan" for a very informal set of videos, discussions, and resources for getting better at using Git and GitHub at Needmore.

git-and-github-classes.md

Git and GitHub Learning at Needmore

This is "course plan" for a very informal set of videos, discussions, and resources for getting better at using Git and GitHub at Needmore. We're spending an hour a day, one day at a time.

Largely, we're basing our conversations on the Lynda.com videos which are excellent. Our development process in our Notebook is obviously essential reading.

Day 1: Monday, February 24

1. Intro: Why are we doing this? (To have a solid foundation, ensure we're using the same process, and answer lingering questions)
2. Chapter 4: Git Concepts and Architecture
3. Chapter 5: Making Changes to Files
4. Discussion: Pull Requests for Web Developers

Notes on the topic of pull requests, please do read more here...

[...] In short, you're expected to branch often, keep your branches pushed to the server, use master to represent exactly what is currently on the production server, and use the hell out of pull requests and a staging server.

Day 2: Tuesday, February 25

1. Chapter 7: Undoing Changes

Day 3: Thursday, February 27

1. Chapter 8: Ignoring Files
2. Chapter 9: Navigating the Commit Tree
3. Discussion: Two Types of Issues (bug vs. feature), and our issue process (screenshot or staging? assignee and notification? useful labels? see here)

[...] Even though you can mention other people in an issue, whoever the issue is assigned to bears sole responsibility for that issue's next steps. When reassigning an issue, the person to whom the issue is being assigned should be notified. There seems to be no good mechnism for being notified that you're being assigned an issue. [...]

Day 4: Friday, February 28

1. Chapter 10: Branching
2. Chapter 11: Merging Branches
3. Discussion: Git Flow, GitHub Flow, and other common workflows
4. Or maybe just: Better commit messages

Day 5: Tuesday, March 4

1. Chapter 12: Stashing Changes
2. Discussion: Always strive for Atomic Commits:

When using a revision control systems a common convention is to use small commits. These are sometimes referred to as atomic commits as they (ideally) only affect a single aspect of the system. These atomic commits allow for greater understandability, less effort to roll back changes, easier bug identification. [...]

Day 6: Thursday, March 6

1. Chapter 13: Remotes

Day 7: Monday, March 10

1. Chapter 13: Remotes, part 2
2. Discussion: Read Developing at Needmore and share your thoughts, so that we're all on the same page going forward.
3. Questions about Pull Requests?
4. Scrum...

Day 8:

1. Chapter 14: Tools and Next Steps