Use this guide when you have a project folder with code and no version control yet, or you want to start a new project the right way. Have Git installed, your project folder ready and an account on a Git hosting service if you want an online backup.
Step by step
Configure Git once
Open a terminal and set your name and email with git config --global user.name and git config --global user.email. This labels your commits. You only need to do this once per computer.
Initialise the repository
In your project folder, run git init to create a new repository. Git now tracks this folder, but nothing is saved until you commit. Run git status to see which files Git has noticed.
Add a .gitignore file
Create a file called .gitignore and list files and folders that should not be tracked, such as .env files, dependency folders, build output and editor settings. Templates for most languages are widely available. Do this before your first commit so secrets are never recorded.
Make your first commit
Run git add . to stage your files, then check git status to confirm nothing sensitive is included. Run git commit -m followed by a short message such as Initial project setup. Each commit is a snapshot you can return to.
Connect a remote backup
Create an empty repository on your Git hosting service, preferably private to start with. Follow its instructions to add it as a remote with git remote add origin, then push with git push. Your code is now backed up off your computer.
Adopt a simple daily routine
Commit small, related changes with clear messages describing what and why. Use a separate branch for experiments and merge when they work. Push at the end of each working session.
Ready-to-use checklist
- Git installed and name and email configured
- Repository initialised
- .gitignore created before first commit
- Secrets and .env files ignored
- First commit made
- Private remote repository created
- Code pushed to remote
- Branch used for experiments
Practical tips
- Write commit messages in the form add, fix or change followed by what, so your history reads like a log.
- Run git status before every commit to catch files you did not mean to include.
- Many code editors have built-in Git tools, which make staging and viewing changes easier for beginners.
Common problems
I accidentally committed a password or API key.
Revoke or change the secret immediately, as removing it from history is not enough if it was pushed. Then remove it from the code, add the file to .gitignore and commit again.
Git says there is a merge conflict.
Open the listed files and look for the conflict markers showing both versions. Keep the correct code, remove the markers, then stage and commit the result.
Push is rejected because the remote has changes.
Run git pull to bring in the remote changes first, resolve any conflicts, then push again. Avoid force-pushing unless you fully understand the consequences.