Saeed Feedback

[brianamarie]

Recording

@SaeedAlbarhami, I didn't see an existing issue for feedback for the teachbacks, so I opened this issue. The feedback here is meant to be constructive and actionable. Please let me know if there are any questions about what you covered in your Teachback, the feedback I'm leaving here, or anything else. I look forward to seeing your next teachback videos! 😄

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

• 👍 Starting out with an introduction of who you are and what you're going to be talking about
• I notice you have your notes on the screen. If possible, have those notes on a separate screen, or don't share when you have the notes up in the future. However, I'm glad that you had notes, because your presentation started very smoothly. :smile:

Topic: GitHub Flow

• 👍 Using GitHub flow visual
• A pull request is a comparison between two branches. The concept of pull request is very new and can be a little strange to new users, so make sure to spend a little more time on this concept.
• 👍 Nice job answering questions! When you weren't sure about the question, you asked for more clarification.
• The questions that came up were great, and I'm glad that it was discussed. However, when you're teaching, make sure you are aware of timing and keeping the class topics on track with your plan.
• The squirrel represents "deploy", but more accurately, that can be representing "integrations". Integrations like CI, testing, or deploying to testing environment all are included.

Topic: Branching

• In this curriculum, we have the repository on the remote and create a branch here.
• Make sure it's clear that participants know if they're meant to follow along, or if it's only a demo. When you go through the second time, you create a branch but if I were a participant, I would only be watching when I think you want me to be following along.

Topic: Local Git Configs

• When discussing configurations, it's a good time to show the visual in the manual and discuss the scopes
• Make sure it's clear that others should be setting the configurations also
• When you're showing your command prompt, make sure it's easy for others to see and there aren't lots of distractions on the screen. Maybe making the terminal take up the whole screen and have larger text, with Cntrl + +. I'd hate for participants to be looking at the files on your desktop instead of what you want them to be looking at. :wink:

Topic: Working Locally

• You created a new repository locally, instead of cloning. It seems that we haven't had a chance to look at GitHub.com at all yet. Is this intentional? If so, what's the reasoning for this? I see that you're using the API to create the repository on GitHub.com. I recommend against this for many reasons.
  • As this is a class, we want it to be easy for participants to follow along interactively. Are they also expected to use the API even though the API is out of scope for the rest of this class?
  • We will cover initializing locally, but that doesn't come until day 4. We recommend creating the repository on GitHub.com and then cloning as a simpler workflow all the time, so we don't discuss git init until much later.
• When discussing the "two step commit", I find it useful to show some kind of visual. The differences between the working directory and the staging area are conceptually quite difficult, yet very important, so I recommend using as many tools as possible to convey this concept.
• You recommened using git add . or git add --all. :bowtie: Please avoid these commands - we don't even mention them until the second day if possible - because they can be harmful in several ways.
  • Users can accidentally stage and commit binary files
  • This encourages bulkier commits, instead of atomic commits
• 👍 Discussing "why" the staging area is necessary
• Second time through: The flow is good, but I still think that it could be improved drastically by:
  • Showing visuals
  • Letting participants know if they should follow along
  • Asking participants how they're doing, if they're keeping up, etc., so you can gauge if they are on track also.
• When you're pushing a new branch, you're correct about setting an upstream. git push -u origin BRANCHNAME. However, in the video, you are trying to push to master. You would want to push to a new branch with your own name so you can continue the GitHub flow: git push -u origin mysecondbranch.
  • git push = network command pushing changes to the remote
  • -u = short for --set-upstream, creates the relationship between the remote branch and your local branch so you won't need to enter this information again
  • origin = tells Git which remote to push the changes to (you can see all remotes with git remote -v)
  • mysecondbranch = the name of the branch you want to create on the remote

Topic: Collaborating On Code

• 👍 Walking through the steps of opening a pull request on GitHub
• Before teaching, it's vital to know all of the features well enough to explain and demo, like Projects and Features.
• During the middle of creating a pull request, you jumped over to creating a new repository. This was very confusing and would be incredibly confusing for a participant trying to follow along in your class.
• In addition to creating the pull request, it's very important to discuss the concept of what a pull request is, when a pull request would be used, and what participants should expect to see when they are creating and interacting with Pull Requests.
  • A pull request is the powerhouse of collaboration on GitHub
  • A pull request is a comparison between two branches where developers propose changes, run tests with integrations, give code review, and so much more.
  • Make sure to show the "Conversation", "Commits", and "Files changed" tabs.
• You go into branch protection quite early, before we've gotten the picture of what Pull Requests are. For protected branches, they make sense to bring up first when discussing the GitHub flow.
• Just like the features of Projects and Milestones, make sure that you understand all of the options possible with settings, including protected branches and how code reviews work before teaching.
• Your pull request has a merge conflict. We try to avoid merge conflicts at this point in class.
  • Do you know why that happened?
  • Do you know how to avoid it in the future?
  • How would you handle this in the future if this happens during a class you are teaching?

General notes:

• I think it's clear you have some experience with Git. I know that this teachback happened quickly after class, so you didn't have much time to prepare with this content :smile:. I would like you to re-record this session. In the next recording, please:
  • Follow the curriculum in the Training Manual
  • Show relevant visuals, easy to read text, and no distractions on your screen
  • Clear instruction for participants to follow along as it is an interactive class
• If you have any questions or want to sync before you do this recording, please feel free to reach out to me at services@github.com.

[brianamarie]

Recording

Topic: Introduction & Getting Started

• 👍 Introducing what we will be covering
  • GitHub flow
  • Branching
  • Pull requests
  • Settings and protected branches on GitHub
• 👍 Discussing Branching
  • How lightweight it is
  • How it's different than other VCS
• 👍 Creating a repository from the UI instead of CLI
  • Typically we use a pre-existing repository. But, if you're going to create one from scratch, this works much better.
• 👍 When you're showing your screen in the browser, it's very easy to see. The font is big enough, and the screen is taking up the whole window so there are minimal distractions.
• When you are working in the terminal, make sure that it's big enough like the browser is.
• 👍 I love the discussion between SSH and HTTPS! If questions come up that you don't know the answer to, you're doing the right thing - being honest and saying that you'll research and find out more. Nice job!
• When you're cloning, it appears you are already in a repository. Make sure you are in the correct directory before cloning.
• 👍 Showing the repository file structure locally
• At this point, you've created a repository and cloned. Are the students expected to also create a repository and clone, or clone your repository, or just follow along?
• 👍 I'm already very impressed with the HUGE improvements from the last video. You seem much more confident, the content you are covering is much easier to follow, and it's much closer to the content that we have in the training manual. :100:
• 👍 After you do something locally, you do git status. Frequent git status is always good!

Topic: GitHub Flow

• I saw that you had this window up, but we didn't talk about it.

Topic: Branching with Git

• 👍 Saying "at this point in class, we go through the workflow after creating a branch". This is on the right track! Take more time here. Make sure that if others are supposed to do this, they have time to do it, they have time to ask questions, and you have time to make sure they did it correctly.
• You first created a branch with git checkout -b. Typically, we do the branch creation from the UI, but if we are already past that, I always start with the basic commands first. So, I would recommend using git branch, then git checkout for the first few workflows before moving to git checkout -b. Emphasize understanding the core commands before using shortcuts.
• 👍👏🏻Description of feature branches is FANTASTIC. Showing the visual would help your strong explanation be a even bit stronger.

Topic: Local Git Configs

• I think you might have forgotten about this section.
• When teaching this section, I recommend using the visual in the manual.
• Remember, students using Git for the first time locally will need to set a few configurations before they are able to commit.

Topic: Working Locally

• The transition from Branching to Working locally is seamless
• Very accurate walkthrough of two stage commit
• Remember, the "two stage" commit is new to most developers coming to Git. Be sure to spend some time on what the staging area and working directory mean. I like to use a visual here, from the manual, or one I create where I can drag and drop things that represent work.

Topic: Collaborating on Code

• Creating a pull request - you did this from the pop up message. If this doesn't pop up, do you can still create a pull request by clicking the pull requests tab at the top.
• 👍 Nice job describing what we see while creating a pull request.
• 👍 Highlighting reviewers, assignees, etc.
• 👍 Enabling protected branches. It's a great thing to show, but I think you could spend a bit more time discussing what that means in context of the "GitHub Flow".
• You can assign yourself as the "assignee", but you can not request a review from yourself.
• 👍 Even though you got into a merge conflict a little bit too early, you did a very nice job of explaining how to handle the merge conflict markers.
• At one point, you asked Deepak a question about what to do next! It was so awesome, and I got so excited! But then, you went on too quickly and didn't give him time to answer. You're on the right track with asking questions - then, wait and let people respond. :smile:

Topic: Editing Files on GitHub

• In the curriculum, we do this step before we merge but after the merge conflict.

Topic: Merging Pull Requests

• This went quickly, but went well. I think it was a little confusing how you went on and merged even though it said merging was blocked. If you are going to enable protected branches, make sure to have someone in the repository to approve the pull request so the flow matches what users will see in their own repositories when they aren't admins.
• 👍 Showing the manual when you're describing types of merges
• You showed git reflog here. Usually, we don't show git reflog until much later. The reflog is a history of everywhere HEAD has pointed locally, and to this point in class, we haven't discussed what HEAD is at all.
• 👍 Asked student what they thought would happen based on different merge circumstances! :100: Great job!
• After you did the first workflow, you went through it again to show the merge options. Typically, we would just show these later, since we will have more merging opportunities built into the curriculum.
• 👍 Asking student if you will get an error on push! :100:
• 👍 Pausing and asking students if they have any questions

Topic: Local History

• 👍 Reviewing git pull and git log
• 👍 Showing manual, this could be even stronger by sharing the URL to the manual for the students
• 👍 Great job pointing out what you see in the log, bringing back other information about what you'd just been talking about with the most recent merge
• git log --patch and git log --stat both add more information to the log about the content that was added in each commit. If something like this comes up in class and you aren't sure, it's OK to look it up later and come back to it.

Topic: Aliases

• 👍 Clear pace and instruction when setting the alias

Topic: Resolving Merge Conflicts

• 👍 I think you got to a great place working with Deepak so you are both clear on what state the repository would be in when the students start following along
• As it mentions in the training manual, we recommend fixing the conflicts in this order:
  • Update README
  • Updates to game manual
  • Minor CSS fixes
• 👍 Great explanation of how to resolve merge conflict
• Don't forget to explain how merge conflicts happen (When changes happen on the same file, on separate branches, since the branches have had a shared ancestor)
• A Merge conflict is between two branches, a merge conflict isn't on one branch
• Before teaching this segment, I would recommend practicing a few more times and maybe taking notes on the steps so it's clear what you want to do in class.

Questions

• You go through the workflow first on master. Can you help me understand why you did this?
• When you went through the Pull Request flow, you first merged one with no review. Why did you do this?
• Is there a reason you didn't add Deepak as a collaborator in this repository so he could follow along?
• You got into a merge conflict here - was this intentional? Do you know why this happened?

General Notes

• Yay! :100: :balloon: :cake: I'm so happy with this video. I hope you are proud also, because you made huge improvements from the last time! I especially noticed:
  • More clear direction of the content - you knew where you wanted to go with the class. If I were a student, I'd have much more trust in you and the content.
  • More confidence in the content - you knew what you were talking about, and when you didn't know an answer, it didn't shake you. You just answered as well as you could, said you'd look into it, and moved on.

Keep practicing

• When you are showing the terminal, make sure it is large enough to read, just like the browser. By default, Cntrl + + on windows will zoom in on applications, for the terminal, browser, and Visual Studio.
• Be extra clear if you want the students to participate or just watch. If they are expected to participate, slow down a bit so they have time. While you are listening to others teach, help them with this by asking questions like, "Am I supposed to be following along?"

[SaeedAlbarhami]

@brianamarie thank you very much for your time watching the records, I do appreciate your feedback, will keep trying in order to improve our explanation. I wasn't happy with my first teach-back session. I did repeat that :)

[brianamarie]

Recording

Topic: Introduction

• 👍 Description of what we'll cover in class
• 👍 What is Git and GitHub as version control
• 👍 Great explanation of all of the broad concepts that will be covered, so that if questions come up you are saying "we will cover that" and bringing focus onto the topics you'd like to discuss
• 👍 Asking participant what they know about GitHub :100:
• 👍 "GitHub is a collaboration platform" :tada: I can tell you are sticking to the manual, and it's helping with accuracy of content, path of content, and confidence in your teaching

Topic: GitHub Flow

• 👍 Smooth transition from Introduction content into GitHub Flow
• 👍 Showing the visual while describing
• 👍 Discussing steps of workflow accurately
• 👍 Highlighting lightweight nature of branching
• 👍 Emphasizing importance of master branch
• 👍 :tada: You caught yourself saying "copy" but you corrected yourself to use the terms "snapshot" and "pointer". You compare branching with centralized version control vs Git
• 👍 Great conversations about workflow during the GitHub Flow

Topic: Branching

• It is a little unclear to me when you created a branch. You mentioned "we created a branch" but at that point you had only started to clone.
• You create a branch on GitHub.com. Is the participant also expected to create a branch? Do they have collaborator access to the repository?
• 👍 Later on, answering questions about branching very well. "Can you create branches inside other branches?" Your response was clear and correct, and also addressed some of the possible misunderstandings based on the wording of the question.

Topic: Local Git Configs

• 👍 Showing configuration levels
• 👍 Setting configurations for class
• 👍 Seamless transition between windows
• !!!! :100: You asked the participant to do something in his terminal!!! Did you notice how once you asked for participation, you noticed that he may have gotten lost a few steps ago? More participation = more hands on = you realize people are behind sooner = participants are more engaged. :clap:
• Make sure when you ask questions, you give the participant time to answer (if you are really asking)

Topic: Working Locally

• 👍 Making it clear that it's up to the participant which text editor they will use
• 👍 Using git status right off the bat
• 👍 Showing the visual to describe the concept of working, staging, and history :tada:
• 👍 Very happy with the amount of time and energy spent on working and staging directory
• 👍 Great distinction between tracked and untracked files
• Anticipate questions here for "why would we ever want to do this"? Bring those questions back to GitHub Flow, making atomic commits for code review and iterative branching.
• :100: very nice work
• I like the notepad version of showing how files ar emoving between Working, Staging, and History. I've used draw.io to create interactive visuals where I can drag and drop.

Topic: Collaborating on Code

• 👍 Discussing remote tracking branch
• I'm still confused if the participant is meant to be typing the same things on their computer, or just watching. If I'm confused, they're probably confused.
• 👍 You took some time to cover all of the concepts you've done so far. "At this point, we know how to..." This is great! I think you could do this a bit more often, and take those moments to ask if there are any questions from the participants.
• Typically, we open up a pull request at this point, then edit the files after the pull request has been created.
• 👍 Spending time on viewing the history of a file in the GitHub UI

Topic: Editing on GitHub

• 👍 Accurate demo of this feature
• 👍 GREAT job, after making changes on the remote, asking participant if they think the changes are reflected locally. You asked for their answer, and had them explain why. :balloon:
• 👍 "I type git status, what do you think I'll see?" Great question - give more time for answers, because this is some of the highest interaction so far.
• 👍 You highlight the text we should be looking at, which drew my eyes to your terminal. It made me realize - the text was so small on my screen, I couldn't see it! On my 15" computer screen, your screen is much smaller. Participants will not have their whole screen dedicated to your screen, since they'll be following along. Zoom in with Cntrl + +, and have the window take up the whole screen to make it easier for everyone to follow along.
  • That being said, the highlighting is great - keep doing that!

General feedback

• One major adjustment will be to start following the activities outlined in the manual. I realize this is tricky when you don't have the template repository.
• Participant following along: This was by far the best and closest of the three videos. However, if you could have waited for them to get Git installed for a few minutes, then they may have been able to follow along for the rest of the time.
• Thank you for taking the time to re-record and practice. I have seen huge improvements, and hopefully you have too! I can't wait to see your next videos. :smile:

[brianamarie]

Recording

Topic: Beginning the course

• 👍 Reviewing the topics from last classes
• 👍 Making sure that everyone is on the same page starting off (with GitHub.com account, local environment, etc.)
• 👍 Your images on draw.io are great! (They look much better than mine!) Your explanations are spot on as well. Very nicely done. I'm optimistic to see you continuing to use this tool as you cover other class topics.
• 👍 Adding participant as collaborator so you can both have access and work together in class

Topic: Working Locally

• 👍 You made it very clear that the participant should be following along, by telling them what to do, asking if they have done it, and clarifying instructions when they hadn't quite gotten it the first time. Great! 💯
• 👍 Both browser and terminal are taking up the whole screen, and you asked the participant if the size was good enough.
• 👍 Clear explanation of what they should be doing to create a branch
• 👍 When the participant was typing the wrong thing, you were patient and had him look at your screen to make sure he saw the right thing to do.
• 👍 Answering questions and clarifying how branches are lightweight, that branches are just pointers.
• 👍 Giving options for how to create and edit files based on participant's preference for their local environment
• 👍 When participant said "Now it's saying one file is untracked", you asked them what that means and went back to the visual of the staging, working, and history! 👏🏻
• 👍 Very patient

Topic: Collaborating on Code

• 👍 When the push didn't work, you accurately identified the reason being that the participant hadn't accepted the invitation
• You mention here that this took longer than expected. This part of class is definitely one of the most challenging ones, for exactly the reasons that you saw. It will hopefully go easier from here on out. :smile:
• 👍 Previewing next few topics briefly
• 👍 Discussing the concept of a pull request before diving right in
• 👍 Using visuals from the guides.github.com and the manual
• 👍 Using examples like trying to see a file on master before it's merged to reinforce the concept of branches
• 👍 Asking again to make sure the participant is at the right place when they are creating a pull request

Topic: Merging Pull Requests

• 👍 Spending time talking about the reviewers, assignees, labels, etc.
• 👍 You did a FANTASTIC JOB keeping track of where the participant was and making sure they moved along!
• 👍 You used the opportunity of seeing the generic "comments from abrar" to emphasize the importance of good commit messages and pull request descriptions.
• Actually, Abrar would have been able to create a review. When he shared his screen, it seems like you didn't look at what he was showing. He wasn't on the main pull request page, he was only on his own pull request. Were you looking at his screen, or were you reading documentation while he was showing you his problem?

Topic: Local History

• 👍 It took a while to get on the same page with log, but you were persistent and you got there
• 👍 Asking participant what the opposite was of push. You explained the concept, but kept them engaged
• 👍 Explaining best practice is to merge on the remote
• 👍 Thorough explanation of all of the flags with git log

Topic: Streamlining workflow with Aliases

• 👍 Aliases - such a smooth transition into this section!
• 👍 Easy to follow pace so participants can understand and follow along
• 👍 Making it clear that the alias is a configuration

Topic: Resolving Merge Conflicts

• 👍 When setting up the conflict, you remind to participate again "Can you type with me? Let's type together". :100:
• 👍 Making it very clear which file to be editing, little room for error while the merge conflict is created.
• 👍 Checking again, "Are we on the same line?"
• 👍 Nice job clarifying that adding isn't just something that happens for new files, but for all changes
• 👍 Going through this workflow again, it seems like there were a lot of breakthroughs. These are things that you've covered with the participant before, but you caught them this time and clarified. You were able to do this because they were following along. It's a powerful difference, nice job!
• 👍 Good walkthrough of how to go through the pull request to resolve the merge conflict
• There were a few times when it sounded like you were getting a little frustrated. It's understandable, but you should know that the questions that came up are rather common in class. Lots of repetition will make it get easier over time. :smile:
• 👍 Good time spent on differences between TFS and Git

[brianamarie]

Recording

• 👍 Starting off with review of what has been done, showing what will be done next
• 👍 Asking if there are any questions from the last few lessons

Topic: Fork & Pull Workflow

• 👍 Using visuals
• You were comparing forking vs cloning, when it's better compare forking vs branching.
  • A branch is a part of a repository, but a fork is a different repository with all of the same code (and branches)
• It can be helpful to give examples for when someone would fork instead of just creating a branch.
• The definition of the difference between the motives behind branching or forking:
  • If someone has permission to create a branch on a repository, they would collaborate that way. If they don't have collaborator permission but they have read access, they can create a fork. This way they can still contribute with a pull request, without having write access to the repository.
• The two main examples I use are:
  • Open source projects on GitHub.com
  • Sometimes contractors will not have write access within a company
• Make sure your vocabulary is correct - you fork a repository, not a branch
• You can clone any remote repository, whether or not it is a fork. The clone will (by default) have all branches of that repository.

Topic: Workflow Review

• 👍 Asking questions (even though you have no participants) about what they think is next, or if they have any questions
• 👍 This video (and the last video) you're doing a fabulous job of following the activities from the manual
• It was a little confusing when you showed the working game, if others' games should be working too.
• 👍 Nice job reemphasizing the importance of good commit messages
• You have that fabulous image for working, staging, and history. You used it the first time through the workflow in the last video, but it would be good to use for the first few times through the workflow to help solidify the concept.
• 👍 Pace is easy to follow, especially with stops for questions.
• 👍 👏🏻 Stopping after push to make sure there are no questions or confusions.
• There was an error with pushing. Do you know why it happened? Would you expect the participants to have this same problem? How could you prevent this problem in the future?
• 👍 I'm glad to hear you asking about questions, and that you'll put links in the chat. Even though there's nobody there, the practice is good and you will be great at remembering in a real class!

Topic: Git Bisect

• 👍 Great explanation of when git bisect would be used
• Careful saying that the goal is to "fix an issue". Rather the goal is to "find a commit" where a problem was introduced.
• 👍 Clear walkthrough of the steps necessary for bisect
• 👍 Clear explanation that tests can be run during the bisect

Topic: Reverting Commits

• 👍 Explaining commit structure, nicely done
• 👍 Using different tools to show focus on where people should look, like circling something in red
• 👍 Reemphasizing importance of atomic commits and that Git stores things as objects
• 👍 Everything you're saying is accurate, but I think that some more practice will help you feel more confident in the future.
• To show the concept of revert, I like to use the visualization tool, along with this definition:
  • A "revert" makes it feel like we are erasing a commit, but instead of removing it, we actually create a new commit.
• 👍 You seemed to get back confidence once you started working hands-on again.
• You say "We reverted back and we have changed the commit message" - that's not true, the commits are all the same, except one has been added. I think your understanding of the concept is spot on, but small vocabulary differences like this can really mislead and confuse new users.

Topic: Helpful Git Commands

• It was a little unclear at the start of this, which was you getting set up to teach and which was supposed to be followed along. I think this is only specific to this repository since it was what we used in class, though. If that's the case, no worries. :smile:
• 👍 Pace of speaking is easy to follow along, even if I'm typing along with you on my own machine
• Here, you created the directories and moved the files and made a commit before making the change in the index file. The purpose of this activity is to show how to handle version control even if there is a lot of work in the working directory. So, hold off on committing anything until after the git add -p.
• For this activity, you are still on readme-update. Don't forget to relate everything back to the GitHub flow, which includes deleting branches and creating new ones for new features.
• 👍 Great job and great timing asking "what do you expect to see here?"
• Since your changes were close together, there was nothing still in your working directory and in your staging area at the same time. Usually, I like to show git diff before anything has been committed, but after the first git add -p has been run, so there is a different version of index.html in the working directory, staging area, and in history.

Topic: Tags & Releases

• Important: Tags are pointers and they can be changed
• Tags and releases are used in some workflows that require formal releases
• 👍 Good distinction between tags and releases
• 👍 Nice job with a detailed demo, including things to watch out for like needing to push separately

Overall, very nice job @SaeedAlbarhami!

[SaeedAlbarhami]

@brianamarie Thank you for your great feedback. Actually, I must watch day3 video again, I was partially attending the session.

Were you looking at his screen, or were you reading documentation while he was showing you his problem? I was expecting him to review the request but it was like disabled, I had no clue why that happened!

There was an error with pushing. Do you know why it happened? Would you expect the participants to have this same problem? How could you prevent this problem in the future? Yes, I had to either pull the remote or do force push but I wasn't willing to show him force push and pulling the remote work will fix the renaming issue

In games repository, If I have to show students how to view their own copy of this game page, Is that possible?

[brianamarie]

I was expecting him to review the request but it was like disabled, I had no clue why that happened!

Ah, I see. In our class repository when we went through on day 1, the settings were already configured to require reviews. This documentation may be helpful for configuring those settings.

Yes, I had to either pull the remote or do force push but I wasn't willing to show him force push and pulling the remote work will fix the renaming issue

👍 I'm happy you didn't show force push! You're right that pulling fixed it. But, the reason that you needed to pull at all is because you'd made edits to that branch on the remote. The activities as they're written don't have that step, so ideally, you wouldn't need to pull, either.

In games repository, If I have to show students how to view their own copy of this game page, Is that possible?

Yes, this is possible, but only after they'd fixed the game. Typically I show the broken page and say, this is broken, but after we fix it, it will be a Tetris game. I don't think there's anything wrong with showing the Tetris game, as long as it's clear that their games shouldn't look like that yet.

[brianamarie]

Recording

Topic: Create a Local Repo

• The recording had a really choppy connection, so I missed some things you were saying
• You use Visual Studio Code to create the files vs using the script
  • Is there a reason you used VSC instead of the CLI script to create the files?
  • Are others supposed to be following along?
  • You've mentioned that they can use whatever tool they'd like to use. If they're not using VSC, they wouldn't be able to follow along with that part of the presentation.
• 👍 Really like the use of the visualization drawing when creating the files and working with the files throughout the RESET process
• 👍 Continuing to ask participants what they think the problem is
• 👍 Advising against git add . - at first!
• Using git add . - Another reason we use the script is that the script will create the 6 files, and commit them each separately, so you have a history with 6 commits to edit in the next activities.
• Instead of using the staging area to make your commits smaller, you added all of the files and used git commit file1 -m 'file1 is added'. I would not do this. It does show off the function, but it goes against the reasoning of using the staging area. What's the purpose of having to add files if you use git commit file1 -m 'message' instead?

Topic: Fixing Commit Mistakes

• 👍 Clear and concise explanation of git commit --amend
  • ! Be careful! You say that it will allow you to change the commit's message without changing the snapshot. If we think about the "snapshot" as the commit, changing the message will change the snapshot, because it creates a different commit with a different commit message.
• The problem that you had with accidentally committing all those files will be easily avoided when you use the script instead of adding all of those files.
• 👍 Even though you ran into trouble a little, you handled it well, explained what was happening, and brought the attention back to the topic focus which was git commit --amend.
• 👍 Later on, you made it very clear that git commit --amend does create a new commit, even with using the visualization tool
• 👍 Continuing to open up for questions, both in voice and in chat
• 👍 Now, you make it very clear that they should create a file7

Topic: Rewriting History with Git Reset

• 👍 Using the draw.io tool to show the difference in types of reset. It's okay to use this tool more, coming back to it in between each demo of the reset types
• Make sure it's clear that the the main function of all types of git reset are to move where HEAD is pointing to
• 👍 Clear explanations with different types of wording about the types of reset
• The visualization tool doesn't have a "working directory" or "staging area", so unfortunately it isn't the best candidate to show the types of reset. However, I do like to use it to show the concept or reset without the flags
• To make more commits, you edit existing files.
  • Adding new files with new numbers (like file8 and file9) and including those names in the commit message makes it more clear what's happening in this activity and the next git cherry-pick activity.
• 👍 Asking "what do you expect to see?"
• Be sure to include examples of when each reset type would be used
  • git reset --soft, maybe a developer made many commits locally but would like to bunch them into one commit
  • git reset --mixed, a developer has made several commits locally but would like to restructure the commits so they are more atomic and logical
  • git reset --hard, a developer has been working on a branch locally but has not yet made commits, and would like to undo their work by clearing out their working and staging area
• Also remind that since this changes the commit ID, it is only safe to use on local commits
• git reflog is a history of everywhere HEAD has pointed. It doesn't track things that have never been committed

Topic: Cherry Picking

• 👍 Very nice transition into cherry-pick, with a clear definition of the command
• You ask the participants to follow the steps in the manual, but also to watch you demo. If I were a participant in your class, my attention would be divided. Is there a reason you don't do the activity as a demo, and have them follow along with your steps?
• 👍 Good example for the cherry-pick from the reflog

Topic: Merge Strategies

• 👍 Making sure to clearly explain the types of merges before trying to explain rebase.
• 👍 Using the visualization tool to show the different types of setups for merges. You set up the branches for a fast-foward merge, but you didn't merge it to show. Go ahead and do the merge, you can always type undo in the tool to go back a step. Show the default merges first, then show how git rebase can change the default.
• Once you show the default types of merge, discuss why a team may prefer one over the other
  • fast-forward merge has no merge commit, and one line of history. No commits have multiple parents
  • recursive merge is the default merge type performed when merging pull request on GitHub.com, and has a precise history where it's clear when merges happen and what their parent branches are
• You rebased the rebase-me branch onto master, but there was nothing to rebase. That was set up to already be a fast-forward merge, so rebasing did nothing. There would need to be a set up for a recursive merge, meaning there would need to be new commits on both branches, not just the rebase-me branch. I think you figured this out on your own near the end. 👍

Topic: Cleaning Loaner PCs

• 👍 I'm glad you pointed this section out, because it's important if users are completing the training on borrowed computers

General Feedback

• You have improved so much, and your knowledge of Git has clearly grown a lot too!
• I think one thing that would have made a big difference and gotten rid of a lot of small problems you fought would have been to use the script to create files at the beginning
• You are so close to being fabulous with git rebase, but I think you need a little bit more practice. Please let me know if you'd like to go over this in a call sometime.

I think it would be good for you to re-do the git rebase portion. As soon as you do that, and complete the post-test, you will be done! So close, Saeed, and very nice work.

[SaeedAlbarhami]

@brianamarie Great day, I have done the forth teach-back

Regards

[brianamarie]

Recording: https://vimeo.com/246442877/aa716e600a

Topic: Create a local repository

• 👍 Great job reviewing past content, making sure that participants knew they should be following along, and letting them know they can stop you to ask questions
• Unfortunately your audio is quite choppy so I think I missed a lot of what you were saying. However, what I could hear was spot on, and that paired with your clear example as a visual made it so I was able to follow along.
• 👍 Showing how to create a file in the explorer as well as in the terminal. This makes it easier for anyone to follow along regardless of their previous experience, and it also solidifies the concept that Git will recognize the files regardless of where they're edited/created.
• 👍 Very nice narration throughout your actions, there is no "silent time" or time when users have to wait

Topic: Fixing Commit Mistakes

• 👍 Great walkthrough of this exercise
• 👍 Perfect timing and details when discussing the HEAD pointer
• Your terminal font was quite small, don't forget to zoom in 🔍
• 👍 Great mix of explanation and demoing, easy to follow and easy to understand

Topic: Rewriting history with Git Reset

• 👍 Explaining why to use git reset before going into the details of how 👏
• 👍 Showing visual and describing the 3 different modes of git reset. You've built that amazing visualization tool for showing the staging area, working directory, and history. It would be good to use that in this section, too.
• 👍 "What do you expect to see" with git status 🎉
• 👍 Breaking for questions
• 👍 Clear explanation of differences between soft, mixed, and hard.

Topic: Cherry Picking

• 👍 Concise explanation and demo

Topic: Merge Strategies

• 👍 Good explanation of merge types - I would use the visualization tool here to make sure that everyone understands the types of merges, when they happen, and what the difference is between them
• Careful using git clear, an alias. Others will not have this command.
• 👍 Clear demo with narration. This part was a little choppier than earlier in the video, but I feel confident you will get it smoother with a little practice
• At one point you mention that everyone must do the rebase activity, even though you're going fast. Actually, during the entire "day four" content, we recommend telling participants that if the pace is too quick they are welcome to watch instead of following along. Making them follow along when the content is too fast or too advanced will stress them out, and not make them want to learn. That being said, I think it's okay to give them time to work on an activity, as long as you don't rely on that strategy all the time.
• 👍 It's clear that you've practiced the material and are comfortable with it, because you know what's going to happen next in each step
• 👍 The review at the end was nice, but may not have been necessary. I'd let the class lead you with questions at this point instead of going over the same content.

Great work, @SaeedAlbarhami! This teachback was fantastic, and I've seen so much growth over your teachback videos. Thank you for all of the hard work you put into these. The only step left is to complete this post-test. 🎉

[SaeedAlbarhami]

@brianamarie Hope you are doing well, I have completed the post-test two weeks back, I have not got any further updates..

[brianamarie]

@SaeedAlbarhami Thank you for the mention, I didn't see that the test had been completed. I've graded it and it looks fantastic.

For the next steps, I have a few questions:

• What email would you like me to use to invite you to the Slack room?
• What company will you be providing training under?

I'm inviting you now to the training manual repository. Congratulations, and thank you! 🎉