Starvard.
Starvard University · Git and GitHub
You will track your work, undo mistakes, and collaborate on projects the way professional teams do. This course teaches Git in plain steps, from your first repository to your first open source contribution, built from Pro Git and the official Git and GitHub documentation.
Hello, my name is Finn, and I'm going to help you understand this course.
Here it is, explained like you are 10:
Git is a tool that remembers every saved version of your work, so you can go back when something breaks. You save snapshots called commits, try ideas safely on branches, and share your work through a site called GitHub. This course shows you the everyday commands professionals use, how to fix mistakes without panic, and how to work with other people on the same project without overwriting each other.
Pro Git, the free book at git-scm.com, explains version control as a way to record changes over time so you can recall specific versions later. Git is distributed, which means each person keeps a full copy of the history on their own computer. GitHub adds a shared home for that history online, plus tools for review and discussion.
You will learn a small set of commands well rather than every command at once. The course puts safety first: it teaches gentle ways to undo work before stronger ones, and it warns plainly where a command can discard work for good. By the end you will be able to start a project, save it step by step, and contribute to someone else project with confidence.
The whole course in brief
What you will be able to do after this course
The ten lessons
Lesson 1
Imagine you are writing a long document and you keep saving copies called final, final two, and really final. Soon you cannot tell which copy has the paragraph you loved yesterday, and sending copies back and forth with a friend creates even more confusion. Version control solves this problem. It is a system that records changes to files over time so you can recall a specific version later, compare what changed, and see who changed it and why.
Git is the version control system most software teams use today. Pro Git describes Git as distributed, which means your computer holds the full history of the project, not just the latest files. You can save work, look through history, and try ideas while offline, then share when you are ready. That full copy also protects you: if one computer fails, other copies still hold the project and its past.
Version control changes how you work day to day. Instead of fearing mistakes, you save small snapshots as you go and know you can return to a working version. Instead of overwriting a teammate file, you each work in parallel and combine your work on purpose. You also gain a clear story of the project: what was built, in what order, and for what reason. This course builds those habits one command at a time, starting with simple saving and moving toward real collaboration. Once version control becomes habit, you stop worrying about breaking things and start experimenting more freely, because a safe version is always waiting for you to return to.
Lesson 2
You start by installing Git on your computer. The official Git site at git-scm.com offers downloads for Windows, macOS, and Linux, and many computers already have Git installed. After installing, open a terminal and check that Git responds when you ask for its version. That quick check tells you the install worked and that your terminal can find the program before you try to use it on a real project. Keep that terminal open as you read, and try each setup step as it appears, so the configuration is done and checked before you create anything that matters.
Next you tell Git who you are. Pro Git puts this first for a reason: every commit uses your name and email, and that information stays with the commits you create. You set it once for all your projects with two commands: git config --global user.name followed by your name in quotes, and git config --global user.email followed by your email address. The word global means the setting applies across your work on that computer.
You can check your settings at any time with git config --list, and you can check one value by naming it, such as git config user.name. You may also set a preferred text editor for longer commit messages with git config --global core.editor, though you can leave the default at first. Take a minute to get your identity right before your first commit. It is much easier to start clean than to fix names and addresses across shared history later.
Lesson 3
A repository is a project folder that Git watches. You create one inside a folder with git init, which makes a hidden .git directory that holds the history. A copy made from an existing project elsewhere comes from git clone, which you will meet again with remotes. Once a folder is a repository, Git can notice which files are new, which have changed, and which are ready to save.
Saving happens in two steps that often confuse beginners, so learn them as separate moves. First you stage the changes you want in the next snapshot with git add, naming a file or using a pattern for several files. Then you save the staged snapshot with git commit, adding a short message that explains why the change matters. The command git status is your guide throughout: it shows what is changed, what is staged, and what Git suggests you do next.
Good commits are small and focused. Save one logical change at a time, such as fixing one bug or adding one feature, and write a message a teammate can understand months later. Vague messages like update or stuff waste the history you are building. If you run git status often, stage deliberately, and commit in small steps, your project history becomes a readable diary that you and your team can trust and search when questions arise. Future you will thank present you every time a clear message explains why a change was made, instead of leaving a mystery to solve under pressure.
Lesson 4
History is useful only if you can read it. The command git log shows your commits in order, with their messages, authors, and dates. Adding simple options can make it shorter and easier to scan. The command git diff shows changes you have not yet staged, line by line, so you can review your own work before saving it. Together, log and diff answer two everyday questions: what has already happened, and what am I about to save.
Undoing has gentle options, and you should learn those first. If you have edited a file and not yet committed, git restore followed by the file name discards the working copy changes and brings back the last saved version, so use it only when you are sure you want that edit gone. To unstage a file you added by mistake, git restore --staged followed by the file name removes it from the next commit while keeping your edits. If you already committed a mistake to shared history, git revert creates a new commit that undoes the earlier one, which is the safer choice for work others may have.
Stronger tools need plain warnings. Warning: git reset --hard can discard commits and uncommitted work permanently, and a force push with git push --force can overwrite history on the shared repository and discard work for your whole team. Do not reach for those commands as a first fix, and never use them on shared branches without talking to your team first. Most everyday mistakes have a gentle undo. Pause, read git status, and choose the least destructive option that solves your problem.
Lesson 5
A branch is a movable line of development that lets you work on an idea without disturbing the main line. Pro Git describes a branch as a simple pointer to a commit, which is why branches in Git are cheap and fast to create. Your repository starts with one default branch, often called main. When you want to try a feature or a fix, you make a new branch, do the work there, and only combine it back when it is ready.
You list branches with git branch, and you create one by adding a name, as in git branch followed by your new branch name. To move onto it, you use git switch followed by the branch name. Many guides also show git checkout for the same job, because older versions of Git used that command for switching. While you are on your branch, your commits advance that branch only. The main branch stays exactly where it was, safe and usable.
Branches keep teamwork calm. Each person can work on a separate branch without stepping on half finished work from someone else. Branches also help you think: one branch, one job. Keep names short and clear, such as fix login or add search, and delete branches after their work has been merged. Small, short lived branches are easier to review, easier to merge, and less likely to drift far from the main line.
Lesson 6
Merging is how Git combines work from one branch into another. When you are ready, you switch to the branch that should receive the work, often main, and run git merge followed by the name of the branch you want to bring in. If main has not moved since you branched off, Git can simply move forward to your latest commit. If both branches moved, Git creates a merge commit that ties the two histories together.
Sometimes Git cannot combine changes on its own. That happens when two branches edited the same lines in the same file in different ways. Git calls this a merge conflict, and it is not a failure or a punishment. Git pauses the merge, marks the conflicted parts of the file, and asks you to decide. You open the file, read both versions, choose or combine the right result, remove the conflict markers, then stage the file with git add and finish with git commit.
Conflicts get easier with calm habits. Merge often so branches do not drift far apart, keep commits small, and talk with teammates about who is editing shared files. When a conflict appears, read carefully rather than picking a side at random. After you resolve it, test the result before you share it. A careful merge protects everyone work, and the skill of resolving conflicts calmly is one of the marks of a reliable teammate.
Lesson 7
So far your repository lives only on your computer. A remote is a copy of the same repository hosted somewhere else, most often on GitHub, that you and your team use as a shared meeting point. GitHub is a website built around Git repositories. It stores your project online, shows its history in a readable way, and adds collaboration tools such as issues and pull requests that you will use in the next lesson.
You connect a local repository to a remote with git remote add, giving the remote a short name, usually origin, followed by its address. To send your commits up, you use git push. To bring new commits from the remote down to your computer, you use git pull, which fetches the changes and merges them into your current branch. When you want a fresh copy of a project that already lives on GitHub, you use git clone followed by its address, which downloads the project and its history and sets up the remote for you.
A steady rhythm keeps shared work smooth. Pull before you start work so you begin from the latest version, commit in small steps while you work, and push when you reach a point worth sharing. If a push is refused because the remote has newer commits, do not force it. Pull first, resolve any conflicts on your computer, test, and then push again. That patience prevents you from overwriting work your teammates have already shared.
Lesson 8
A pull request is a proposal to merge one branch into another, and GitHub documentation describes it as a way to discuss and review changes before merging them. Instead of pushing straight to main, you push your branch to GitHub and open a pull request against main. The pull request shows a clear description of your change, the list of commits, and the exact lines that differ, all in one place where your team can read them.
Review is the heart of the pull request. Teammates can read the changes, leave comments on specific lines, ask questions, and request changes or approve the work. Automated checks, when a project uses them, can also report whether tests pass. As the author, you respond to feedback by pushing more commits to the same branch, and the pull request updates itself. This conversation improves the code and spreads knowledge, because at least one other person understands each change before it lands.
Write pull requests that are easy to review. Keep each one focused on a single job, give it a clear title, and explain what changed and why, plus how you tested it. As a reviewer, be kind and specific: praise what is good, ask questions where you are unsure, and explain the reason behind each request. Good review is not gatekeeping. It is how teams catch mistakes early, learn from each other, and keep quality high together.
Lesson 9
Not every file in your project folder belongs in the repository. Build results, downloaded libraries, local settings, and large data files can clutter history and slow everyone down. Git lets you list patterns in a plain text file named .gitignore in the root of your repository. GitHub documentation explains that Git will ignore files and folders matching those patterns when you commit, and that you should commit the .gitignore file itself so your whole team shares the same rules.
A few habits make .gitignore work well. Add it early, before the clutter gets committed, because ignoring a file that is already tracked does not untrack it: you would need to remove it from tracking with git rm --cached and then commit that removal. Use the ready made templates GitHub maintains for common languages and tools as a starting point, then adjust them for your project. Check git status to confirm that files you meant to ignore no longer appear as new files.
Secrets need a stricter rule: passwords, keys, and tokens never go in a repository, not even a private one, and not even once. Once a secret is committed and pushed, you should treat it as exposed, because copies of history spread quickly. Keep secrets in separate local files that your .gitignore covers, or in your system settings, and share them through a safer channel your team agrees on. If a secret does slip into a commit, act fast: rotate the secret at once so the old value stops working, tell your team plainly, and then clean the repository. Rotating comes first, because removing the file later does not unshare what was already pushed.
Lesson 10
Open source projects live in public repositories and welcome help from people outside the core team. The usual path starts with a fork. GitHub documentation describes the fork and pull model: a fork is your own copy of someone else repository under your account, where you can push freely without permission from the original project. You clone your fork to your computer, make a branch, do focused work, and push that branch back to your fork.
Before you write code, read the project contribution guide and its open issues. Start small: a documentation fix, a clearer error message, or a modest bug fix teaches you the process without overwhelming reviewers. Follow the project style, keep your change to one job, and test it the way the project asks. When you are ready, open a pull request from your fork branch to the original project main branch, and explain what you changed, why it helps, and how you checked it.
Expect conversation after you submit. Maintainers may ask questions, suggest changes, or ask you to split the work into smaller pieces. Respond graciously, make the requested edits on the same branch, and be patient, because many maintainers volunteer their time. Whether your change is accepted or not, you will have practiced the full professional workflow: fork, clone, branch, commit, push, and pull request. That experience, and a polite presence in the community, are real contributions in themselves.
Sources
This course is built from the free Pro Git book and the official Git and GitHub documentation. Pro Git is licensed under Creative Commons Attribution Non Commercial Share Alike 3.0, and it supplies the explanations of version control, configuration, branching, and undoing taught here. GitHub Docs supplies the guidance on remotes, pull requests, and ignoring files.
Graduation
You learned why version control matters, how to install and configure Git, and how to save work with commits. You read history, undid mistakes safely, worked on branches, merged and resolved conflicts, shared work through remotes and GitHub, used pull requests and code review, kept secrets out with .gitignore, and contributed to an open source project.
Keep learning
This course is part of Starvard University, striving for greatness.
A note on accuracy: Much of what you read at Starvard was created with help from AI agents, working alongside people. We check what we can, but we cannot guarantee that everything here is true, current, or complete. If something really matters, your health, your money, a grade, a job, please verify it with a trusted source before you rely on it.