Repository Access

Issues

  • Issues are used to track and plan work.
  • Issue templates provide template text for the first comment for new Issues of various types. They can auto-label Issues and encourage collaborators to give plenty of detail.

Branching Models

  • A clearly communicated branching model helps developers.
  • For small projects use the Feature Branch flow.
  • For larger projects or those with external collaborators use forks with feature branches.

Feature Branch Model

  • Cloning a repository gives you a local copy of the repository: git clone <repository> <directory>
  • Automatically close Issues when a PR is merged by adding a Closes #<Issue number> line to the first comment in the PR.
  • Pull Request templates provide template text for the first comment for new Issues of various types, and Pull Requests. They can auto-label Issues and encourage collaborators to give plenty of detail.

Review

  • A Pull Request (PR) is where your code and science review takes place.
  • General review comments go in the PR Conversations tab.
  • View a diff of the changes in the PR Files changed tab.
  • Make inline comments or suggested changes in the Files changed tab using the diff.

Break

History

  • git log --decorate --oneline --graph lets you visualise your repository history in graph form.
  • There are three options for merging your feature branch into main.
  • merge: creates a merge commit and results in a non-linear history unless you first rebase your feature branch.
  • squash and merge: squashes all your feature branch commits into one merge commit on main. Your history is linear.
  • rebase: re-writes your git history so that all the feature branch commits are now on main. Your history is linear.

Forks

  • A fork is a server side, in our case GitHub, copy of the repository.
  • Forks allow collaborators to contribute to the main repository without being given collaborator access or write permissions.

Conflicts

  • Conflicts occur when two or more people change the same lines of the same file.
  • The version control system does not allow people to overwrite each other’s changes blindly, but highlights conflicts so that they can be resolved.

End

Rebasing

  • Rebasing helps keep your git history linear which can be useful when using commands such as git bisect to find the commit that introduced a bug.
  • Rebasing re-writes your git history. Make a backup of your branch before rebasing. git branch <branch-name>.backup
  • Use an interactive rebase with the -i flag when you want to tidy your git history.
  • Use git rebase main to rebase your feature branch onto the HEAD of the main branch.
  • Always check you have updated your local branch from the remote before rebasing.
  • Always check before pushing to the remote after rebasing that no new commits were added to the remote as these will be lost, use the --force-with-lease flag with git push to help prevent this.
  • Use git push --force-with-lease to update the remote branch.

Pre-commit

  • pre-commit checks help prevent accidental commits to main and provide an extra layer of quality assurance.