Further Git and GitHub for Effective Collaboration: Summary of Commands

Code along with the presenter.

Ask questions!

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.