Further Git and GitHub for Effective Collaboration: Key Points

Course overview

Collaborative working poses additional challenges compared to individual working
Git and GitHub provide powerful tools to help teams to work together

Git allows non-linear commit histories called branches
A branch can be thought of as a label that applies to a set of commits
Branches can and should be used to carry out development of new features
Branches in a project can be listed with git branch and created with git branch branch_name
The HEAD refers to the current position of the project in its commit history
The current branch can be changed using git switch branch_name
Once a branch is complete the changes made can be integrated into the project using git merge branch_name
Merging creates a new commit in the target branch incorporating all of the changes made in a branch

Merge conflicts result when Git fails to merge files automatically because of mutually incompatible changes
Merge conflicts must be resolved by manually editing files to specify the desired changes
After resolving a merge conflict you must finalise the merge with git stage and git commit

There are several ways of rewriting git history, each with specific use cases associated to them
Rewriting history can have unexpected consequences and you risk losing information permanently
Reset: You have made a mistake and want to keep the commit history tidy for the benefit of collaborators
Stash: You want to do something else – e.g. switch to someone else’s branch – without losing your current work
Rebase: Someone else has updated the main branch while you’ve been working and need to bring those changes to your branch
More information: Merging vs. Rebasing

With git push you can push any committed changes in your current branch to its upstream branch.
If the current branch has no upstream yet, you can configure one by doing git push -u origin BRANCH_NAME.
Using git pull will bring changes in the upstream branch to the local branch.
If the local and upstream branches have diverged (have different commit history), then git pull will attempt to merge both. If there are conflicts, you will have to resolve them.

Forks and pull requests are GitHub concepts, not git.
Pull request can be opened to branches on your own repository or any other fork.
Some branches are restricted, meaning that PR cannot be open against them.
Merging a PR does not delete the original branch, just modifies the target one.
PR are often created to solve specific issues.

Continuous Integration (CI) is the practice of automating checks of code contributions
GitHub Actions is a CI system provided by GitHub
GitHub Actions is configured via a YAML file in the directory .github/workflows
GitHub Actions comprise individual steps combined into workflows
Steps may run a pre-existing action or custom code
The result of a GitHub Actions run can be used to block merging of a Pull Request
CI can be used for a wide variety of purposes

A version of your code with a release number (e.g. v13.4.2) is referred to as a release
A version of your code represented by a commit hash (e.g. 047e4fe) is just referred to as a commit
Publishing a release can be a good way to bundle features and ensure your users use a specific version of your code
git tag allows you to give a commit a human-readable name, such as a version number
Semantic versioning is a common convention for conveying to your users what a new version number means
Tags need to be explicitly pushed to remotes with git push --tags
You can use a tag as the basis for a release on GitHub

Working collaboratively requires coordination - use Issues to discuss with your colleagues who is doing what.
Notifications from GitHub are very useful but also overwhelming when there are many contributions - you will need to manage them.