How to Integrate Replit with Git

If your Replit project was created fresh (not imported from a Git repository), it may not have Git initialized yet. Open the Git panel by clicking the branch icon in the left sidebar. If you see a button that says 'Initialize Git repository,' click it. Replit runs git init and creates a hidden .git directory in your project root. The Git panel now shows all your existing files as untracked (new) files. To make your first commit, configure your Git identity first — this information appears in every commit you make. Open the Shell (click the terminal icon) and run two commands: git config user.name 'Your Name' and git config user.email 'your@email.com'. Back in the Git panel, click 'Stage All' to stage all current files, or click the + button next to individual files to stage them selectively. Type a commit message in the text field — for a first commit, 'Initial commit' is conventional. Click the 'Commit' button. The commit is created and appears in the Git history. Your project is now tracked by Git and every future change will be visible as a diff.

1# Shell — initialize Git and make first commit
2git config user.name "Your Name"
3git config user.email "your@email.com"
4
5git init
6git add -A
7git commit -m "Initial commit"
8
9# View the commit
10git log --oneline

A remote repository is a hosted copy of your Git project on a service like GitHub or GitLab. Connecting Replit to a remote lets you push commits off-platform for backup, share code with collaborators, and trigger external CI/CD pipelines. Before connecting, you need a Personal Access Token from your Git host for authentication. On GitHub, go to Settings > Developer settings > Personal access tokens > Tokens (classic) and generate a token with repo scope. On GitLab, go to Avatar > Edit profile > Access Tokens and create a token with read_repository and write_repository scopes. Store the token in Replit Secrets as GITHUB_TOKEN or GITLAB_TOKEN (click the lock icon in the sidebar). Then, in the Replit Shell, add the remote URL with the token embedded: git remote add origin https://YOUR_USERNAME:${GITHUB_TOKEN}@github.com/username/repo.git for GitHub, or https://oauth2:${GITLAB_TOKEN}@gitlab.com/username/repo.git for GitLab. Using the shell variable ${GITHUB_TOKEN} means the actual token value does not appear in your shell history. Verify the remote is set with git remote -v. If you are connecting to an existing repository that already has commits, run git pull origin main --allow-unrelated-histories before pushing to merge the remote history with your local history.

1# Shell — add authenticated remote and push
2
3# GitHub
4git remote add origin https://YOUR_USERNAME:${GITHUB_TOKEN}@github.com/username/repo.git
5
6# GitLab
7git remote add origin https://oauth2:${GITLAB_TOKEN}@gitlab.com/username/repo.git
8
9# Verify remote
10git remote -v
11
12# Push to remote (first push sets upstream)
13git push -u origin main
14
15# Future pushes (after -u is set)
16git push

Branches let you develop features or fix bugs in isolation without affecting your main codebase. The main branch is typically called 'main' or 'master' and represents your production-ready code. Feature branches are created for each new piece of work and merged back to main when complete. To create a branch in Replit, you can use the Git panel's branch dropdown at the top of the panel — click the branch name, then click 'Create new branch,' type a name, and press Enter. Replit switches to the new branch automatically. Alternatively, use the Shell: git checkout -b feature/branch-name creates and switches to the branch in one command. All commits made while on this branch accumulate independently from main. When you are ready to merge, either use the Git panel's merge option or the Shell: git checkout main, then git merge feature/branch-name. If both branches modified the same lines of the same file, Git reports a merge conflict — the conflicting sections are marked in the file with <<<<<<, =======, and >>>>>>> markers. Open the conflicted file, choose which version to keep, remove the markers, save, and commit the resolution. Good branching practice means merging often and keeping branches short-lived to minimize conflict complexity.

1# Shell — branch workflow
2
3# Create and switch to new branch
4git checkout -b feature/add-authentication
5
6# ... make changes to files ...
7
8# Commit on the feature branch
9git add -A
10git commit -m "Add user authentication with JWT"
11
12# Push feature branch to remote
13git push origin feature/add-authentication
14
15# Switch back to main and merge
16git checkout main
17git merge feature/add-authentication
18
19# Push merged main to remote
20git push origin main
21
22# Clean up merged branch (optional)
23git branch -d feature/add-authentication
24git push origin --delete feature/add-authentication

One of the most practical benefits of Git is the ability to look back at the history of your code and recover previous versions when something goes wrong. In Replit, the Git panel shows a scrollable list of recent commits with messages and timestamps. Click any commit to see which files changed and what the diff looks like. For a more detailed view, use the Shell with git log --oneline to see a compact list of commits with their hash codes, or git log --oneline --graph --all for a visual branch graph. To recover a specific file from a previous commit, use git checkout COMMIT_HASH -- filename.js (substituting the actual commit hash and filename). This overwrites the current version of that file with the version from that commit. If you want to recover ALL files to a previous state (reverting the entire project), use git checkout COMMIT_HASH and examine the code, but be careful with git reset --hard COMMIT_HASH which permanently discards all commits after that point. A safer recovery approach is git revert COMMIT_HASH which creates a new commit that undoes the changes of the specified commit, preserving full history.

1# View commit history
2git log --oneline
3git log --oneline --graph --all  # Visual with branches
4
5# Recover a specific file from a past commit
6# Replace HASH with the commit hash from git log
7git checkout abc123f -- server.js
8
9# Recover all files to a previous state (non-destructive)
10git revert abc123f
11# Creates a new commit that undoes the specified commit
12
13# See what changed in a specific commit
14git show abc123f
15
16# Compare current version to a past commit
17git diff abc123f -- server.js

A .gitignore file tells Git to never track specified files or directories. This is essential for two reasons: keeping sensitive files (like .env files containing API keys) out of version control, and excluding large build artifacts (like node_modules/) that should be regenerated rather than stored in Git. Create a file called .gitignore in your project root. Each line specifies a pattern for files to ignore: exact filenames (like .env), directory names followed by a slash (like node_modules/), file extensions using wildcards (like *.log), or patterns with subdirectories (like **/temp/). Replit's Secret Scanner helps by detecting API keys pasted directly into code files and prompting you to move them to Secrets, but it does not prevent you from committing an .env file if you have one. The safest approach is to commit a .env.example file with placeholder values (like API_KEY=your_api_key_here) that shows collaborators what variables to set, without exposing any real credentials. If you accidentally committed a secret, remove it from Git history using git filter-branch or the BFG Repo Cleaner tool — simply deleting the file and committing does not remove it from Git history.

1# .gitignore — comprehensive example for Replit projects
2
3# Node.js
4node_modules/
5npm-debug.log*
6yarn-error.log
7.npm
8
9# Python
10__pycache__/
11*.pyc
12*.pyo
13*.egg-info/
14dist/
15build/
16.venv/
17venv/
18
19# Environment variables — NEVER commit these
20.env
21.env.local
22.env.*.local
23
24# Replit-specific (optional — some teams commit these)
25.replit
26replit.nix
27
28# Build output
29dist/
30build/
31.next/
32
33# OS files
34.DS_Store
35Thumbs.db
36
37# Logs
38*.log
39logs/