hbayado feedback

[hbayado]

Hi @brianamarie

I just finished my first teach-back session, it took us 3 hours! Sorry for that 😟

Please let me know once you receive the video and I will be waiting for your feedback on it.

The next session should be recorded in the next few days as we have a long weekend in the UAE these days because of the national holiday, I am targeting Monday evening for Day 2, will keep you posted.

Thanks

[brianamarie]

Hi @hbayado! Yes, I have gotten the recording. I hope to have it graded before you do the Monday recording. Have a nice holiday and weekend!

[beardofedu]

Hey Hazem,

My name is Matt Desmond and I am a colleague of @brianamarie on the GitHub Training Team. I helped Briana with reviewing your teachback video so we could provide you with timely feedback. I really enjoyed watching your video and it was really awesome to see you explore Git functionality in "real time". Here is my feedback for the Teachback November 29 Room 2 Video 2 video:

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

Intro

• I like that you normally ask the students to introduce themselves and identify their expectations for the course. Makes it easier to make sure you are meeting expectations and you can tie specific sections of the content to the students who expressed interest in that topic.
• Good answer to the "do I have to collaborate with Git using GitHub" question
• One thing to avoid is the use of "simple task" or "this is easy" because if a student in the class is struggling with an "easy / simple" task they might give up before really getting started.
• It is helpful to have all the websites you are going to access already open in new tabs. This will become more natural as you continue to teach classes.
• I like the review of all of the things you need to continue with the class.

Getting Started

• The question that was asked about garbage collection, Git does have internal housekeeping actions however it doesn't communicate with a server until you tell it to, which was your primary point during this section. When we reference how Git is explicit we normally focus on the no auto-save / auto-sync capabilities which you nailed.
• Technically, a repository can be created on a local machine and uploaded to GitHub. Typically we refer to GitHub as a collaborative platform for Git repositories as opposed to a tool to create a Git repositories.
• When describing the README.md file, it can be helpful to identify things that should be included in the README.md file, such as: how to contribute, who the project owners are, installation / general use content, etc.
• Wikis are one place that documentation can go, GitHub Pages is another way to display project documentation. Just a small addition to the description of the Wikis tab.
• Good description of what a pul request is, this comes up a lot in trainings. Example, "Why is it called a pull request"
• You accidentally said "learned markup" instead of markdown, but great insight as to where markdown comes from
• Your comment about the GitHub Flow image in the documentation not having clickable sections is something that we can look at fixing. Great feedback. @brianamarie for :eyes: on this issue.
• Typically we call it Atomic Commits rather than Atomic Changes, but the basic concept was presented in this section.

Topic: GitHub Flow

• You mentioned 3 stage commit, we call it the 2 stage commit. Might have just been a quick mistake since you were commenting on the 3 commits made before the Pull Request.
• When you were talking about the deployment testing during the GitHub Workflow, you should be able to use tools to test specific PRs as opposed to testing the code applied to master. As you merge PRs into master, the other PR tests would be updated with the latest version of master.
• The dots on the feature branch are individual commits and don't identify the stages of creating a commit. You referenced this around 2:39-2:40 so I was able to catch where the image made it a little confusing.
• Default reviewers can be identified with the CODEOWNERS file that you can add to your repository. You spoke about it around 1h34m mark, just wanted to identify the file you were talking about.

Topic: Branching

• Great callout on the blue bar that is created during the creation of a branch in a repository.
• Good description of what a branch is.
• One thing to remind students about is that when you switch between tabs within the GitHub UI the branch might switch back to the master branch and to be aware of that if they are looking at files on a specific branch within the UI.

Topic: Local Git Configs

• One thing about git config is that with --local you have to be within a repository within your command line to set a --local config
• When you talked about the git config --global you mentioned system wide on accident and corrected yourself after someone pinged you in chat. Just something to keep in mind when talking about configuration levels.

Topic: Working Locally

• Remember, the first time you clone, you use the git clone command and not the git pull. You corrected yourself in the video, just something to keep in mind when going through the exercise of git clone with students.
• Nice touch bringing up how to move from one repository to another repository and the followup conversation about how the file system and Git interact.
• You caught it in the video, but just remember that to checkout you use git checkout <branch> and git branch <branch> will create a branch if it doesn't exist. If it does exist on the remote but not on your local machine, it create a local branch that isn't tracking your remote branch. Around the 2:15 - 2:20 mark you were trying to resolve the issue you encountered, sometimes Git produces helpful text on how to resolve an issue. This text is something that is important to share with students as well, when they encounter a problem, Git is probably trying to provide resolution text.
  • The conversation you were having about this was a really great exploration of Git and was fun to watch. :+1:
• git pull is going to update the branch you are currently checked out to, however, it updates all of the other branches on your remote that they are ahead/behind the remote by X number of commits. You would still need to perform a git pull to update the branch when you check out another branch for the first time since performing a git pull.
• To remove a branch, or untrack it, you would run git branch -d <branch name>. This removes the local version of the branch on your machine.
• Branches displayed in your command line:
  • white: branch has been brought down locally
  • green: branch you are currently checked out to
  • red: branches that exist on your remote(s)
• Git tracks the files all of the time and displays the file how they appear on the branch you are currently checked out to. You can move from one branch to another with a change in your working directory and commit it to another branch as long as it doesn't create a conflict. For instance, if you create 2 commits while on master you can use git reset --mixed to send the changes back to the working directory, create a new branch from master, and recreate your commits (as one option).
• If you modify files on one branch Feature 1 and need to apply the branches to Feature 2 you would need to merge the changes from Feature 1 into Feature 2 as you discussed in your video ~2:33. I was typing this as you were discussing it, and you came to a conclusion, so reassuring your outcome :smile:.
• @brianamarie we reference gh-pages on the Working Locally section and the gh-pages branch didn't exist in their class repository. Something to look into and potentially fix.
• Just a remindeer, we refer to it as a 2 stage commit. The stages are differentiated by the commands (git add, git commit) as opposed to the names of the area the file resides in (Working Directory, Staging Area, History). This is because a commit can be created in Git without the need of pushing the file to a remote repository.
• Great walkthrough of how to get out of Vim
• I like how you showed your branch in the UI before you ran git push to show that the local changes haven't been sync'd to the remote
• Around 2:45 you ran into the issue of not being able to push your local branch to the remote repository. This was caused by running git branch <branch name> and not git checkout <branch name>.
• When discussing Labels I like to bring up some example labels like bug, feature, or for open source projects good first issue.
• One clarification on being able to see an Issue that has been closed. The issue can still be found, you just need to look at the Closed Issues, by default, the GitHub UI displays Open Issues. So when we close an issue, the issue can still be found within the repository. This is a great way of being able to reference what conversations occurred prior to the creation of a Pull Request when looking at changes that have been made to the repository.
• Because you reviewed your own Pull Request the Request Changes and Approved options weren't available to you in the Review drop-down. You didn't mention it during the video, just something to keep in mind if you are teaching a class, and review your own Pull Request.
• Technically, you don't have to go back to your local machine to make changes based on a Pull Request review, however (and I think this is what you were inferring), in most cases the user will work on the files locally because editing 1 file at a time would be very time consuming. You ended up making the change on the GitHub UI which is :+1: but you had referenced (or it sounded like) the student would always find themselves working locally.
• Another note on the Pull Request review feature is the number of notifications the author of the Pull Request will receive. In the past you would need to provide comments one at a time, and each comment would generate a notification for the Pull Request author. With a review, the author of the Pull Request gets 1 notification that includes all of your comments.

Question at the end

So, if your pull request isn't approved, you would make changes locally and push the commits to your branch. That branch will be updated with your changes and the Pull Request you already have opened will be updated with the commits you made and pushed after your Pull Request was rejected. Typically a branch and a pull request exist in a 1:1 relationship.

Rejected : Request Changes vs Closed

So, a Pull Request reviewer can request changes or close the pull request. If the reviewer requests changes the pull request is still open and you can make changes to the branch (locally or on the UI) and commit / push (if working locally) to your pull request.

Around 3:07, the discussion was talking about creating a pull request with a branch to identify what you are planning on doing. Typically an Issue would be used to identify what work you wanted to accomplish but, if you want to initate the change with a pull request you would need to create a new branch and make a commit that differentiates the new branch from the base branch. Then you can create a pull request.

General notes:

• When using a mouse highligher, in your case the big red circle, don't forget to turn it off when you aren't using it to highlight content on the screen
• We typically don't teach from a slide deck and use existing content on various websites to explain concepts related to Git and GitHub, that being said, you did a great job of not reading your slide deck word for word and it added value to your class.
• When showing how to create an account, it might be useful to use a browser that you normally don't use GitHub for so you don't need to log out of your account.

If you have any questions about my feedback, feel free to at-mention me.

[hbayado]

Hi @beardofedu

Thanks Matt for your feedback, very helpful and insightful.

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

Intro

• I fully agree with you on the use of "This is easy". I need to pay attention to the words I choose in the future, thanks.

Getting Started

• I still don't understand how git does its garbage collection if there is no service/daemon running in the background? Does it do some GC during every command you run? Or is it something (ie. GC) that needs to be turned on?

Topic: Github Flow

• You're right about the 3 stage commit mistake, I was probably confused with the three states of the files and got it mixed up with this as you mentioned.

• The dots on the feature branch are individual commits and don't identify the stages of creating a commit. You referenced this around 2:39-2:40 so I was able to catch where the image made it a little confusing."

  Thanks, that's good to know, didn't realize that. But now that you mention it, it makes sense.

• Default reviewers can be identified with the CODEOWNERS file that you can add to your repository. You spoke about it around 1h34m mark, just wanted to identify the file you were talking about.

  That's also good to know

Topic: Branching

• One thing to remind students about is that when you switch between tabs within the GitHub UI the branch might switch back to the master branch and to be aware of that if they are looking at files on a specific branch within the UI.

  That's a very good point, will keep that in mind 👍

Topic: Local Git Configs

• One thing about git config is that with --local you have to be within a repository within your command line to set a --local config

  That is a VERY important point, thanks for that 👍

Topic: Working Locally

• git pull is going to update the branch you are currently checked out to, however, it updates all of the other branches on your remote that they are ahead/behind the remote by X number of commits. You would still need to perform a git pull to update the branch when you check out another branch for the first time since performing a git pull.

  I read the above point many times and still am confused by it. The first part is clear, where git pull updates the current branch I am currently checked out to. However, the second part is where I get confused. So you said "it updates all of the other branches on your remote that they are ahead/behind the remote" so you mentioned the remote entity twice here and implied that they are being compared to each other, but are they the same "remote" or you did you mean different "remotes"?? Can you please elaborate? Thanks

• Just a remindeer, we refer to it as a 2 stage commit. The stages are differentiated by the commands (git add, git commit) as opposed to the names of the area the file resides in (Working Directory, Staging Area, History). This is because a commit can be created in Git without the need of pushing the file to a remote repository.

  Yep, this is clear now and the distinction is understood 👍

• One clarification on being able to see an Issue that has been closed. The issue can still be found, you just need to look at the Closed Issues, by default, the GitHub UI displays Open Issues. So when we close an issue, the issue can still be found within the repository. This is a great way of being able to reference what conversations occurred prior to the creation of a Pull Request when looking at changes that have been made to the repository.

  Great Point! I actually realized that during my practice before the session and thought that I should show the closed issue to the class but completely forgot 😄

• Because you reviewed your own Pull Request the Request Changes and Approved options weren't available to you in the Review drop-down. You didn't mention it during the video, just something to keep in mind if you are teaching a class, and review your own Pull Request.

  Thanks, need to read more about the "Review" feature. 👍

• Technically, you don't have to go back to your local machine to make changes based on a Pull Request review, however (and I think this is what you were inferring), in most cases the user will work on the files locally because editing 1 file at a time would be very time consuming. You ended up making the change on the GitHub UI which is 👍 but you had referenced (or it sounded like) the student would always find themselves working locally.

  You are correct, I was inferring that the user would need to do the requested changes on his/her local machine, I will be more explicit in the future.

• Another note on the Pull Request review feature is the number of notifications the author of the Pull Request will receive. In the past you would need to provide comments one at a time, and each comment would generate a notification for the Pull Request author. With a review, the author of the Pull Request gets 1 notification that includes all of your comments.

  Cool, didn't know that

Questions at the End

The way you are describing how the Pull Request is integrated with your feature branch is very powerful and nice to know! Need to do more testing to fully flesh out the details, but thanks for pointing it out.

General Notes:

• We typically don't teach from a slide deck and use existing content on various websites to explain concepts related to Git and GitHub, that being said, you did a great job of not reading your slide deck word for word and it added value to your class.

  I noticed that and allow me to disagree with your approach here 😄. I've been in the IT industry for about 21 years now, yeah getting old ha ha, with heavy involvement in education/training. Having all the "material" in once place, aka a training guide (which you already -kind of- have, it is a bit basic in my opinion), is very helpful for students and a slide deck (which you don't have) that has the main subjects with the graphics and diagrams to support it. The slide deck has many helpful uses one of which is for the instructor to use to get a glimpse of the subjects to be taught and can act like a review/flash card tool. Also I notice the minimal use of graphics and diagrams in the class which is strange since a lot of the concepts can really use the aid of graphics and diagrams to help drive the ideas home. A separate lab guide is also very helpful.

  Using your approach actually confused me a lot and I had to refer back to the Pro Git book for the step-by-step explanation of all the concepts. Maybe your approach works for veterans of git which I am not and cannot judge on that, I am completely new to this. But you guys kept mentioning in the class that this also is "for beginners" and as a "beginner" I can tell you that the pace of the class was very fast and the scattered materials didn't help at all. I hope you see this as constructive criticism and that it might help you optimize your approach for an otherwise Superb class in the future.

[hbayado]

Hi @brianamarie,

I noticed that my name on the project board is still in the list of "No Techbacks Complete"? So is that gonna change soon to reflect that Day 1 is complete? Should I move to Day 2? Please advise

Thanks in advance

Hazem

[beardofedu]

@hbayado

I read the above point many times and still am confused by it. The first part is clear, where git pull updates the current branch I am currently checked out to. However, the second part is where I get confused. So you said "it updates all of the other branches on your remote that they are ahead/behind the remote" so you mentioned the remote entity twice here and implied that they are being compared to each other, but are they the same "remote" or you did you mean different "remotes"?? Can you please elaborate? Thanks

So I'm going to try and explain it with an example, and hopefully this clear it up a little bit.

In your project you have 3 branches, master, feature_1, and feature_2

When you run git pull while checked out to feature_2 Git will literally grab the latest changes to the feature_2 branch and apply them. When you run git pull you are actually running git fetch (aka grab the latest changes) and git merge (take those latest changes and apply them to my branch. When you run git pull Git applies the changes from your remote to the branch you are checked out to, but, it is also updating the reference points for master and feature_1. The next time you checkout to master or feature_1 and run git status Git will respond with the number of commits that you are behind (aka the number of commits that exist on your remote that aren't on your local version of the branch) or ahead (the number of commits on your local machine that don't exist on the remote). Basically, when you run git pull Git is updating your current branch (applying changes to your files that exist on the remote but not locally) but also updates the reference points for other branches on your local copy of the repository.