Git and GitHub help developers track changes, protect their work, and collaborate on software projects without losing control of the code. This practical guide explains the difference between Git and GitHub, the commands worth learning first, how branches and pull requests work, and how to build a safe, repeatable workflow from your first commit to team collaboration.
You do not need to master every Git feature at once. Start with the basic workflow, practise on a small project, and gradually add branches, remote repositories, code reviews, and automation as your confidence grows.
Version control is a system for recording changes to files over time. It lets you inspect earlier versions, compare changes, identify who made them, and restore work when something goes wrong. For a developer, that means you can experiment with a new feature without relying on folders named “final,” “final-new,” and “final-really-final.”
Without version control, collaboration can become risky. Two people might edit the same file, overwrite each other's work, or struggle to work out when a bug appeared. A version control system keeps a history of changes and provides tools for combining contributions in a controlled way.
Version control can be centralized or distributed. In a centralized system, a main server holds the shared history. In a distributed system such as Git, each clone contains the project's history, allowing many operations to happen locally and offline. A remote hosting service is useful for sharing work, but the local repository remains a complete working record.
Git is version control software. You install it on a computer and use it to record changes, create branches, compare versions, and combine work. Git can be used entirely locally, even if you never create an online account.
GitHub is an online platform for hosting Git repositories and collaborating around them. It adds a website interface, pull requests, issues, discussions, access controls, project tools, and automation integrations. GitLab and Bitbucket are other platforms that host Git repositories and provide collaboration features.
| Git | GitHub |
|---|---|
| Version control software | Repository hosting and collaboration platform |
| Runs locally and can work offline | Provides online access to hosted repositories |
| Records commits and manages branches | Hosts repositories and supports pull requests and issues |
| Uses commands such as git add and git commit | Provides a web interface, permissions, reviews, and automation |
A simple analogy is that Git is the tool that records and manages the history of your work, while GitHub is a shared online workspace where that history can be stored and discussed. You can use Git without GitHub; GitHub uses Git to manage repository history.
A Git repository is a project whose history is tracked by Git. The hidden .git directory stores repository data and configuration. Your ordinary project files are in the working tree, where you edit code and documents.
Git's everyday workflow has three important areas:
You edit a file in the working tree, use git add to stage the version you want to save, then use git commit to record a snapshot. Staging is useful because you can select only some changes for a commit rather than saving every edit at once.
A commit records a snapshot and points to its parent commit or commits. It includes metadata such as author information, a timestamp, and a message. Git identifies objects using hash-based identifiers; you usually do not need to memorise them because commands display short forms. The key idea is that commits form a history you can inspect and compare.
Install Git using the official download page at git-scm.com/downloads. Windows users can install Git for Windows; macOS and Linux users can follow the installation options for their systems. You can use Git from a terminal, a code editor such as Visual Studio Code, or a graphical client such as GitHub Desktop.
After installation, open a terminal and check that Git is available:
git --versionSet the name and email that Git should attach to your commits. Use the identity you want represented in your project history; in a work environment, follow your team's guidance.
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch mainThe --global option applies the setting to your user account on that computer. A repository-specific setting can override it. These commands configure commit metadata; they do not sign you in to GitHub. For help with authentication, use GitHub's official instructions for HTTPS or SSH rather than placing passwords or tokens in scripts.
Practise with a small folder so that you can see each step clearly. Create a directory, enter it, and initialise a repository:
mkdir hello-git
cd hello-git
git initCreate a file named README.md with a short description of your project. Then inspect the repository and record the file:
git status
git add README.md
git status
git commit -m "Add project README"The first status check shows Git's view of the untracked file. After staging it, the second status check shows that the file is ready to be committed. The commit saves the staged snapshot in the local repository. If Git reports that your identity is missing, complete the configuration step above and retry.
If you are starting from a repository that already exists online, use git clone with its URL instead of running git init in a new folder. Cloning downloads the repository and sets up a remote connection, normally named origin.
You do not need hundreds of commands to begin. Learn what these common commands do and practise them until they feel natural.
| Command | Purpose |
|---|---|
git status | Shows the current branch and working-tree or staging changes. |
git add filename | Stages a specific file's current changes. |
git add . | Stages changes under the current directory; review status first. |
git commit -m "message" | Records staged changes in a commit. |
git log --oneline | Shows a compact commit history. |
git diff | Shows unstaged changes compared with the index. |
git diff --staged | Shows changes staged for the next commit. |
git branch | Lists local branches. |
git switch -c feature-name | Creates a branch and switches to it. |
git merge branch-name | Merges the named branch into the current branch. |
git fetch | Downloads remote updates without integrating them into the current branch. |
git pull | Fetches and integrates remote updates according to the configured strategy. |
git push | Sends local commits to a remote when permissions and branch setup allow it. |
A reliable habit is to run git status before and after important operations. When you are unsure what a command will do, inspect the changes first and consult git help command or the official documentation.
A commit should represent one logical change. Examples include fixing a validation bug, adding a test, improving a setup guide, or implementing one small feature. Small, focused commits are easier to review, understand, and revert than a single enormous commit containing unrelated work.
Write messages that describe the change in plain language. “Fix empty email validation” is more informative than “changes” or “update.” Some teams use a consistent format such as Conventional Commits, with prefixes like feat:, fix:, and docs:; follow the convention used by your project.
Before committing, review what you are about to save:
git status
git diff
git add path/to/file
git diff --staged
git commit -m "Explain the change"Avoid including generated files, temporary logs, local environment settings, credentials, or unrelated edits. A .gitignore file tells Git which untracked files to ignore, such as build output or local dependency directories. Ignoring a file does not remove it if it is already tracked, so check the repository status and project guidance.
A branch is a movable pointer to a commit. Branches let you work on a feature or bug fix without immediately changing the main line of development. They are lightweight, so creating a branch for a focused task is usually inexpensive.
A typical feature workflow looks like this:
git switch main
git pull
git switch -c feature/profile-page
# edit files and test your work
git add .
git commit -m "Add profile page"This assumes your main branch is called main and tracks the appropriate remote branch. If your project uses another default branch or a different update process, follow its instructions. Creating a branch does not automatically publish it to GitHub; use git push -u origin feature/profile-page when you are ready to share it.
Teams use different branching strategies. A simple GitHub Flow typically keeps a main branch and uses short-lived topic branches with pull requests. More elaborate release workflows may use release branches or long-lived development branches. Choose a process that matches the project's deployment needs; do not add branch complexity without a clear reason.
A merge conflict occurs when Git cannot safely combine changes automatically, often because two branches changed overlapping lines. A conflict is not proof that your repository is broken; it is a request for you to decide how the final version should look.
When a merge stops with conflicts, inspect the affected files and look for markers like these:
<<<<<<< HEAD
Current branch version
=======
Incoming branch version
>>>>>>> feature-branchEdit the file so it contains the intended final content, remove the conflict markers, and check the surrounding code. You may need to combine parts of both versions rather than choose one wholesale. Then stage the resolved file and complete the operation:
git status
git add path/to/conflicted-file
git diff --staged
git commitThe final command depends on the operation and Git's prompts: a merge commonly needs a merge commit, while a rebase uses git rebase --continue after staging resolutions. If you are unsure or the result is wrong, pause and read the status output before running more commands. Test the project after resolving conflicts because a syntactically clean merge can still introduce a logical bug.
Create or sign in to your account on GitHub. From the website, create a new repository, choose a clear name, and decide whether it should be public or private. Public repositories can be viewed by anyone; private repositories are restricted to you and authorised collaborators, subject to the platform's access rules.
If your local project already has commits, one straightforward approach is to create an empty repository on GitHub, then connect and push your local repository. GitHub will show a repository URL that you can use as the remote address:
git remote add origin https://github.com/USERNAME/REPOSITORY.git
git remote -v
git push -u origin mainReplace the example username, repository, and branch with your actual values. If you initialise the GitHub repository with a README or licence while your local repository already has a different history, you may need to fetch and reconcile the histories rather than pushing immediately. Follow GitHub's setup instructions for your exact situation.
A useful repository usually includes a README explaining the purpose, requirements, setup, usage, and contribution process. Add a licence if you intend to grant others permission to reuse the work, and include a suitable .gitignore. Never assume that making a repository private is a substitute for keeping secrets out of version control.
A remote is a named connection to another repository. When you clone a repository, Git usually names the source remote origin. You can check the configured remotes with git remote -v.
To start from an existing project, use the repository's Code menu to copy its clone URL, then run:
git clone https://github.com/OWNER/REPOSITORY.git
cd REPOSITORY
git statusTo share a branch you created locally, push it and set its upstream tracking branch:
git push -u origin feature/profile-pageDo not treat git pull as a magic repair command. It can produce conflicts if your local and remote work diverged. Check your working tree first, commit or safely preserve local changes, then fetch and integrate updates. The Git documentation explains remote tracking branches and the difference between fetch and pull in more detail.
A pull request (PR) is a proposal to merge changes from one branch into another. On GitHub, it gives contributors a place to explain a change, review a diff, discuss feedback, connect issues, and run automated checks before merging. It is a collaboration and review process, not a Git command itself.
A common workflow is to push a feature branch, open a pull request targeting the main branch, describe the problem and solution, and ask appropriate teammates to review it. Reviewers can comment on particular lines, request changes, or approve. The author can push additional commits to the branch and the pull request updates to show the new version.
Make pull requests easy to review. Use a specific title, explain why the change is needed, summarise what changed, provide test steps, and include screenshots when visual behaviour is relevant. Keep the scope manageable and mention limitations or follow-up work. Reviewers should focus on correctness, maintainability, security, tests, and whether the implementation solves the intended problem.
A pull request can use automated checks such as tests, linting, and builds. GitHub Actions can run these checks in response to pushes or pull request events. Branch protection and repository rules can require successful checks or reviews before merging. Set these controls to fit the project's risk and team size rather than assuming every repository needs the same rules.
A small personal project can use a simple routine: work on a short-lived branch, make focused commits, push the branch, open a pull request if review is useful, test, and merge. A team may add required reviewers, issue templates, automated checks, release tags, and deployment steps.
When contributing to a project you do not own, the workflow often involves a fork. A fork is your own GitHub copy of another repository. Clone your fork, create a branch, make and commit the changes, push the branch to your fork, then open a pull request to the original project. Read the project's CONTRIBUTING.md and issue instructions first; maintainers may specify tests, formatting, licence requirements, or sign-off rules.
Agree on a few team conventions: branch naming, commit message style, code formatting, required tests, review expectations, and who can merge. Keep these rules documented and proportionate. Consistency helps people work together, but an overly complicated process can slow down simple changes.
Git offers several ways to undo work, but they are not interchangeable. Choose based on whether the changes are unstaged, staged, committed locally, or already shared.
git restore path/to/file restores the file from the index. This discards those unstaged edits, so inspect or back them up first.git restore --staged path/to/file removes it from the staging area without normally discarding the working-tree edits.git show COMMIT_ID displays the commit and its changes.git revert COMMIT_ID creates a new commit that reverses the selected commit's changes.git reset can move the current branch and has different modes. It can discard work, so understand the mode and target before using it.Be especially careful with commands that rewrite history or remove files. Avoid force-pushing to shared branches unless your team explicitly agrees and you understand the consequences. When a command behaves unexpectedly, stop, run git status, and check the official documentation before trying more destructive commands.
Never commit passwords, API keys, private keys, access tokens, database credentials, production configuration files, or personal data. Put secrets in environment variables or an approved secret manager, and provide a safe example configuration file that contains placeholders rather than real values.
Add sensitive local files to .gitignore before they are staged. However, .gitignore does not remove secrets that have already been committed. If a credential is exposed, revoke or rotate it immediately, assess potential access, and follow the incident process. Deleting the file in a later commit does not erase it from the earlier repository history or any existing clones.
Use the minimum permissions collaborators need, enable multi-factor authentication on your hosting account, review repository visibility before sharing, and be cautious about third-party GitHub Apps and workflow permissions. Do not run code from an untrusted pull request or install an unfamiliar action without understanding what access it receives. For team projects, protect important branches and review dependency changes.
For large binaries or datasets, consider whether they belong in Git at all. Git is particularly effective for text files and source code. Git Large File Storage (Git LFS) can help with certain large-file workflows, but it has its own storage and bandwidth considerations. Keep secrets out of the repository regardless of which storage system you use.
A GitHub profile can help you share projects and demonstrate how you approach development. A strong portfolio is not simply a high commit count. It presents a few useful, understandable projects with clear documentation, meaningful commit history, tests where appropriate, and an explanation of the problem each project solves.
For each portfolio repository, include a concise README with a project overview, features, screenshots or a demo, technology stack, prerequisites, installation steps, usage instructions, and known limitations. Explain how to configure environment variables without publishing actual credentials. Add tests and a licence where relevant, and keep setup instructions working as the project evolves.
Pin your best repositories on your profile and make their purpose easy to understand. Contributing to open-source projects can also build experience with unfamiliar codebases, review feedback, and team conventions. Start with documentation improvements, reproducible bug reports, tests, or beginner-friendly issues, and read each project's contribution guidelines before opening a pull request.
Quality matters more than artificial activity. A smaller number of complete projects that you can explain confidently is generally more useful than many abandoned tutorial copies. Keep personal, client, and employer code separate, and never publish work unless you have permission to share it.
git status to see what is staged, modified, or untracked before committing.git add . can include files you did not intend to save. Inspect the staged diff.The fastest way to learn is to practise a complete cycle. Create a small command-line calculator, personal landing page, notes app, or another project that you can safely change. Then use the following steps to practise both local Git and GitHub collaboration.
git switch -c feature/add-instructions..gitignore, and confirm the project can be set up from a clean clone.Try making two branches that change the same line in a practice file so you can see a merge conflict safely. Resolve the conflict, inspect the final diff, and test the project. This exercise helps make conflicts less intimidating before you encounter them in a shared project.
| Task | Command |
|---|---|
| Check Git version | git --version |
| Start repository | git init |
| Copy remote repository | git clone URL |
| Check changes | git status |
| Stage a file | git add FILE |
| Review unstaged changes | git diff |
| Review staged changes | git diff --staged |
| Commit staged changes | git commit -m "Message" |
| View history | git log --oneline --graph |
| Create and switch branch | git switch -c BRANCH |
| Switch branch | git switch BRANCH |
| Combine a branch | git merge BRANCH |
| Download remote updates | git fetch |
| Integrate remote updates | git pull |
| Share commits | git push |
| See remote addresses | git remote -v |
| Reverse a commit | git revert COMMIT_ID |
Commands can behave differently depending on your current branch, working-tree state, and remote configuration. Use this table as a memory aid, not a substitute for reading command output. For commands that can discard work or rewrite history, check the documentation and make sure you understand the effect before proceeding.
No. Git is version control software that tracks changes and manages project history. GitHub is an online hosting and collaboration platform built around Git repositories. You can use Git locally without GitHub, and GitHub adds features such as pull requests, issues, access controls, and code review.
Yes. Git can track many text-based projects, including documentation and writing. Learning basic Git is useful even before you become an experienced programmer. A small practice repository is enough to learn commits, branches, and history.
Either is fine. Graphical tools can make history and branch changes easier to visualise, while the command line teaches portable skills and provides access to the full range of Git operations. Understanding the underlying concepts matters more than choosing one interface.
A commit records staged changes in your local repository. A push sends commits from your local repository to a remote repository such as GitHub. Your commits remain local until you push them or otherwise share the repository.
A branch provides a separate line of development for a feature, fix, or experiment. It lets you work without immediately changing the main branch. Once the change is ready, you can merge it locally or propose it through a pull request.
Repository visibility depends on the choice made when creating it and on organisation policies. Check the visibility setting before adding sensitive or proprietary work. A public repository can be viewed by anyone, and a private repository should still never contain credentials or secrets.
Often, if the file was committed previously, its contents may still be available in the repository history. The safest recovery method depends on whether the deletion is staged, committed, or pushed. Check status and history before using restore, reset, or other commands that may discard work.
Revoke or rotate the exposed key immediately and check whether it was accessed. Removing the file in a later commit is not enough because the key may remain in repository history, forks, logs, or clones. Follow your organisation's incident procedure and use the platform's guidance for sensitive-data removal if necessary.
Not every role requires a public GitHub profile, and some work cannot be shared for confidentiality reasons. However, a well-documented portfolio or thoughtful open-source contributions can help demonstrate skills. Focus on projects you can explain and maintain rather than chasing activity counts.
The best learning path is practical: create a repository, commit small changes, branch for a task, push to GitHub, and practise a pull request. Use the official documentation when a command's behaviour is unclear, especially before operations that could discard work or change shared history. With regular practice, Git and GitHub become a dependable part of your development workflow rather than a hurdle to getting started.