recet feedback

[lonix]

A Bit unstructured language, mostly because non english native speaker.

• Git config missunderstanding.
• Not clear on what was git vs github.

[lonix]

Day 2

Better in so many ways, you seemed to be a bit more comfortable with the content this time around, and i dont doubt that with a bit of pratice, youll nail it!

[brianamarie]

Recording

Topic: Introduction

• 👍 Nice job walking the participants through how to check for git. One of the challenges is making a difference between a demo and letting participants know they should be following along, and right off the bat, you make it very clear they should be following along.
• 👍 Accurate account of the difference between Git and GitHub, and nice amount of time spent on it
  • Git is a distributed version control system.
  • GitHub uses Git, so it isn't its own version control system, but it is where the remote is stored in distributed version control.
  • Examples of centralized version control systems are Subversion, TFS, ClearCase, and CVS.
• 👍 Nice walkthrough of the GitHub interface
  • Project boards aren't where one would accept pull requests; a project board is where issues and pull requests can be organized.

Topic: GitHub Flow

• Discussing the GitHub flow is one of the key parts of the training. I think spending some time practicing this portion will be very helpful for you. :smile:
• 👍 Stopping to ask participants if they have questions

Topic: Branching with Git

• Question you got about why is Git lightweight: Git uses pointers, so all branches are just 40 character pointers. Instead of creating new files like in centralized version control, the pointers allow the repository to be very lightweight.
• In this section, have the participants follow along. Everyone should create a new branch in the class repository during this section.

Topic: Local Git Configs

• You speak accurately about the configurations, but I get the feeling you don't feel totally comfortable with the content.
• When showing your command prompt, can you make it larger? (Cntrl + +)
• 👍 You showed the demo for setting configurations, but maybe go slower. It went so quickly, I don't know if participants in a full class would have been able to follow or would have known tht they were supposed to

Topic: Working Locally with Git

• 👍 Demoing through the git clone
• Stian mentions a good point to use another command prompt. Good point - find a terminal that works for you. :smile: You handled the feedback very well! Acknowledged, said you'd improve, then jumped right back into the content.
• You mentioned you're "jumping the interactive parts". Why? Personally, I think those are the most difficult parts, so they're very important to practice. :wink:
• 👍 When starting the commit process, showing the visual for two stage commit. If you can find or create an interacive tool, that would be even better.
• Ah! You mentioned "or just put git add . and it will put all changes to the staged"! Please do not advise this practice, it is not advisable for several reasons. :bowtie:
  • Developers can accidentally commit binary files
  • This habit will lead to large, non-atomic commits

Topic: Collaborating on Code

• If this were an interactive teachback, how would you know everyone was able to push?
• I think some more time with Git and GitHub will help this part go smoothly
• 👍 When there was a hiccup and the result wasn't what you expected, it was the right thing to go back to the manual.

General Notes

Recet, great job! I know this was 'uncharted territory' and it's on a new tool as well! All in all, you did a great job - this is hard to do for anyone, even after doing it many times. I can't wait to see your next rounds of teachbacks! Nice.

[brianamarie]

Recording

Topic: Merging Pull Requests

• 👍 Starting off by reviewing where we just ended, and what we're about to do. This is always a good thing to do, even if you're not at the beginning of a day. Nice!
• 👍 While showing pull request, before merging, you described what a merge actually is.
  • You're showing your pull request. Are participants also meant to be looking at your branch, or should they be looking at their own? Make sure you are explicit about this so people know what to do.
• 👍 Discussing different ways teams can decide who merges
• 👍 Discussing different "types" of merges on GitHub.com. We don't always get into this in too much detail on the first day since we'll cover Rebase and Squash on day 4, but if they're going to be covered this early it's good to do it briefly as you did.
• 👍 Pacing of showing the steps is very clear and easy to follow up through clicking "merge"
• Were participants meant to merge their branches now too? Make sure it's very clear by saying something like "Go ahead and merge your pull request now".
• When you went back to the local repository to pull and clean up the branches, it was a little unclear what you were doing and why you were doing it.
• The "branch cleanup" time is a good time to ask questions to the group to check for understanding. If you aren't checking with them, how do you know they are understanding what you're explaining? I like to use questions like "what do you expect?" or "Why is/isn't this showing me what I see on the remote/other branch?". The pause can be awkward if it's a quiet group, but:
  • The time will cause everyone to try and think of an answer, even if they aren't speaking up. Otherwise they may just wait and passively let you tell them the answer.
  • A longer pause will let them know you actually do expect it to be an interactive class instead of a demo or lecture
• Deleting branches is a good time to discuss the concept of "remote tracking branches". Remember, this is quite a difficult concept that is very different from other version control systems.
• 👍 Showing the fetch.prune alias without actually running the command :100:

Topic: Local History

• 👍 Explaining what git log does and showing the different flags in the manual
• 👍 Showing git-scm documentation
• Make sure to slow down for questions and to check if others are able to follow along
• Terminal can be zoomed in with Cntrl + +. If it takes up the whole screen and is bigger font, everyone will be able to follow along more easily. :smile:

Topic: Streamlining with Aliases

• 👍 Accurate demo
• 👍 Great point that local configurations will be shared with other repository collaborators

Topic: Resolving Merge Conflicts

• As with all things Git, the "why" is very important. When going through the merge conflict activities, first establish why merge conflicts happen.
  • I like to use the visualization tool to show a merge, and ask students what they think would happen if there were changes on both branches to the same file?
  • This is why centralized version control uses "checkout" to block files from being changed - to avoid merge conflicts
  • Git handles merge conflicts in a way that gives power to the developer and avoids overwritten code and lost work
  • After I wrote all of that out, you DID explain it. :clap: Nice job. 👍

General Feedback

• 👍 Already huge improvements from the last video. Nice job! It went smoothly, your presentation was generally easy to follow.
• I think the biggest place you could improve is making the difference between a demo and an interactive class clear. If I was in this presentation, would you have known if I was following along? How would I have known I should be following along? When in doubt, focus on the three main steps of:
  • Give instruction (Tell them what to do)
  • Observe (Are they doing what you told them to do?)
  • Give feedback (Tell them if they did the thing you asked them to do, in as specific of terms as possible)
• Nice work!

[brianamarie]

Post test complete ✔️