Deepak Dinakaran Feedback

Recording

Topic: Introduction to GitHub, Getting Ready for Class, & Getting Started

👍 Starting out, nice overview of what to expect and opening it up for questions
👍 Taking feedback quickly from participants, helping answer questions about "what is git".
- Maybe instead of getting too deep into detail, give a shorter answer, and let them know we'll cover more throughout the next few days. The more quickly you can get "hands on keyboard" with interaction, the better.
👍 You're right, Git (the free, open source version control system) has existed for about 25+ years. GitHub came about as a way to manage remote repositories as a platform for collaboration. The first commit on GitHub.com was about 10 years ago.
👍 Four commands with network interaction: git clone, git fetch, git pull, and git push.
👍 Nice showing git --version, and advising to have version 2+. At this point, it might be a good idea to press Cmd + + to make the window and the text larger and more legible.
👍 A few minutes in, after having people check their git versions, you stop and review the content and ask about any questions. Very nice, to help people from getting behind and giving them an opportunity to share comments or questions. 💯
I'm guessing you went to create a repository because we didn't have one for class, but generally we like to have the repository already made so it can be a quick transition to adding collaborators and getting the developers working on their own machines.
The explanation of repositories went on for quite a while, and there were lots of good questions. You did a good job of answering the questions, but I might consider saving the questions for later. Maybe something like writing them in an issue, writing them on the board, or simply saying "We are going to cover that later, but right now I want to focus on getting started with our project" to keep the class on track.
I noticed a slack notification. 😄 When teaching, be sure the screen is clear of distractions. Notifications, browser tabs, bookmarks, chrome extensions, toolbar - everything that could be distracting.

Topic: GitHub Flow

Describing the GitHub Flow, make sure the vocabulary is exact. When describing a new branch, you said "at this time you pull a revision". Really, at that point you would create a new branch. If or when you pull doesn't have anything to do directly with the 5 steps of the GitHub flow; one could pull at any time throughout the process.
I wouldn't use the GitHub Flow visual to explain forking. Good job on coaching them to hold off on Forking for now - we will cover forking later (and use different visuals that are a little more precise).
👍 GREAT job going back to the GitHub flow to relate what you're doing at any step along the way. Keep doing that as we move on through all of the Git and GitHub concepts, and when you get questions! 👏
SHA 1 Hash = 40 characters, not 41 😊
It seems at this point it's a Demo, not an interactive class. 30 minutes in, are you wanting the students to be following along with you?
👍 I really like it when you pointed out how collaborators and permissions are handled on GHE. That immediately relates it to the developers' current understanding.
Again, make sure vocabulary is exact - you said "Now it is time to check out the code" when I think you meant "clone".
To create the directory, you went to Finder. I would recommend doing this via CLI if possible, since the participants might be on different operating systems.
You used a command git hist - what is this command? It worked for you, so maybe is it an alias?
👍 Nice job knowing when to show the visuals, pulling up the config page.
Asking participants if you are going with their pace, too slow/too fast 👍

Topic: Working Locally

👍 Explanations for concepts of 2 stage commits are very strong
It's a little unclear if it's a "demo" or if they should be following along on their own machines
👍 Still very nice job answering questions
👍 Great job going back to visual of GitHub Flow while explaining and re-explaining concepts of commits
👍 At about 54 minutes, you changed the pace and said something to the effect of "I know we've been going slow, we're going to move on to the next bit". Nice job steering the class back on track
In general, the pace is quite slow. However, whatever speed is necessary to keep the class engaged is the right speed, so it might be perfect for this group.

Topic: Collaborating on Code

👍 Workflow conversations took a while, but I think it's because of existing questions from the training before. I think it was good to get to a common understanding. In a 'real life' teaching scenario, I would probably try to hold off on this conversation until a break time so it doesn't stop the class unless every student is engaged. Since all were engaged here, I think you did the right thing by continuing with the workflow conversation.
👍 "This tells a story" while describing pull request
👍 Having the reviewer show the screen to show their perspective in the workflow
To leave a review, click "files changed" to see the changes introduced in the Pull Request. Generally I lead people to "files changed" for pull requests always, including when they're making a review.
I think it will be easier to teach the flow when using the class activities, and when you have a bit more practice. :smile:
The merge conflict was a bit confusing this early in the class. Do you know why it happened? How can you be sure to avoid it in the future?

In general, very nice job. To continue improving, I recommend focusing on: 1) making it clear when participants should follow along
2) being cognizant of timing and pacing

Recording URL: https://vimeo.com/242530428/520f4a18ad

Topic: Editing Files on GitHub

I think you may have forgotten this section

Topic: Merging Pull Requests

👍 Starting off the class with brief overview of what was covered last time
👍 Starting off with an overview of what will be covered during the day
👍 During the merge, you specify that participants should sit back and watch as you explain a concept.
Generally, we avoid discussing too much detail of the types of merge on GitHub during this first walkthrough. We typically save it until later, when we understand how Git history is created, and after talking about Rebase we can come back to the UI. I think the amount of time you spent was good, but bringing it up tends to bring up lots of questions that we have to shut down until days later.
👍 Using visualization tool to show concepts :tada:
While describing that the merge happened, you mention the "parent" repository. I think you probably meant "remote" repository. Parent can be a confusing term here, because it could also represent a Fork and Pull workflow. In this case, we would call the repository on GitHub the "remote".
👍 Deleting the branch on the remote
👍 When discussing branch deletion, checking with participants "will it have an error, or will it be fine?" Nice, having them try to predict! It keeps them engaged and helps solidify understanding. 👏🏻
👍 I like writing out git pull = git fetch + git merge.
git fetch ~~will pull down all changes from parent repository~~ will update the remote tracking branches from the remote repository.
git merge will merge it to the local repository but only for the branch you are currently checked out to. "If you have any changes in your other branches, it will basically merge it onto yours" <- Not correct, this will only happen for the branch you're currently checked out to. :smile: (Later, I see Saeed helps clarify and you make sure to clear this up. Good job.)
👍 git branch --merged Very good description.
Again, make sure the vocabulary is "remote" repository, not "parent" repository. It's a small detail but it makes a difference, especially later on.
I'm not quite sure what you are meaning about needing capital D. In this case, you did not require a capital D. Since the branch had no original work compared to master, you were able to delete with the lowercase -d option. If you need -D, Git will post that into the terminal so you know that you need it. I don't think it has anything to do with the remote tracking branch.
👍 Discussing --prune. Good description and clean example.
The configuration for pruning (git config --global fetch.prune true) is recommended, but I don't set it as a trainer so I can demo the behavior with default configurations.

Topic: Local History

👍 Describing what git log is.
Notice: If you're demoing this, (depending on your group) and others are following along, expect questions about how to get out of VI. :smile:
At this point, you've only demoed. You've done a good job of clarifying what should be happening, but remember, in our activities to this point almost everything is meant to be hands on for the participants.
- Participants will be more engaged and paying attention to the content
- Participants are more likely to remember what was discussed when they acted on it instead of only observing
👍 Very nice job in terms of sticking to the content. It's clear that you either have studied a lot, or you have the book right next to you. Very smooth.
I do still wish your text window was larger. On my machine, if I'm following along, the video is much smaller, so by the time it fits onto my screen your font looks quite small. It might feel very large for you on your machine, but it will be easier for those trying to follow along.

Topic: Streamlining Workflow with Alias

👍 Nice job explaining and demoing concept of aliases
👍 Reminding participants that aliases are set the same way all configs are, and reminding participants about --global
You can remove a setting with --unset for a configuration, like git config --global --unset alias.lol
Aliases set with --local will be stored in the .gitconfig file within the shared repository, not the .git file.
👍👍👍 Asking what an alias would do - you had to repeat the question! I always think of this as a good thing. It means that the participant would have missed what you said entirely, for whatever reason, but by asking them a direct question, they realized they didn't know what you said, and makes sure everyone's attention is in the same place. Always do as much of this as possible.

Topic: Resolving Merge Conflicts

Again you say "I'm not going through the activity itself". Why not? This is the time to practice. Even if you don't have the participants to do it, pretending you do and walking through the steps is valuable. Otherwise, the first time you actually go through the content would be with a group of students!
For this activity, even outside of the activity, there is a time to talk about what merge conflicts are. I typically discuss:
- How centralized version control is different than distributed version control
- What circumstances can create a merge conflict
- How branches look (with visualization tool)

Topic: Day 2 Merge Conflict Practice

You say that you've forked "for us". Does this mean that you have created a fork for Saeed as well? It looks like you've only created one for yourself, which means this is a demo, not an interactive training.
Your fork would be at /GitHub.com/deepakarchinnova/github-games. You went back to the githubschool repository from our group class. A fork changes the ownership and creates an exact copy, so you'd look under your own account.
You described that there are activities, and that'd we'd resolve merge conflicts, but you didn't actually show any resolving merge conflicts or explain what merge conflicts are.

General Notes

In general, much better job with saying if users should be participating or not. However, I heard you say several times "if this were a real class". Instead of saying that and describing, please go ahead and actually do what you would do. Pretend it is a real class.
I missed both sections "Editing on GitHub" and "Merge Conflicts". I think you could do better here. Depending on the videos for the next few days, I may ask you to re-record those segments.
Very nice job on many subjects! Improved from last video. :smile:

I missed both sections "Editing on GitHub" and "Merge Conflicts". I think you could do better here. Depending on the videos for the next few days, I may ask you to re-record those segments.

😄 Thanks for letting me know. Editing on GitHub I forgot this topic totally. I can revisit this for sure. Merge Conflicts we ran out of time as I believe I was eating into both of our working time. We are working on post work timings but materializing it is rather a difficult affair. If you have any suggestions for this I would love to hear it.

We are working on post work timings but materializing it is rather a difficult affair. If you have any suggestions for this I would love to hear it.

I'm not sure what you mean. Can you please clarify?

Sure. Our group tried to run the teachback in the morning but is not working well as expected. So we switched the time to the evening i.e. after work timing, which is also not working super well as one would be free but the other would not. Mostly it is coordination and unavailability but everyone is super cooperative. We are working on it, but I thought I would mention it to you. I think the only solution is to be patient and await. Hope it is clear now. 😄

Ah, I see @deepakarchinnova. I'm sorry to hear that scheduling is challenging. Unfortunately I don't have any recommendations specifically, but I will say that if it becomes too burdensome to find shared availability, you can feel free to join the room and share your screen as if you were teaching. It will still record with 1 person, and though you won't have an audience, I will still review your videos. Good luck! I'm really enjoying your videos so far!

Recording

Topic: Workflow Review

👍 Starting off by reviewing what was already covered
👍 Using the visuals in the manual to emphasize the points you're talking about
👍 Your browser window is taking up the whole screen, no distractions
👍 :100: Setting expectation that they should follow along and participate
👍 Setting expectations of what will be covered today
👍 Pace is very easy to follow
👍 When typing in terminal, text is large enough to see clearly
👍 Very clear explanation of what is happening at each step

Topic: Git Bisect

👍 Showing image from manual while explaining bisect
👍 Accurate explanations of how git bisect is working
👍 Showing that with git status, you are still not finished with the bisect until you type git bisect reset

Topic: Reverting Commits

When describing how commits are made, you use the word "head" to describe a commit ID. This isn't true - HEAD is a pointer, that represents your local working directory.
👍 Generally accurate description, showing the images from manual to help you describe
This info was very accurate, but I may try to spend a little bit less time on the conceptual aspect and move more quickly into the 'hands on' section of revert. We get to changing history, like the examples you get into, on day four. :blush:
👍 Using the visualization tool
"A revert is an indirect commit" - A revert is a direct commit, there's nothing indirect about it.
👍 Asking the crowd (even though they're pretend) "will this work?" Keep doing more of this! :100:
I noticed as you pushed that you completed the revert on the branch. This is slightly different than we have in the curriculum, but it is still okay.
The pull request step went a little quick, make sure that it's clear that participants know they should follow along here. I don't recall having been told to follow along since the beginning, which was 40 minutes and several topics ago.

Topic: Helpful Git Commands

👍 Describing what we will do in this section
👍 Reviewing what -b flag means, even though it's not the first time you've used it. Sometimes people take this for granted and don't give the explanation, but I'm very glad you do!
👍 As you type, you're doing a good job of speaking and describing what you are typing
It will just take a small tweak to your language to make it feel hands on. Use "we" instead of "I". Some examples:
- You say: "I'm going to look into my editor and see if everything is intact. I think it looks good."
- Instead, say: "Open up your text editor to see if everything is intact. Mine looks good. Does yours?"
- You say: "The first thing that I'm going to do over here, I'm going to make a change in line 9. This is where texture.jpg is being referenced." Instead, say: "First, we are going to change line 9. This is where texture.jpg is being referenced. Find line 9 now."
- You say: "I'm going to slow down the game, plus I'm going to restructure the repository."
- Instead, say: "We are going to slow down our games, plus we're going to restructure the repository."
👍 Strategic, exact explanation of commands add -p and mv.
👍 Showing visuals of working and staging directory to help solidify concepts
The pacing here feels a little slow, but I think with checks worked in to ask participants if they're able to follow along, it would be almost perfect
👍 Concept of atomic commit
👍 Showing commit history in pull request

Topic: Viewing Local Changes

Typically, I like to show git diff while I am in the middle of git add -p, because there is a lot to compare.
That being said, you did a great job of setting up an example quickly to show the functionality of git diff.
👍 :100: I really like how you go back and forth between the terminal and the browser window. Very smooth transitions! It's very easy to follow, it feels seamless.

Topic: Workflow Discussion

👍 This is a tricky session. It's generally led by the questions and context clues given by the participants. You did a great job, considering you had no audience!
👍 Focus on GitHub Flow, having exceptions circle back to main flow

Things to keep doing

:100: Asking participants to predict what will happen in any situation, then waiting for an answer
:100: Keeping the screen clutter-free, large text, with pertinent visuals
:100: Telling/asking participants to follow along

👋 @brianamarie thank you for the precise feedback. Appreciate it alot and you are doing an amazing job, otherwise I wouldn't recognize my mistakes/imperfections. Can you please acknowledge if you have received day-4 as my mac hung up on me and had to restart. For day-4 I think you might have 2 recordings. This is so I can plan ahead for the next steps.

Hi @deepakarchinnova! Yes, I have received all of the recordings. I'm watching the first part of day 4 right now. So far, they're all good. I think the one thing you have left is the post-test. 👍

Recording Part 1

Recording Part 2

Topic: Tags & Releases

👍 Reviewing what was covered, saying what will be covered, having time for questions
👍 Specifying those who want to follow along can, and some can just watch, it's ok either way
👍 Pausing and asking "can anyone tell me where this is?"
I think this section might have gone on a little too long. You may want to choose to spend less time on tags depending on the group you're teaching. Sometimes, a class will have a lot of interest in tags and have a lot of questions. Sometimes, they'll have no interest and they'll just be fine knowing they exist and moving on.

Topic: Create a Local repo

👍 Asking specifically for people to follow along :balloon:
👍 Asking participants to let you know if your pace isn't right
👍 easy to follow pace while setting up local repository
👍 Asking participants "has everyone followed along with me so far?" :100:

Topic: Fixing Commit Mistakes

👍 Good explanation of what git commit --amend can do
👍 Doing git status very frequently to show how exactly each command affects the working directory and staging area

Topic: Rewriting History with Git Reset

👍 Posing questions to the participants about if they've used git reset
I like to use the visualization tool when describing the core functionality of git reset. However, even though you did not use it, I thought you did a very nice job.
👍 Outlining practical examples of when each type of git reset would be used
👍 Accurate descriptions of three types of reset
👍 Noting that participants could follow along or just watch
👍 You are very clear that git reset is dangerous, and is safe to use only locally
👍 Continuing to ask participants what they expect to happen
👍 You wrote on the screen that it was break time, so people who looked away would still have an idea of what is going on

Topic: Cherry Picking

git cherry-pick is another one example where using the visualization tool can be quite helpful
👍 Great definition and review of what the reflog is
👍 Clear explanation of git cherry-pick
👍 Reiterating that any command that changes the commit ID needs to stay local
👍 Clear example of git reset going forward
👍 Very good explanations of what can happen in terms of merge conflicts during cherry-picks

Topic: Merge Strategies

👍 Using visualization tool. You could go even further to show the merges
👍 Explaining fast forward merge vs recursive merge, why people would want each, before getting into details of git rebase
👍 The example was accurate for going through git rebase and git rebase -i. I think going through with participants will be helpful, and actually make it easier, because their questions will help guide you in terms of how much time to spend on each part of the concept.

Great job!!! :tada:

Congratulations, @deepakarchinnova! I think you've done a fantastic job. As soon as you complete the post-test, I will invite you to our Slack room and send you the training manual. I've very much enjoyed watching your videos, and I appreciate all of the time and effort you've put into making them so fantastic. GitHub is lucky to have you as a partner!

👋 @brianamarie , I was able to complete the post test, but I have some queries:

The 'add -p' did not work the way it did for the class repository. May be we can have a session for this via https://github.youcanbook.me/index.jsp

The 'add -p' did not work the way it did for the class repository. May be we can have a session for this via https://github.youcanbook.me/index.jsp

You're right - you are not the first one to bring this up. Do you know why it doesn't work? 😉 Git's similarity index looks at the whole file, and since the file is small, the "blobs" aren't considered far enough apart to be different changes. 👍 That's really all there is to it. 😄

githubschool / Nov-6