Lecture 5B - GitHub

Question 1

What is a repository?

Answer 1

A repository is a folder that contains related items, such as files, images, videos, or even other folders.

A repository usually groups together items that belong to the same “project” or thing you’re working on.

Github is best for managing code files so you may want to store other artifacts elsewhere.

Question 2

What should a repository contain?

Answer 2

Every repository should include a README file giving a brief description of the purpose of the project and how to use and run it.
- In a README:
○ Description of the project
○ Instructions
○ Links if necessary

Question 3

What are the repository settings?

Answer 3

Repositories for your university work should be PRIVATE to you, group members (for group projects) and your facilitator or UC (for marking, as required).

Make sure you select the PRIVATE option when you set up your repository.

Making your repository PUBLIC means your code is visible to other students. This is academic misconduct on your part.

Question 4

What are the Local and Remote Repositories?

Answer 4

A remote repository is hosted on a remote location and is shared among multiple team members.
The repository you create for your team in https://github.com/ will be your remote repository.

A local repository is hosted on a local machine for an individual user.

You make changes and test your code locally and then commit to the remote repository branch or make a pull request to commit to the main branch when you are ready.

Question 5

What is commit?

Answer 5

On GitHub, saved changes are called commits. Commit copies local changes you have made to project files onto the repository in GitHub (that is the online ground truth version of your repository).
- Typically done every hour or so or when you make a meaningful change

Each commit has an associated commit message, which is a description explaining why a particular change was made.

Question 6

What do commits capture?

Answer 6

Commit messages capture the history of your changes so that other contributors can understand what you’ve done and why. It is important to take the trouble to write meaningful commit messages or your team may waste much time later trying to work out what was done and why.

Question 7

What is branching?

Answer 7

Branching lets you have different versions of a repository at one time.

By default, your repository has one branch named main that is considered to be the definitive branch. The code on main should always be runnable, checked, and correct.
- Main is known as the master branch
- Never do changes on the main, it should be the most correct and working software

You can create additional branches from main in your repository. These branches are used for programming work: implementing new functionality and fixing bugs.

Commit changes (only) to your branch until everything is working and you are ready to merge your updates to the main branch.

Question 8

What are issues?

Answer 8

Issues are used to define tasks to be carried out for your software project. You should create issues in your repository to plan, discuss, and track work. Tasks can include reporting bugs, planning work, collecting feedback and tracking ideas.

Question 9

How are issues used/what can they do?

Answer 9

Issues can have subtasks to break down the work and labels to categorise the task (eg bug fix vs new functionality). You can create templates (a sort of checklist) for defining issues.

Issues can be assigned to particular team member(s).

Software development work for a issues should be done in its own branch (see above).

Discuss and review issues before you start work to minimise the risk of merge conflicts

Question 10

What is a pull request?

Answer 10

Pull requests are the heart of collaboration on GitHub.

When you open a pull request, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch.

Remember that the main branch is considered to be the definitive branch. The code on main should always be runnable, checked, and correct.

When you start collaborating with others, a pull request is the time you’d ask for their review. This allows your collaborators to comment on, or propose changes to, your pull request before you merge the changes into the main branch.

A pull request SHOULD generate discussion and usually some changes to the code to improve its quality.

Question 11

What is merging (and merge conflicts)?

Answer 11

In this final step, you will merge your branch changes into the main branch.

It is the responsibility of the author and reviewers to ensure this is done carefully or problems can be introduced which are much harder to fix later.

Sometimes, a pull request may introduce changes to code that conflict with the existing code on main. This is caused a merge conflict and can be very painful! You need to resolve the conflicts by making changes to the code and discussion with your collaborators.

Plan your tasks and branches to minimise the risk of merge conflicts.

Once you and your collaborators have checked that code from a github branch select Merge Pull Request and finally Confirm merge.

In professional settings you can delete a branch once the changes have been made