Skip to content

Git for normal people

Jump to bottom
Richard Darst edited this page Dec 17, 2017 · 2 revisions

Course designed so that everyone can start using version control. The core idea is to teach workflows that are easy, instead of the git developer's ideas. The target is to present this in a one-hour session.

Goals

  • Understand why version control is useful, compared to cloud service snapshots, renaming files, etc
  • Use git in workflows that are close to subversion. Abstract away the power
  • Use git via only github/gitlab (online editing, viewing trees, PRs, etc).
  • Use git via GUIs and in close cooperation with a hosting service. Some command line is learned, but this is only after easy methods.

Usage models

The main point of this course is to not be able to do everything that git offers, but instead to use several simple logical workflows. List the workflows in this section. (for now they are in goals above)

Course Outline

  • About version control
    • Problems without version control
    • some of these comics, lost revisions, etc. Discussion of snapshotting cloud services and so on, why a proper VCS is still better.
    • Introduce some of the fundamental software development graph models: simple (history advances linerarly), forks (history diverges), development lines (branches eventually merged). Not to teach how this works, but to get an intuition about the graphs you will be seeing later.
      • Why git is better than other VCSs for some of these development models (so why it's become popular).
      • Branches in someone else's repo.
  • About git
    • Git is by far most popular VCS now, but it was never made for normal people
    • The idea was "better UIs would come later", but guess what: we are still teaching the old way from command line.
    • We call this course "git for normal people". It's not insulting to you, it's insulting to git. The "default" way of working really is not designed for people who just want to get something done simply, and front-loads learning on new contributors.
  • Git archaeology using github/gitlab (mainly based on CodeRefinery course, but start using web GUIs only.)
    • First, a note that git != github/gitlab, but they are nice interfaces. same features as command line, but command line much more powerful.
    • This section is taught using existing projects found on github and/or gitlabs.
    • Example exercises:
      • View old commits. When was it first started? What code existing on 1.feb.2017?
      • Get version of file on that day.
      • go dig through history of existing project, find old versions, git blame, etc
      • Your non-git using colleague just reports "the function global_efficiency in networkx doesn't work anymore, it is doing something different". You know networkx is on github. Was this function changed recently (in 2016)? Who changed it and why? What are the first versions of the change?
  • Git edits using github/gitlab
    • Exercise: create a project, make some commits (guacamole recipe)
    • Exercise
      • Explain forks and pull requests. Not anyone can commit to a project, but anyone can fork with no risk and make changes. Pull requests = "I want to send something back", which is also a low-barrier process.
      • Pair exercise: Create fork, patch, and pull request.
  • Local usage using GUIs and and little bit about command lines.
    • Standard git configuration: user.name and user.email configuration, and our other important aliases like git graph (things you always copy and paste, don't need to understand what these mean).
    • Making git repositories and linking to github/gitlab (TODO: many ways to create a repository and link it to the repo. Settle on the minimum set that works in all cases and use them.)
    • Committing locally and pushing
    • Always pull before working, always push as soon as possible (yes, this is simplistic but is best way to prevent conflicts at the expense of sometimes breaking master, which is OK for now).
  • Command line use
    • init, add, commit, push, pull, remote add, remote set-url.
  • Advanced use
    • Solving conflicts? Come up with the simplest possible conflict resolution strategy, which might be "reset to master and try again".
    • Things that you'll learn next. Give some motivation to advance to the next level. (solving conflicts better, not breaking master, working on branches, staging, rebasing) (basically incrementally better practices than the simple method recommended above). How much to teach now? Probably not much, save it for medium level course.
    • Demo of meld?
    • The answer is "Can I do X with git?" is always yes, if you know enough. So don't be shy about trying things.

Cheatsheet

We should have a "git for normal people" cheatsheet to go along with this. It can have both command line and github/gitlab ways of doing things, if possible, and focus on our two workflows. Does anyone know of a good git cheatsheet already?

References

Clone this wiki locally