The lab for this lesson revealed a number of issues.

Students need a checklist for a basic workflow. Perhaps use the checkbox feature of GitHub and really emphasize the typical flow:

• make changes
• git add filename
• git commit filename

Additional checklists, for removals and moves, are a good idea.

Should be 'bottom of the body'.

See #23
@nayana487

The Learn Git Branching tutorial was also super confusing for students. The first section introduction to git commits was good, but having students try to grasp detached heads and rebasing was a bit much. I personally don't mess around with rebasing too much, so I don't think students should try to either. Again, this was another thing that detracted from the fundamentals they need to understand.

@raq929

I agree that the git branching tutorial can be a bit confusing. It does tend to work well for visual learners and not as well for others. I'm certainly open to considering different material

The developers fork and clone the repository to their training folder. Many of them instinctively then go into the folder. We then have them create a folder called game-of-gits but we do not highlight in the README that they need to not be in the git repository that they just cloned.

I would recommend clarifying just to minimize any chance of error.

- In your training directory create a subdirectory called game-of-gits.
+ In your training directory, NOT the git directory you just cloned, create a subdirectory called game-of-gits. 

https://github.com/ga-wdi-boston/git#code-along-making-a-local-repository

I didn't realize I used this until now.
"Think about git history like Hansel and Gretle's breadcrumbs."
IF they had just left a sandwich in the middle of the woods, it wouldn't have been very helpful at all. However, the trail of breadcrumbs allows someone else to figure out exactly what their trail was, and saved them from getting horribly murdered by that crazy old woman.

Explain to developers why it's bad practice and tell the never to use this command. Repeat as necessary.

If/when that sinks in, tell them about the one exception (template/generator initial commit).

Forgot to do this, this time around. Please update.

See #23

@nayana487

The lesson plan started off with a section called why git? -- version control. Version control is dev speak and not something that we should expect new students to know. When I delivered, I asked them to think about working on project in a word doc--something most would be familiar with. How did you previously save changes? If someone else was working with you on the doc, how did you collaborate? What would you do if you wanted multiple versions of the project? This set them up to understand why something like git/github would be useful. Perhaps you all do something similar when you actually deliver the lesson, but for someone who was just seeing the lesson plan and doesn't have a sense of the Boston lesson flow, it was kind of confusing.

@raq929

I really like your first point, and it seems like you related it to something they would understand really well. I think we do need to introduce the term version control, because they'll run into it in interviews - but the way you did it sounds great.

The value of this lab as I see it, is to show Atom changing in accordance with their branch changes.

The lab should just be switching between the two branches and observing Atom.

Steps 3 on have the developers staging and committing to master. This should be removed.

In README.md Prerequisites "WDI Fundamentals, Chapter 2" is a dead link. Should it be changed to Git Bash and Terminal?

Just to note a common confusion about what a repository is.

A student asked if it was ok if they "just pushed a folder". This indicates a good understanding of the purpose of git, but not how it works.

See #23
@nayana487

I was kind of put off by the section that said never user git commit -m. That "This is surely a sign of a poor developer and one that does not respect his or her teammate's time." This is how my instructors taught me to write commit messages and what they and pretty much every other developer I know uses in their work flow. When I delivered the lesson, I told the students that what was written in the lesson plan is the opinion of the instructor who wrote the lesson. I personally don't agree with it and this is why. It's ok and encouraged to have differing opinions as developers, but we should be able to intelligently articulate why we prefer one way over another. I did let Matt know ahead of time that I'd be saying this. That said, I don't think such strongly worded opinions should be written into a lesson plan in this way. I think --generally speaking--it's better to present different options and let students figure out what works for them. At least until the shops they end up at tell them otherwise.

@raq929

I agree the wording should be changed. Calling people bad developers just isn't helpful. I think the reasoning here (and @gaand might have more to say) is that at this level, developers aren't yet good at writing commit messages. Forcing them to open an editor and write a two line commit message makes them think more critically about what they're doing and produces commit messages that are more helpful to them and to us. (Personally, I only use -m when I'm making a fixup commit, for similar reasons.)

e.g.
git log --graph --all --decorate --oneline

Should be modified, staged, then commited. via @payne-chris-r

Summary

Using Git especially in the context of how we use them in the class.

Prerequisites

• Unix CLI Intro

See ga-wdi-boston/git-practice#36

This was the first lesson I taught and I was unsure about how much I should deviate from the set curriculum, if I could make changes to the repo so I mostly delivered as is. However, there were a couple points mentioned in the lesson that I contradicted in my delivery and some points I added. I also have some thoughts on how this lesson should be restructured.

• The lesson plan started off with a section called why git? -- version control. Version control is dev speak and not something that we should expect new students to know. When I delivered, I asked them to think about working on project in a word doc--something most would be familiar with. How did you previously save changes? If someone else was working with you on the doc, how did you collaborate? What would you do if you wanted multiple versions of the project? This set them up to understand why something like git/github would be useful. Perhaps you all do something similar when you actually deliver the lesson, but for someone who was just seeing the lesson plan and doesn't have a sense of the Boston lesson flow, it was kind of confusing.

• I was kind of put off by the section that said never user git commit -m. That "This is surely a sign of a poor developer and one that does not respect his or her teammate's time." This is how my instructors taught me to write commit messages and what they and pretty much every other developer I know uses in their work flow. When I delivered the lesson, I told the students that what was written in the lesson plan is the opinion of the instructor who wrote the lesson. I personally don't agree with it and this is why. It's ok and encouraged to have differing opinions as developers, but we should be able to intelligently articulate why we prefer one way over another. I did let Matt know ahead of time that I'd be saying this. That said, I don't think such strongly worded opinions should be written into a lesson plan in this way. I think --generally speaking--it's better to present different options and let students figure out what works for them. At least until the shops they end up at tell them otherwise.

• I actually wouldn't have gotten into branching at all in a first time exposure to git lesson. Git is a pretty hard concept for complete newbies to grasp in general, and implementing branching proved very confusing to the students. If I were to deliver this again, I would talk about what branching is at a high level and why it's useful, but I wouldn't teach the implementation just yet. I think having them know about git add, git status, git commit and git log at this point is sufficient. It's what we actually need them to be doing for their homework. They can know how to look at a solution branch on an exercise in Github, but they're probably not going to be creating their own branches for a while. In DC, we do teach branching in week one, but as a separate lesson after git intro and github are introduced. Going into branching at this stage confused the students a lot and I think ultimately made it challenging the rest of the week because they were unsure about how to properly use git and github when submitting homework.

• The Learn Git Branching tutorial was also super confusing for students. The first section introduction to git commits was good, but having students try to grasp detached heads and rebasing was a bit much. I personally don't mess around with rebasing too much, so I don't think students should try to either. Again, this was another thing that detracted from the fundamentals they need to understand.

shoudl be code along not lab

The following section isn't code or a direct instruction. I don't think it should be formatted like this

Committed means that the data is safely stored in your local database. Modified
means that you have changed the file but have not committed it to your database
yet. Staged means that you have marked a modified file in its current version
to go into your next commit snapshot.

Explain ramifications from an employment perspective.

Model good commit messages, headline, blank line, detail.

Not even on first commit:

Initial commit

Starting from `ga-wdi-boston/js-template`.

The lab for this lesson revealed a number of issues.

For moves, we should definitely remind them to use git mv instead of mv. We know it doesn't matter, but it's a source of confusion when students use mv and see that a file has been added or deleted in the staging area.

Checklist:

• git mv filename newname
• git commit
• Write message noting the moved file

A similar checklist for removals might be necessary.

• @J-Weeks