Project 2: Git Collaboration Simulation

The diagram below represents the Git data flow architecture showing transitions between local files, staging tables, databases, and remote repositories, alongside the branches lifecycle.

STEP 1

Configure Git Global Identity Settings

Configure default commit descriptors to stamp repository updates with valid email credentials and default editors.

$ git config --global user.name "Your Name"

This command sets the author name for your commits, associating your identity with the changes you write.

$ git config --global user.email "your.email@example.com"

This command defines your official email address, ensuring your commits are linked to your GitHub profile.

$ git config --global init.defaultBranch main

This command configures Git to automatically set the primary branch name to main when initializing new repositories.

$ git config --global core.editor nano

This command sets nano as the default text editor for drafting merge conflict commit messages.

$ git config --list

This command queries and lists all active Git settings, verifying that your configuration matches expected parameters.

STEP 2

Initialize a Local Git Repository

Establish an empty local tracking database inside a project directory and execute your initial commit.

$ mkdir -p ~/Projects/git-lab && cd ~/Projects/git-lab && git init

This command creates a project folder, moves your terminal context into it, and initializes an empty local Git repository.

$ echo "# Git Collaboration Lab" > README.md

This command writes a baseline markdown header block into a README.md file, establishing a foundation for documentation tracking.

$ git add README.md && git commit -m "initial commit: create project readme"

This command stages README.md and records your changes in the local repository database with a descriptive commit message.

STEP 3

Simulate Branching and Feature Implementation

Create a feature branch, isolate development modifications from the stable main lineage, and commit code changes.

$ git branch feature/login && git checkout feature/login

This command creates a new feature branch and switches your workspace context to it, isolating your development work.

$ echo "const login = () => { console.log('Auth login UI version'); };" > auth.js

This command writes a Javascript login function code block inside a new file named auth.js to simulate feature implementation.

$ git add auth.js && git commit -m "feat: implement auth login routine"

This command stages auth.js and commits the new feature code to the history of the feature/login branch.

STEP 4

Trigger and Resolve a Merge Conflict

Return to the main branch, make conflicting code updates, attempt a merge, and resolve the resulting merge flags manually.

$ git checkout main

This command returns your local workspace back to the main branch to write conflicting baseline updates.

$ echo "const login = () => { console.log('Auth login database version'); };" > auth.js

This command writes a conflicting Javascript function body to auth.js on the main branch, setting up the conflict.

$ git add auth.js && git commit -m "fix: set standard auth login database"

This command stages and commits the conflicting auth.js file to main, preparing the branch histories to collide during a merge.

$ git merge feature/login

This command attempts to merge the feature branch into main, which fails and triggers a merge conflict because both branches contain different changes to the same lines of auth.js.

1. Open auth.js in your editor. Notice the conflict markers:

<<<<<<< HEAD
const login = () => { console.log('Auth login database version'); };
=======
const login = () => { console.log('Auth login UI version'); };
>>>>>>> feature/login

2. Edit the file to merge both versions, resolving the conflict. Save the file:

const login = () => {
  console.log('Auth login UI and Database Integrated');
};

$ git add auth.js && git commit -m "merge: resolve auth login conflicts between main and feature/login"

This command stages the resolved file and commits the changes, completing the merge and resolving the conflict.

STEP 5

Synchronize Workspaces with Remote GitHub Repositories

$ git remote add origin git@github.com:yourusername/git-lab.git

This command maps your local repository to a remote repository URL on GitHub, naming the link "origin".

$ git push -u origin main

This command uploads your local commit history to the remote main branch and configures tracking tracking flags.

The diagram below highlights the automated workflow script. The script builds local branches, runs program conflicts, resolves edits programmatically, and prints status reports.

To automate the verification of Git collaborations and branching conflicts, we will write a simulation script. Below is a step-by-step breakdown of how this script is constructed, followed by the final combined script.

Step-by-Step Script Construction

Step 1

Define Shebang & Workspace Environment Variables

Setup standard script safety flags and allocate repository folders.

#!/usr/bin/env bash set -euo pipefail LAB_DIR="${HOME}/Projects/git-lab"

This sets the bash shell execution driver, enforces strict exit-on-error behaviors, and allocates the git project target directory inside shell memory.

Step 2

Initialize Repository and Configure Local Identities

Create the directory structure, switch directory context, run repository initialization, and set configuration properties.

mkdir -p "${LAB_DIR}" && cd "${LAB_DIR}" git init git config user.name "Local Student" git config user.email "student@devops-node"

This command creates the lab directory, navigates into it, initializes a new Git database, and sets the commit author details locally.

Step 3

Create Base Files & Establish Initial Commit

Write standard project README documentation, stage it, and commit it to the main repository lineage.

echo "# Git Lab Repository" > README.md git add README.md git commit -m "initial commit: create project readme"

This writes baseline headers into README.md, stages the file, and commits the initial version to the repository.

Step 4

Isolate Feature Branches and Commit Modifications

Create a feature branch, create files with specific source lines, and commit them.

git checkout -b feature/login cat <<EOF > auth.js const login = () => { console.log('Auth login UI: Feature Branch Version'); }; EOF git add auth.js git commit -m "feat: implement auth login routine"

This creates and switches to the feature/login branch, writes JavaScript code to auth.js, stages it, and commits it.

Step 5

Trigger Branch Conflict on Main

Switch back to main and write conflicting changes to the same file, committing the updates.

git checkout main cat <<EOF > auth.js const login = () => { console.log('Auth login database: Main Branch Version'); }; EOF git add auth.js git commit -m "fix: set standard auth login database"

This switches your workspace context back to main, writes a conflicting function body to auth.js, and commits the changes.

Step 6

Attempt Merge and Resolve Programmatically

Attempt to merge the feature branch, handle the expected conflict failure, and write the resolved code, finalizing the merge commit.

git merge feature/login || echo "Merge conflict detected as expected." cat <<EOF > auth.js const login = () => { console.log('Auth login UI and Database Integrated Successfully'); }; EOF git add auth.js git commit -m "merge: resolve conflicts programmatically in auth.js"

This attempts to merge feature/login into main, catches the expected conflict failure, overwrites auth.js with the resolved code, and commits the merge.

Combined Automated Script

Save the consolidated blocks above as ~/Scripts/simulate_git_flow.sh, make it executable with chmod +x simulate_git_flow.sh, and run it:

Verify that the following configurations and outputs exist inside your project workspace.

Created Files / Templates

/home/devops/Scripts/simulate_git_flow.sh - Automated branching simulation script.
/home/devops/Projects/git-lab/auth.js - Resolved Javascript authentication interface file.
/home/devops/Projects/git-lab/README.md - Baseline repository documentation.

Verification Artifacts / Execution Proof

Output of git config --list verifying your global email and name.
Output of git status confirming no active conflicts remain.
Output of git log --graph --all showing the split and merged branch history.

Architectural Intent & Operational Impact

Why We Did This

Branching separates experimental feature changes from production code, keeping the main branch stable.
Merge conflicts occur when changes overlap. Resolving them manually ensures that conflicting code is reviewed and integrated safely.
Local repository commits track code changes historically, allowing developers to revert to previous versions if needed.

What This Accomplishes

Demonstrates team development practices, preparing students to resolve merge conflicts in collaborative workspaces.
Shows how branching policies, remote links, and commits protect the production release lineage.
Teaches students how local changes sync with GitHub remote servers using SSH key validation.