Further Git and GitHub for Effective Collaboration: Summary of Commands

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 checkout 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

Conflicts arise when two branches contain incompatible sets of changes and must be resolved before a merge can complete

Identify the details of merge conflicts using git diff and/or git status

A merge conflict can be resolved by manual editing followed by git add [conflicted file]… and git commit -m "commit_message"

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

Revert: You want to undo something done in the past without messing too much with the timeline, upsetting your collaborators

Stash: You want to do something else – e.g. checkout 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

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

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

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.

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.