Learn Git and GitHub: A Practical Guide for Students

What Git and GitHub do

Git records the history of a project. Instead of keeping folders named “final”, “final-new” and “final-latest”, you save related changes as commits. Each commit gives you a point in the history that you can inspect and compare with other versions. This makes it easier to understand when a change happened and what it was intended to do.

GitHub hosts Git repositories and adds tools for working together: pull requests, code reviews, issues and project boards. Git works on your computer; GitHub gives a team a shared place to discuss and review the work. Saving a local commit and uploading it to GitHub are separate steps.

These habits apply across languages and frameworks. You can use Git while learning a simple website, a Python script or a complete application. The Software Development guide explains how version control fits alongside programming, testing and documentation.

Start with one small repository

Use a practice project with files you understand. A simple website with an HTML page, a stylesheet and a README is enough. A README should explain what the project does and how another person can run it.

There are two common starting points. Run git init inside a new local project to create its repository, or use git clone with the repository URL to make a local copy of an existing project and its history. Cloning is useful when joining a team project. Choose the starting point that matches the project you have.

1. Open your terminal in the project folder and confirm that you are working in the intended project.
2. Check the repository with git status. Read the files it lists before adding them.
3. Make one small change, such as adding a project description to the README.
4. Review the change with git diff, stage the intended file and create a commit.

If this is your first Git setup, configure the name and email you want associated with your commits. Use a practice repository you control, choose its visibility deliberately and keep credentials or private data out of its files.

Understand the everyday commands

Learn what each command changes before memorising a long command list. The staging area lets you choose which changes belong in the next commit; the remote repository is updated when you push.

A useful commit message describes the purpose of a change, for example Add project setup instructions or Fix mobile navigation spacing. Keep commits focused so a teammate can follow the history. Before updating a shared branch, check your local changes and agree on the team’s merge or rebase workflow.

Practise a feature on its own branch

A branch lets you work on a focused change while the team’s main branch continues to represent the shared project. For a practice website, create a branch for a contact page, build and test that page, and commit the work there.

git switch -c feature/contact-page creates a branch and switches to it. Check git status to confirm where you are working. Review and commit the relevant files, then push the branch to the project’s remote. When a new branch needs an upstream connection, specify the remote and branch when pushing.

Before you start, read the project’s contribution instructions and branch naming conventions. Git does not test a page for you: open the page, check its links and try a small screen before proposing the change.

Use a pull request to explain and review the change

After pushing a branch, open a pull request against the team’s intended target branch. A pull request makes the proposed difference visible and gives reviewers a place to discuss it before it becomes part of the shared project.

1. Explain the result. State what the change does and why the project needs it.
2. Review the diff. Check that the proposal contains only the intended files and no local configuration or private data.
3. Describe validation. Record what you tested, such as form validation, links or the mobile layout.
4. Respond to feedback. Discuss unclear suggestions and commit any required improvements on the same branch.
5. Merge when ready. Follow the project’s review and test requirements, then update your local copy of the shared branch.

Code review is useful for learning as well as finding mistakes. Ask specific questions about behavior, clarity and edge cases. Reviewers should explain why a change helps, and authors should be able to explain their implementation choices.

Handle a merge conflict by understanding both changes

A conflict can happen when Git cannot combine overlapping changes automatically. For example, two people may edit the same heading or nearby lines in a page. A conflict is a request to decide what the combined result should be.

1. Read git status to identify the files that need attention.
2. Open each affected file and compare the conflicting changes with the intended behavior.
3. Discuss the overlap with the teammate when the correct result is unclear.
4. Edit the file to keep the correct combined content and remove the conflict markers.
5. Run the relevant checks, stage the resolved files and complete the merge or rebase process you started.

Do not choose one side just to make the conflict disappear. After resolving it, test the feature that each person changed. A file that no longer contains conflict markers can still contain a broken link, missing validation or unintended behavior.

Build useful team habits around the repository

Use an issue to describe a small task before starting work. Agree on who owns it, what should change and how to check the result. Branches and focused commits then make the work easier to review. GitHub project boards can help show planned, active and completed tasks without replacing the discussion about the task itself.

Keep setup instructions in the repository, write clear commit and pull-request descriptions, review feedback thoughtfully and update your branch using the team’s agreed process. As the project grows, automated checks can support review. The DevOps and CI/CD guide explains how version control connects with builds, tests and deployment.

Practice project: build and review a small website together

Pair up with a teammate and create a small public-information website using your own sample content. One person can improve the navigation while the other adds a contact-information section. Keep the first version small enough that you can understand every file.

• Create a repository with a README explaining the purpose and local setup.
• Write two issues with clear tasks and completion checks.
• Create a separate feature branch for each task.
• Make focused commits, push the branches and open two pull requests.
• Review each other’s changes, check the rendered pages and resolve any overlap.
• Merge the completed work and confirm that both features work together.

The result is more useful than a repository containing only an uploaded ZIP file: you can explain the changes, the review decisions and the project history. For a larger next project, follow the Full Stack roadmap or choose a manageable idea from the Full Stack project guide.

Frequently asked questions

Do I need to know a programming language before learning Git?

You can practise Git with plain text files and a README. Combining it with a small coding project gives the commits and branches a clearer purpose.

Does committing a change put it on GitHub?

A commit records the change in your local repository. Pushing sends commits to a remote repository such as GitHub. The remote and branch determine where the work goes.

Should every experiment go directly on the main branch?

For a team project, follow the agreed workflow. A focused feature branch and pull request let others review an experiment before it becomes part of the shared branch.

What should I show when presenting a GitHub project?

Explain the problem, setup, important features and your contribution. A clear README, understandable commits and a tested demonstration help another person assess the work.