BLOG POSTS
    MangoHost Blog / How to Push an Existing Project to GitHub – Step by Step
How to Push an Existing Project to GitHub – Step by Step

How to Push an Existing Project to GitHub – Step by Step

Pushing an existing project to GitHub is one of those fundamental tasks that every developer encounters sooner or later, yet it’s surprisingly easy to mess up if you don’t know the proper sequence of commands. Whether you’ve been working on a local project for weeks or inherited code that needs proper version control, getting your files onto GitHub safely requires understanding Git’s workflow and avoiding common pitfalls that can cause headaches down the road. This guide will walk you through the complete process, from initializing your local repository to handling merge conflicts, plus we’ll cover troubleshooting steps for the most frequent issues you’re likely to encounter.

How Git Repository Initialization Works

Before diving into commands, it’s worth understanding what happens when you initialize a Git repository and connect it to GitHub. When you run git init in your project directory, Git creates a hidden .git folder that tracks all changes, branches, and metadata for your project. This local repository exists independently of any remote repository like GitHub.

The connection between your local repo and GitHub happens through remotes – basically named URLs that point to external repositories. The standard convention is to name your primary remote “origin,” but you can have multiple remotes pointing to different services or forks. When you push commits, Git sends your local changes to the specified remote repository, updating it with your latest work.

Prerequisites and Initial Setup

Before starting, make sure you have Git installed and configured with your credentials. You’ll also need a GitHub account and, ideally, SSH keys set up for authentication. If you’re still using HTTPS authentication, GitHub now requires personal access tokens instead of passwords.

Check your Git configuration:

git config --global user.name
git config --global user.email

If these aren’t set, configure them:

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

Step-by-Step Implementation Guide

Here’s the complete process for pushing an existing project to GitHub, broken down into manageable steps:

Step 1: Navigate to your project directory

cd /path/to/your/project

Step 2: Initialize Git repository

git init

This creates the .git directory and sets up the basic repository structure.

Step 3: Create a .gitignore file

Before adding files, create a .gitignore to exclude unnecessary files:

# Example .gitignore content
node_modules/
.env
*.log
.DS_Store
__pycache__/
*.pyc
build/
dist/

Step 4: Add files to staging area

git add .

Use git status to verify which files are staged:

git status

Step 5: Make your initial commit

git commit -m "Initial commit"

Step 6: Create repository on GitHub

Go to GitHub and create a new repository. Don’t initialize it with README, .gitignore, or license if you already have these files locally.

Step 7: Add remote origin

Copy the repository URL from GitHub and add it as a remote:

# For SSH (recommended)
git remote add origin git@github.com:username/repository-name.git

# For HTTPS
git remote add origin https://github.com/username/repository-name.git

Step 8: Push to GitHub

git push -u origin main

The -u flag sets the upstream branch, so future pushes only need git push.

Handling Common Branch Scenarios

GitHub now defaults to “main” as the primary branch, but older repositories might use “master.” Check your default branch:

git branch

To rename your branch to match GitHub’s default:

git branch -M main

If you’re working with an existing remote repository that has content, you might need to pull first:

git pull origin main --allow-unrelated-histories

Authentication Methods Comparison

Method Security Setup Complexity Expiration Best For
SSH Keys High Medium No expiration Regular development work
Personal Access Token High Low Configurable Automation, CI/CD
GitHub CLI High Low Token-based Command-line workflows

Real-World Use Cases and Examples

Scenario 1: Migrating a WordPress Plugin

When pushing an existing WordPress plugin to GitHub, your .gitignore should exclude WordPress core files if they’re in your directory:

# WordPress specific .gitignore
wp-config.php
wp-content/uploads/
.htaccess
wp-content/cache/

Scenario 2: Node.js Application

For Node.js projects, always exclude node_modules and include your package-lock.json:

git add package.json package-lock.json
git add src/
git commit -m "Add Node.js application with dependencies"

Scenario 3: Python Project with Virtual Environment

Python projects need specific exclusions:

# Python .gitignore additions
venv/
env/
.venv/
__pycache__/
*.egg-info/
.pytest_cache/

Troubleshooting Common Issues

Issue: “remote origin already exists”

This happens when you try to add a remote that’s already configured. Check existing remotes:

git remote -v

Remove and re-add the remote:

git remote remove origin
git remote add origin git@github.com:username/repository-name.git

Issue: “Updates were rejected because the remote contains work that you do not have locally”

This occurs when the remote repository has commits that aren’t in your local repo. You have several options:

# Option 1: Pull and merge
git pull origin main

# Option 2: Pull with rebase
git pull --rebase origin main

# Option 3: Force push (dangerous - only if you're sure)
git push --force-with-lease origin main

Issue: Large file upload errors

GitHub has a 100MB file size limit. For large files, use Git LFS:

git lfs install
git lfs track "*.zip"
git lfs track "*.tar.gz"
git add .gitattributes

Issue: Authentication failures

If you’re getting authentication errors, check your SSH key or token setup:

# Test SSH connection
ssh -T git@github.com

# For HTTPS, ensure you're using a token instead of password

Advanced Git Operations and Best Practices

Selective File Addition

Instead of using git add ., you can be more selective:

# Add specific files
git add src/ README.md package.json

# Add files interactively
git add -i

# Add parts of files
git add -p

Commit Message Best Practices

Follow conventional commit formats for better project management:

git commit -m "feat: add user authentication system"
git commit -m "fix: resolve memory leak in data processing"
git commit -m "docs: update API documentation"

Branch Strategy for Existing Projects

Consider creating a development branch immediately after your initial push:

git checkout -b develop
git push -u origin develop

Performance and Repository Management

For large existing projects, consider these optimization strategies:

  • Use git add -A instead of git add . to handle file deletions properly
  • Configure Git to handle line endings correctly with git config core.autocrlf
  • Set up .gitattributes for binary file handling
  • Use shallow clones for deployment: git clone --depth 1

Monitor your repository size and consider cleaning up history if needed:

# Check repository size
git count-objects -vH

# Clean up unnecessary files
git gc --aggressive --prune=now

Integration with Development Workflows

Once your project is on GitHub, consider setting up continuous integration. For projects deployed on VPS instances from MangoHost VPS services, you can automate deployments using GitHub Actions:

# Example GitHub Actions workflow
name: Deploy to VPS
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Deploy to server
      run: |
        # Your deployment commands here

For larger applications requiring more resources, dedicated servers provide the performance needed for complex CI/CD pipelines and multiple environment deployments.

The key to successfully pushing existing projects to GitHub lies in understanding the Git workflow, preparing your files properly, and knowing how to handle the inevitable issues that arise. Take time to set up your .gitignore correctly, choose the right authentication method for your workflow, and don’t rush the initial commit – it’s much easier to exclude files from the start than to remove them from Git history later. With these foundations in place, you’ll have a solid version control setup that scales with your project’s growth.



This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.

Leave a reply

Your email address will not be published. Required fields are marked