This module covers some of the basic concepts of using git/github such as:

• What is a code repository
• How to use branches
• How to commit changes
• How to use pull requests

This course will cover the high-level concepts of GitHub and explain why they are important.

Specifically, you will learn about:

• Code repositories
• Branches
• Committing changes
• Pull Requests

A code repository is a place where source code is kept.

Usually, multiple people have access to the same repository, and this is how they can work together.

You work on code on your local development machine and push the changes to the reposiitory. You pull other people's changes down to your local machine.

Git does a good job of merging code together for cases where multiple people have changed the same things.

It can even automatically merge changes to the same file, provided the same lines of code haven't been modified, but occasionally it is impossible to resolve conflicts and a developer will need to do it manually.

Branching is the way to work on different versions of a repository at one time.

By default your repository has one branch named master which is considered to be the definitive branch. We use branches to experiment and make edits before committing them to master.

If you want to add a new feature to a project you would:

1. Create a branch from master
2. Work on the feature on your local machine
3. Commit the changes you made locally
4. Push the branch and your changes to the repository
5. Ask a colleague to review your work
6. Merge the branch into master if it looks good

Your company may break from this tradition, and it is important to understand how a team works when you first join.

NOTE: It is recommended to use Pull Requests as an official way to suggest changes to a codebase, which we will cover later.

Once you have a branch to work on, you can start committing code.

When you make a change to a code file and save it (or if you delete it), the changes are noticed by git.

You can then commit them to a branch, along with a nice message about what you did.

Once the changes are committed, you can continue working and making more commits.

NOTE: It can seem overkill initially to describe every commit you make, but it is worth getting into the habit. The commit messages are extremely useful for your team mates, and for yourself when looking back through your commits.

You usually commit lots of individual changes at once. Example commit messages are:

• updated all URLs to be https
• added new logo image
• removed old auth files

When you have completed your task (e.g. implemented a new feature, or fixed a bug) you can create a Pull Request to ask for your work to be merged into the main branch (usually called master).

A Pull Request is a proposal to your team to accept the changes you have made in a branch.

Pull requests show diffs (visualisations of what changed in each file) of the content from both branches. The changes, additions, and subtractions are shown in green and red.

Your team can comment on the Pull Request, request changes, ask for clarification, and collaborate in other ways and you can continue to commit more changes to it until it's ready.

If your project has automated tests, it is common practice to have a Continuous Integration system run those tests on the Pull Request before it can be merged.

When everything looks good, the Pull Request can be merged into the master branch, and your task is complete.