User Tools

Site Tools



  • git commit
    • amend (–no-edit)
    • templates
    • what makes a good commit?
  • git rebase
  • worktrees
  • setting up remotes
  • GitHub workflow

Then, group users in teams, and have them add each other’s remotes (after making them public but read-only) and either send each other pull requests. If it were me, I’d have a simple project already ready with a few “source” files in it (could be plain text) and encourage changes from the group in a few specific exercises, trying merges back and forth.   I’m mostly prefer that the trainer give specific workflows that let us meet these basic criteria that we expect. Off the top of my head: ·         Cross-discipline development on the same topic branch (multiple developers plus qa) – might imply pushing to each other or merge requests to each other, ideally one “team lead” is expected to have a little bit more knowledgeable ·         Pull requests get CI, eventually CD for validation ·         Forbidding pushes except from merge requests, configuring them to require some kind of team lead slash “lieutenant” to approve before merge (rather than someone who worked on the feature or knows them etc)

Additional points:

  • Newer git filter-repo
mck.txt · Last modified: 2019/04/04 12:36 by rpjday