Initializing a Bare Repository on the Server

Creating a bare repository prevents direct modification of the project source on the remote host, ensuring integrity for shared access. Initialize the empty directory using the following command:

git init --bare /path/to/central/repo.git

Configuring SSH Access

To enable passwordless authentication, generate an SSH key pair locally. Execute the key generation utility from your terminal within the target project root:

ssh-keygen -t rsa -C "developer@example.com"

Once generated, copy the contents of ~/.ssh/id_rsa.pub. If the .ssh directory does not exist on the server, initiate an SSH connection once to create it. Then, append the public key to the authorized_keys file:

cd ~/.ssh
vim authorized_keys

Fetching Project Code

Clone the remote repository onto your local machine. Replace the placeholder IP and path with actual server details:

git clone ssh://admin@192.168.1.10/home/git-project

If cloning to a specific directory name, specify it at the end. Otherwise, it uses the folder name found in the URL path.

Global User Configuration

Identify yourself globally before pushing commits so they appear under your profile:

git config --global user.name "Developer Name"
git config --global user.email "dev@example.com"

This ensures every commit in the current environment includes metadata. Without --global, settings apply only to the specific local repository.

Writing and Pushing Changes

Develop code within the local environment. Stage modified files, review the state, commmit locally, and finally push to the remote tracking branch:

nano src/main.py

git add src/main.py

git status

git commit -m "Implement initial parser module"

git push origin develop

Note that bare repositories do not render a working tree, which is why pulling updates requires checking out a branch on a non-bare client.

Reverting Modifications

Different scenarios require different reset strategies depending on where the change resides in the index stack.

Undoing Staged Files

Remove a file from the staging area without altering the working directory version.

git reset HEAD src/new_module.py

Rewinding Local History

Use the caret symbol (^) to target the previous commit. You can locate specific SHA hashes via git log.

# Keeps staged changes, moves to parent commit
git reset --soft HEAD~1

# Unstages changes but keeps file modifications
git reset --mixed HEAD~1

# Discards all uncommitted changes entirely
git reset --hard HEAD~1

Refining Commit History

Correcting metadata or combining recent changes can be done interactive.

Modifying the Last Commit

Amend the most recent commit message or include missed files:

git add missing_file.txt
git commit --amend -m "Updated description with additional context"

Interactive Reordering

Squash or edit historical entries based on their position:

git rebase -i HEAD~4

Change pick to squash or reword for specific lines, save the file, then finalize the operation:

git rebase --continue

Managing Branches

Visualize existing brenches, including those pushed to the remote server:

git branch -a

Create a new isolated workspace:

git branch experimental-v2

Switch contexts either by branching off or moving between existing ones:

git switch experimental-v2

Alternatively, create and switch simultaneously:

git checkout -b release-candidate

Resolving Conflicts During Merges

When integrating upstream changes into a feature branch, handle synchronization carefully.

# Update current branch with remote data
git pull

# Switch to the integration branch
git checkout feature-module

# Combine the remote branch into local branch
git merge main

# Resolve conflicts manually using editor
vim src/broken_component.py

# Mark resolved files as merged
git add .

# Complete the merge transaction
git commit -m "Resolved merge conflicts between main and feature-module"