This repository showcases a modular shell scripting approach for automating Linux service setup using shared common functions. Reusable logic is centralized in common.sh and sourced by individual scripts, enabling clean code reuse, consistency, and easier maintenance. The structure emphasizes DRY principles, service isolation, and production-style

I built a centralized Linux repository server using HTTP, FTP, and NFS protocols. This solution enables offline package installation across multiple systems and improves deployment efficiency in restricted network environments. I also automated the setup using shell scripting.

Comprehensive Critical Thinking Project Report: Enterprise-Grade Source Code Management Migration Task 1: Comparative Evaluation — SVN vs. Git The transition from Apache Subversion (SVN) to Git is a strategic imperative driven by our team’s shift to a fully distributed, remote work model. Centralized Architecture (SVN) Drawbacks Single Point of Failure (SPOF): SVN relies entirely on a centralized repository server. If the server goes down, all developer operations (including viewing history, committing code, and branching) are instantly paralyzed. Network Dependency: Every operation requires a network request to the primary server. For remote developers with variable internet connectivity, this introduces latency and delays integration. Distributed Architecture (Git) Advantages Local Redundancy: Git operates on a peer-to-peer model. Cloning a repository duplicates the entire project database, including its complete historical log, onto the developer's local machine. High Performance: Because the entire commit history resides locally, actions like committing, branching, and reviewing logs are executed instantly on local disk storage. Task 2: Standardizing the Distributed Git Workflow To maintain code quality and ensure frictionless parallel development across a remote engineering team, we have instituted a strict Feature Branching Workflow. Figure 1: Git Feature Branching Architecture Flow. Source: Galeanu Mihai / Getty Images 1. Isolated Feature Development Developers are strictly prohibited from pushing code directly to the upstream main branch. All work must occur in dedicated feature branches named with the convention feature/ or bugfix/. To synchronize the local workstation and instantiate a feature branch, the following sequence is executed: Bash # Ensure local repository is synchronized with the upstream remote git checkout main git pull origin main # Provision and pivot to an isolated workspace git checkout -b feature/user-login 2. Peer Review and Quality Gates via Pull Requests Once a feature is completed, the developer pushes the local branch to the remote origin hosting provider (GitHub) and initiates a Pull Request (PR) against the main branch. The Review Gate: Direct self-merging is blocked. At least one peer engineer must review the diff and provide an explicit approval signature. Upstream Synchronization: If the remote main branch advances during local development, the developer must pull the latest upstream updates into their branch to address integration problems locally before merging: Bash git pull origin main Task 3: Continuous Integration & Automated Verification To prevent regression and eliminate the risk of breaking our production environments, we leverage automation via GitHub Actions. Figure 2: GitHub Actions Automated CI/CD Pipeline. Source: Medium We have implemented a CI/CD pipeline configuration file located at .github/workflows/test-and-deploy.yml: YAML name: Test and Deploy Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] jobs: build-and-test: runs-on: ubuntu-latest steps: - name: Checkout Source Code uses: actions/checkout@v4 - name: Initialize Environment Runtime uses: actions/setup-node@v4 with: node-version: '20' - name: Dependency Installation run: npm ci - name: Execute Automated Test Suite run: npm test - name: Deploy to Staging Server if: github.ref == 'refs/heads/main' && github.event_name == 'push' run: ./scripts/deploy.sh Task 4: Hardening Repository Security and Data Integrity Operating a remote engineering team introduces unique security vectors. We address these threats through cryptographic enforcement and structural access controls. Branch Protection Policies We have configured strict branch protection rules within the repository settings for the main branch: Require Pull Request Reviews: Blocks direct commits and forces peer review sign-offs. Require Status Checks: Demands that our automated GitHub Actions workflow passes perfectly before a merge is unlocked. Block Force Pushes: Prevents users from overwriting or altering historical commit data on the production line. Cryptographic Identity Management To prevent identity spoofing and secure data transit, we have eradicated password authentication in favor of public-key cryptography: SSH (Secure Shell) Transport: All network communication with GitHub is restricted to cryptographic SSH connections. Developers generate an key pair locally and register their public key to authenticate code pushes securely. Commit Signing via GPG/SSH: To guarantee authorship integrity, developers must sign their commits using cryptographic keys. This adds an immutable signature to each commit hash, displaying a "Verified" badge on GitHub. Bash # Signing a commit cryptographically using local keys git commit -S -m "Feat: Implement authenticated session storage" Task 5: Incident Report — Resolving Merge Conflicts The Problem Incident During a concurrent update cycle, two developers simultaneously modified the same structural block inside index.html on their respective branches. When Developer B attempted to integrate their branch into main, Git detected overlapping alterations and blocked the automated merge, throwing a merge conflict error. Figure 3: Anatomy of Git Merge Conflict Markers. Source: Stat@Duke Step-by-Step Resolution Execution Bash # Step 1: Sync the local environment with the authoritative upstream branch git checkout main git pull origin main # Step 2: Switch back to the working feature branch and merge main to encounter the conflict safely git checkout feature/ui-headings git merge main Upon attempting the merge, Git inserts structural conflict markers directly into the conflicting file as illustrated in Figure 3: HTML <<<<<<< HEAD <h1>Welcome back, Author Premium Client</h1> ======= <h1>Welcome to our Distributed DevOps Dashboard</h1> >>>>>>> main Resolution and Code Stabilization Code Inspection: Open the broken file in a code editor and evaluate the conflicting logic lines between the HEAD marker and the commit hash pointer. Conflict Cleanup: Manually delete the Git conflict anchors (<<<<<<<, =======, >>>>>>>), keep the correct structural header lines, and save the source file cleanly. Final Stage and Distribution: Bash # Stage the manually reconciled file git add index.html # Record the merge resolution commit git commit -m "Fix: Reconcile heading conflict in index.html, combining dashboard headers" # Safely upload the stabilized branch to the remote host git push origin feature/ui-headings