Replit creates web applications from natural language prompts quickly and easily. Everyone's doing it, so why don't you?

If you are learning how to code, building small web apps for personal use or for clients, you will need to save a local version of the files replit generates for you and back it up to github.

Here is a diagram of how Git and commits work locally and remotely.

This is how you do it....

Step 1: Download source files from replit.

Click the file icon at the top left in replit.
Click the Kebab menu ⋮
Click Download as Zip.

Step 2: Extract project files to your project folder.

Drag and drop zip file from Downloads folder to your project folder.
Open zip file.
Extract files locally.

Step 3: Create a new repository on Github.

Step 4: Initialize Git and Commit main branch.

Git Repository Setup
    git clone https://github.com/krashautomation/ReplitSourceControl.git
  
    git branch -M main
  
    git push -u origin main
  
    These commands will:

    1. Clone the repository

    2. Rename the default branch to "main"

    3. Push your changes to the remote repository

Step 5: Create a README.md File Using Gemini (or your favorite AI Coding Tool)

Start gemini with command Gemini in your project folder.
Enter this prompt: Scan this project. Then create a ReadMe file according to the highest standards.

Step 6: Add File to Main Branch and Commit

Uploading New Files to Git Repository

1. Navigate to your local repository

cd /path/to/your/repository

2. Check your file status

git status

You should see your new file listed as "untracked"

3. Stage your new file

git add filename.ext
# Or to add all new files:
git add .

4. Commit your changes

git commit -m "Added new file with description"

5. Push to remote repository

git push origin main
# If you haven't set upstream branch:
git push -u origin main

Pro Tip:

You can combine steps 3-5 into one command if you have git-together installed:
git together "Added new file"

Note on Documenting Your commits:

Professional Git Commit Standards

The 7 Rules of Atomic Commits

One logical change per commit - Never mix unrelated changes
Small, focused commits - Easy to review and revert
Complete & functional - Each commit should work independently
Tested code - Don't commit broken functionality
Follow team conventions - Consistency across the project
Meaningful messages - Explain "why" not just "what"
Reference issues - Link to tickets or discussions

Commit Message Structure

<type>(optional scope): <subject>

<body>

<footer>

1. Type (Required)

feat: New feature

fix: Bug fix

docs: Documentation

style: Formatting

refactor: Code restructuring

test: Test-related

chore: Maintenance

2. Subject (Required)

50-72 characters max
Imperative mood ("Add" not "Added")
No period at the end
Lowercase (except proper nouns)

Good Examples:

feat: add dark mode toggle fix(login): validate email format refactor(api): simplify auth middleware

3. Body (Optional)

72 characters per line
Explain "why" not "what" (the code shows what)
Use bullet points if needed
Reference previous commits if applicable

4. Footer (Optional)

Reference issues (e.g., "Closes #123")
Breaking changes (start with "BREAKING CHANGE:")
Co-authored-by for pair programming

Complete Example:

feat(auth): implement JWT authentication

- Add JWT token generation on login
- Create auth middleware for protected routes
- Include token refresh endpoint

Closes #123
BREAKING CHANGE: Requires new JWT_SECRET env variable
Co-authored-by: Jane Doe <jane@example.com>

Pro Tips

Interactive staging

Use git add -p to review hunks before committing

Commit templates

Configure .gitmessage for team consistency

Linting commits

Use commitlint to enforce standards

Key Professional Commit Standards

Atomic Commits

Each commit represents one logical change

Conventional Commits

Type-scope-subject structure

Message Format

Proper capitalization, length, and mood

Content Hierarchy

Subject, body, footer separation

Issue Tracking

Proper reference to tickets/PRs

Team Consistency

Following shared conventions

Tooling

Interactive staging, templates, linters

This Format Ensures:

Machine-readable commit messages
Easy generation of changelogs
Better code archaeology
More effective code reviews
Professional collaboration standards

Pro Tip:

Use commitlint with husky to automatically enforce these standards on every commit.

Guide to Commitlint and Husky

Commitlint + Husky: Professional Git Hooks

What Are They?

Husky

Git hook manager that lets you run scripts:

Before commits (pre-commit)
Before push (pre-push)
When preparing commit messages (commit-msg)

Commitlint

Linter for commit messages that:

Validates against Conventional Commits
Ensures consistent formatting
Prevents bad commit messages

Installation

1. Install packages

npm install --save-dev @commitlint/cli @commitlint/config-conventional husky

or using yarn:

yarn add --dev @commitlint/cli @commitlint/config-conventional husky

2. Configure commitlint

Create commitlint.config.js:

module.exports = {
  extends: ['@commitlint/config-conventional']
};

3. Set up husky

Add to your package.json:

"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

For husky v5+ (recommended), run:

npx husky install
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

How It Works

When you run git commit, husky triggers
Commitlint checks your message against the conventional commit rules
If invalid, the commit is rejected with an error message
If valid, the commit proceeds normally

Example Error

⧗   input: my bad commit message
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings

Advanced Configuration

Custom Rules

Modify commitlint.config.js:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      'feat', 'fix', 'docs', 'style', 'refactor', 
      'test', 'chore', 'revert', 'ci', 'perf'
    ]],
    'subject-case': [2, 'always', 'sentence-case'],
    'body-max-line-length': [1, 'always', 100]
  }
};

Pro Tips

Combine with lint-staged for pre-commit code checks
Add to CI pipeline as an extra validation layer
Use commitizen for interactive commit message creation

Key Features Explained

Husky

Manages Git hooks (pre-commit, pre-push, etc.)
Runs automatically during Git operations
Ensures checks happen before bad commits/pushes

Commitlint

Validates commit message structure
Enforces Conventional Commits standard
Provides clear error messages when rules are violated

Workflow

Installation via npm/yarn
Simple configuration file
Automatic hook setup
Custom rule support

Benefits

Consistent commit history
Automatic changelog generation
Better team collaboration
Professional-grade commit hygiene

How It Works Together

$ git commit -m "add login button" ✖ type may not be empty [type-empty] $ git commit -m "feat: add login button" ✓ Commit successful

Essential Git Terms Explained

Stage / Staging

Preparing changes for commit by adding them to the index

git add filename.txt
# Stages specific file

git add .
# Stages all changed files

Commit

Saves staged changes to the local repository with a message

git commit -m "Add login functionality"
# Records changes with descriptive message

Clone

Creates a local copy of a remote repository

git clone https://github.com/user/repo.git
# Copies entire repository to your machine

Branch

Isolated line of development that diverges from main code

git branch feature/login
# Creates new branch

git checkout feature/login
# Switches to branch

Origin

Default name for the remote repository you cloned from

git remote -v
# Shows your remote repositories

git push origin main
# Pushes to the 'origin' remote

Push

Uploads local commits to a remote repository

git push origin feature/login
# Sends branch commits to remote

Pull

Downloads changes from remote and merges them locally

git pull origin main
# Fetches and merges remote changes

Workflow Summary

Clone

Get the repo

Branch

Create feature

Stage

Add changes

Commit

Save changes

Push

Upload changes

Working with Replit, Github & Gemini for Source Control

Step 3: Create a new repository on Github.

Step 4: Initialize Git and Commit main branch.

Git Repository Setup

Step 5: Create a README.md File Using Gemini (or your favorite AI Coding Tool)

Step 6: Add File to Main Branch and Commit

Uploading New Files to Git Repository

1. Navigate to your local repository

2. Check your file status

3. Stage your new file

4. Commit your changes

5. Push to remote repository

Pro Tip:

Note on Documenting Your commits:

Professional Git Commit Standards

The 7 Rules of Atomic Commits

Commit Message Structure

1. Type (Required)

2. Subject (Required)

Good Examples:

3. Body (Optional)

4. Footer (Optional)

Complete Example:

Pro Tips

Key Professional Commit Standards

Atomic Commits

Conventional Commits

Message Format

Content Hierarchy

Issue Tracking

Team Consistency

Tooling

This Format Ensures:

Pro Tip:

Commitlint + Husky: Professional Git Hooks

What Are They?

Husky

Commitlint

Installation

1. Install packages

2. Configure commitlint

3. Set up husky

How It Works

Example Error

Advanced Configuration

Custom Rules

Pro Tips

Key Features Explained

Husky

Commitlint

Workflow

Benefits

How It Works Together

Essential Git Terms Explained

Stage / Staging

Commit

Clone

Branch

Origin

Push

Pull

Workflow Summary

Comments

Post a Comment