Using One GitHub Project on Two Computers

GitHub becomes especially useful when you work on the same project from more than one computer.

You might use a portable laptop during the day and a larger computer at home. Instead of copying the project back and forth with a USB drive, you can use GitHub as the central location for the project’s code.

The basic idea is simple:

• Each computer has its own local copy of the project.
• Git records the changes made on each computer.
• GitHub stores the shared online copy.
• You push changes to GitHub from one computer.
• You pull those changes from GitHub onto the other computer.

Before You Begin

You will need:

• A GitHub account
• Git installed on both computers
• A GitHub repository for the project
• A local copy of the project on each computer

For a personal project that is not ready to be shared publicly, create a private GitHub repository.

The First Computer

Suppose the project already exists on your first computer.

Open a terminal in the project folder. In Windows, you can use PowerShell, Command Prompt, Windows Terminal, or the terminal built into Visual Studio Code.

If the project is not already using Git, initialize it:

git init

Add the project files:

git add .

Create the first commit:

git commit -m "Initial project commit"

GitHub will provide instructions for connecting the local project to the new online repository. The commands will look similar to these:

git branch -M main
git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
git push -u origin main

Replace YOUR-USERNAME and YOUR-REPOSITORY with the correct GitHub account and repository names.

After the push is complete, the project’s committed files will appear on GitHub.

The Second Computer

On the second computer, you normally do not create another empty project folder and copy files into it manually.

Instead, you clone the repository from GitHub.

Open a terminal in the folder where you want the project to be stored, then run:

git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git

Git will create a new project folder containing the files and the project’s Git history.

You can then open that folder in your code editor.

Your Normal Daily Workflow

The most important habit is to synchronize the project before and after each work session.

Before beginning work on either computer, open the project folder and run:

git pull

This downloads and applies the latest changes from GitHub.

After making and testing your changes, review the project status:

git status

Add the changed files:

git add .

Create a commit with a meaningful message:

git commit -m "Add initiative location editing"

Then upload the commit to GitHub:

git push

The next time you use the other computer, begin with:

git pull

The Safe Two-Computer Routine

A good routine is:

• Pull before you start.
• Make one logical group of changes.
• Test the changes.
• Commit the changes.
• Push before leaving the computer.
• Pull when you move to the other computer.

This routine greatly reduces the chance of conflicts or missing work.

A Practical Example

Suppose you work on a Flask project using a portable laptop at a coffee shop.

You begin by pulling the latest version:

git pull

You update a template, test the page, and confirm that it works.

You then save the change:

git add .
git commit -m "Add Edit Note button to linked locations"
git push

Later, at home, you open the same project on the second computer and run:

git pull

The template change is now available on the home computer.

Do Not Work Independently on Both Computers

Problems can occur if you make changes on one computer, forget to push them, and then make different changes to the same files on the second computer.

Git may then report a conflict because it cannot safely decide how the two versions should be combined.

The easiest prevention is simple:

• Push your completed work before switching computers.
• Pull before editing on the other computer.

It is also helpful to avoid leaving unfinished changes on both computers at the same time.

What If You Forget to Pull?

If GitHub contains newer changes and you try to push from an older local copy, Git may reject the push.

You may see a message explaining that the remote repository contains work that you do not have locally.

In many cases, the next step is:

git pull

After Git combines the changes, you can test the project and push again.

If both computers changed the same part of the same file, Git may ask you to resolve a merge conflict manually.

Understanding Merge Conflicts

A merge conflict does not mean the project is ruined. It means Git found two competing changes and needs you to choose the correct result.

A code editor such as Visual Studio Code can show both versions and help you decide whether to:

• Keep the local change
• Keep the incoming change
• Keep both changes
• Edit the file into a combined final version

After resolving the conflict, save the file, test the project, add the corrected file, and create a new commit.

Use Clear Commit Messages

Commit messages should briefly explain what changed.

Examples include:

• Fix spacing in location names
• Add case studies to location detail page
• Update organization search
• Add notes to initiative-location links

A message such as changes or update is less helpful because it does not explain what the commit contains.

Files That May Differ Between Computers

Some files should not necessarily be synchronized through GitHub.

Examples include:

• Python virtual-environment folders
• Temporary files
• Editor-specific settings
• Passwords and secret keys
• Local environment files
• Large generated files
• A live local database

A .gitignore file tells Git which files and folders it should ignore.

For a Python project, part of the file might look like this:

venv/
.venv/
__pycache__/
*.pyc
.env

Be Careful with SQLite Databases

A SQLite database is stored in a single file, which may make it appear easy to synchronize through GitHub.

However, a database file can change frequently and may contain important local data. Two computers editing separate copies of the same database can create confusion and increase the risk of losing changes.

A safer approach is to keep one authoritative database on the main home computer.

The portable computer can be used mainly for:

• Writing Python code
• Editing templates
• Improving styles
• Testing features with sample data
• Making small temporary test records

Substantial content entry and permanent database changes can remain on the home computer.

If the database structure must change, use a migration script or a carefully documented SQL file. That script can be stored in GitHub and then run on the home computer.

GitHub Is Not Your Only Backup

GitHub provides an online copy of committed and pushed files, but it should not be your only backup.

GitHub does not protect work that has not yet been committed and pushed. It may also exclude database files, uploaded files, local settings, and other important project material.

A complete backup plan may include:

• The local project copy
• The private GitHub repository
• Regular backups of the database
• Copies of uploaded files
• An external drive or another backup service

A Simple Rule to Remember

When using one GitHub project on two computers, remember this sequence:

Pull
Work
Test
Commit
Push

Then repeat the same sequence on the other computer.

Once this habit becomes routine, GitHub provides a safe and organized way to continue the same project wherever you are working.