gcapes / git-course Goto Github PK

Commit on a detached head, then checkout a new branch to save the changes.
We have already abandoned the changes in the worked examples of the lesson, so let's save the commits this time in a new branch.

Example doesn't produce a merge conflict, and that is the intention.
Re-test lesson to make sure examples work. I think there is one step missing somewhere i.e. without telling you what changes to make.

When are we adding the second paper to references?

The ascii diagrams are OK, but a diagram which could be put into a slideshow would be better

Use PS1="$ " if running Bash so the commands typed are easy to see.
Also use a black-on-white shell profile.

See what the default editor is in git bash, if you can set gedit, test for potential problems

In the remotes lesson, the instructions only pull down the master branch. Add in how to get the other remote branches.

This appears to be the same issue as
microsoft/Git-Credential-Manager-for-Windows#613

(I've run with export GCM_TRACE=1 and the error is the same)

Presumably GCM needs updating on the machines in G11

http://staffnet.manchester.ac.uk/news/display/?id=19679 may be useful

Nano seems to be confusing for those not used to the command line. No need for this extra cognitive load.

In slideshow too.

Github changed the URL.

There is a second commit on master for no reason - should be a hot-fix or merge from develop.

Like

• one issue per PR
• one branch per issue
• read and follow contributing
• maybe submit issue to discuss first
• the role of rebase when making edits

Not sure where - maybe in hints and tips

The bio exercise comes a little while after the set-up stage, so maybe asking learners to remember to initialise the repository is asking too much.
A faded example showing what steps need to be done would reduce the cognitive load, while still solidifying the understanding by typing the commands again.

Connection problems can cause freezes, so just side-step this and use the C drive (default home directory for git bash anyway).

In episode 3, line 233, HEAD~ is used to get the parent commit. I don't think this has been introduced at this point, so might be clearer to use the absolute commit id?

Notice how HEAD and master point to the same commit. Now checkout a previous commit again, and look at the graph again. We can display, this time specifying that we want to look at --all the history, rather than just up to the current commit.

$ git checkout HEAD~
$ git log --graph --decorate --oneline --all

Label the commits with their refs

Simply git fetch then git checkout new_branch, rather than introducing new syntax

Already mentioned, but make more obvious that the global config options are effectively a one-time set-up task.

It's likely to be seldom used, so save time and show a bit more of GitHub instead.

Mention that you can release versions with GitHub

In the Commit advice there are mention of file to not follow with git. It is a logical place to mention the .gitignore file which is mention in the hints.

The link to the different types of git reset on line 227 is broken.

[This article](http://git-scm.com/2011/07/11/reset.html) discusses more in
depth `git reset` showing the differences between the three options:

* `--soft`
* `--mixed`
* `--hard`

Put in hints and tips, and link from episode 3 on diff http://stackoverflow.com/questions/6412516/configuring-diff-tool-with-gitconfig

Explanation of detached head needs improving and expanding with diagrams

Somewhere in the branching episode, show git log --graph

In introduction, give very quick overview of git vs SVN if there are people who have previously used SVN.

This is done by default on my computers, but not on G11 cluster. Required command is:
git config --global --add color.ui true

Hopefully improve at-a-glance readability when teaching.

And link to it from the exercises

Just to make demonstrating easier.

R studio in particular because participants have asked about R.

Lesson just does the rebase but the point is to show what happens when you rebase then merge

Visualisation would help greatly with the explanations of what these commands do

Add sections one at a time to make visualising changes between commits more straightforward.
Collaboration could be a model - measurements comparison.

i.e. it makes it really easy for the repo owner to merge your PR

Have emailed Atlassian to ask for clarification of their diagrams.

Check that:

• software is installed
• editors are installed - choose kate for G11 so font size can be changed (gedit doesn't have this)
• terminal is clear on projector (large font, coloured output from ls and git log)