If you're building web applications, version control isn't optional—it's essential. Without proper version control, you're one mistake away from losing hours of work, unable to track changes, and incapable of collaborating effectively with other developers.

Part 1: Understanding Your Server File System

Navigating the NonBioS File Browser

Before we can set up version control, you need to understand where your code lives on the server.

Accessing the File Browser:

1. Navigate to your "Default Sandbox" Settings
2. Click on the "File Browser" tab
3. Note your access URL (typically on port 8080)
4. Log in with your sandbox credentials

The file browser provides a clean, intuitive interface for navigating your entire Linux file system without needing SSH or FTP clients.

Key Directory Structures Explained

Understanding Linux directory structure is crucial for web development:

/home/nonbios/ - Your development workspace

• This is where your code lives during development
• Contains your project folders and working files
• The health-tracker folder contains all our application files

/var/www/html/ - Apache web server document root

• This is where Apache serves files from
• When you deploy on NonBioS, code is copied from /home/nonbios/ to /var/www/html/
• This is the production location for your live application

/etc/apache2/ - Web server configuration

• Contains Apache virtual host configurations
• The sites-enabled folder has your domain configurations
• Includes SSL certificate configurations from Let's Encrypt

Downloading Your Code for Local Backup

The file browser makes it easy to create local backups:

1. Navigate to your project folder (/home/nonbios/health-tracker)
2. Select the folder
3. Click the download button
4. Choose your preferred compression format (ZIP, TAR, etc.)

This gives you a manual backup, but it's not a sustainable solution for ongoing development. That's where Git comes in.

Part 2: Setting Up Git Version Control

Why Git Over Manual Backups?

Manual file downloads have serious limitations:

• No version history or change tracking
• No ability to roll back to previous versions
• No collaboration capabilities
• Easy to forget or skip backups
• No merge conflict resolution

Git solves all these problems by providing:

• Complete version history with commit messages
• Easy rollback to any previous state
• Branch-based development workflow
• Collaboration tools for team development
• Industry-standard version control

The beauty of using NonBioS AI is that you don't need to remember complex Git commands or workflows. You simply tell NonBioS to "check in the health tracker application to GitHub," and it automates the entire setup process for you.

However, it's helpful to understand what NonBioS is doing behind the scenes—especially when you need to debug issues or want to perform Git operations manually in the future.

Here's what NonBioS automates when you ask it to set up Git:

Step 1: Initialize the repository‍

NonBioS navigates to your project directory and runs:

‍cd /home/nonbios/health-tracker
git init

This creates a hidden .git folder that tracks all your version history.

Step 2: Create a .gitignore file

‍NonBioS automatically generates a .gitignore file to exclude unnecessary files from version control—things like system files, logs, temporary files, and sensitive configuration data that shouldn't be in your repository.

Step 3: Configure Git user

‍NonBioS sets up your Git identity:

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

This ensures all your commits are properly attributed to you.

Step 4: Add files and create initial commit

‍NonBioS stages all your files and makes the first commit:

git add .
git commit -m "Initial commit: Health Tracker Application"

‍

Step 5: Create README.md

‍NonBioS can even generate a professional README file with your project description, features list, and file structure documentation.

At this point, you have local version control fully configured, but your code isn't backed up remotely yet. That's where GitHub comes in.

The key advantage here is that NonBioS handles all these steps automatically. You don't need to remember the exact commands or syntax. But knowing what's happening under the hood means you can troubleshoot if something goes wrong, or perform these operations manually when needed.

‍

Understanding GitHub Personal Access Tokens

GitHub no longer accepts passwords for Git operations. Instead, you need to create a Personal Access Token (PAT) for authentication.

How to create a GitHub Personal Access Token:

1. Go to GitHub Settings → Developer Settings
2. Click "Personal access tokens" → "Tokens (classic)"
3. Click "Generate new token"
4. Give your token a descriptive name (e.g., "health-tracker-deployment")
5. Set an expiration date (7 days, 30 days, or custom)
6. Select scopes - at minimum, you need:
   • repo - Full control of private repositories
   • workflow - Update GitHub Action workflows (if needed)
7. Click "Generate token"
8. CRITICAL: Copy the token immediately - you won't be able to see it again

Security Best Practices for Access Tokens

• Never share your tokens publicly
• Don't commit tokens to your repository
• Use tokens with minimal required permissions
• Set reasonable expiration dates
• Revoke tokens you're no longer using
• Use different tokens for different projects

Pushing Your Code to GitHub

With your access token ready, you can now ask NonBioS to push your code to GitHub. NonBioS will automate this process using the GitHub API:

1. Creates a new repository using your GitHub token
2. Adds the remote origin with authentication
3. Pushes your initial commit to the master/main branch

Best Practices: Organizing Your Development Workflow

The Multi-Chat Strategy

Here's a pro tip that will keep your development workflow clean and organized:

Create separate NonBioS chat sessions for different purposes:

• One chat for feature development
• One chat for GitHub/version control operations
• One chat for deployment and server configuration

Why this works:

‍All NonBioS chats run on the same virtual machine, so they all access the same file system. This means:

• Your development chat stays focused on coding
• Your GitHub chat handles all version control operations
• Each chat maintains context relevant to its purpose
• You can switch between tasks without cluttering your conversation history

This organizational strategy helps the AI maintain better context and give more relevant assistance for each specific task.

‍