When starting a new software project with Git, the initial setup determines how collaboration, versioning, and deployment will function throughout the development lifecycle. This involves decisions about repository structure, handling special files, configuring line endings, and choosing a remote access protocol for team sharing.

When to Apply This Workflow

This workflow applies at project inception—when initializing version control for a new or existing codebase that hasn’t yet been migrated into Git. It establishes the foundational repository structure and defines how developers interact with a central remote. Later workflows (e.g., feature branching, release management, or repository splitting) build upon this initial configuration.

Workflow Structure Overview

Each Git workflow follows a consistent format:

• Motivation: Why and when to use it.
• Overview: High-level steps and key concepts.
• Prerequisites: Required infrastructure or conditions.
• Summary: Concise description of the core idea.
• Implementation: Step-by-step commands and configurations.
• Alternatives: Other viable approaches and their trade-offs.

Project Initialization Workflow

The goal is to convert a local project directory into a Git repository and expose it as a shared remote for team collaboration.

Step 1: Prepare the Local Repository

Handle empty directories Git does not track empty directories. To preserve them (e.g., EmptyDir), add a placeholder file like .gitkeep or .gitignore:

cd projecta/EmptyDir
touch .gitkeep

Alternatively, use .gitignore to both preserve the directory and ignore its contents:

echo "*" > .gitignore

Exclude unnecessary files Prevent build artifacts, logs, or temporary files from entering version control by creating a root-level .gitignore:

# .gitignore
/TempDir
*.bak

Initialize the repository

cd projecta
git init

Configure line endings To avoid cross-platform line-ending conflicts, standardize on LF in the repository:

git config --global core.autocrlf input  # On Unix/macOS
git config --global core.autocrlf true   # On Windows

Stage and commit initial files

git add .
git commit -m "Initial commit"

Create a bare repository A bare repository (without a working tree) serves as the central remote:

git clone --bare projecta projecta.git

Step 2: Share the Repository

Multiple protocols can expose the bare repository:

File Protocol (Local Network Share)

Copy the bare repo to a shared network location:

cp -R projecta.git /shared/gitrepos/

Team members clone using:

git clone /shared/gitrepos/projecta.git
# or
git clone file:///shared/gitrepos/projecta.git

Permissions are managed via the filesystem. Simple but inefficient over distance and lacks authentication.

Git Daemon (Fast, Anonymous Access)

Enable export:

cd projecta.git
touch git-daemon-export-ok

Start the daemon:

git daemon --base-path=/shared/gitrepos --enable=receive-pack

Clone via:

git clone git://server-42/projecta.git

Offers high performance but no user authentication—suitable only for trusted networks.

HTTP(S) Protocol (Web-Based Access)

Using Apache and git-http-backend, configure:

SetEnv GIT_PROJECT_ROOT /shared/gitrepos
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

<Directory "/usr/lib/git-core">
    Options ExecCGI
    Require all granted
</Directory>

<LocationMatch "^/git/.*/git-receive-pack$">
    AuthType Basic
    AuthName "Git Access"
    AuthUserFile /shared/gitrepos/git-auth-file
    Require valid-user
</LocationMatch>

Clone with:

git clone http://server-42/git/projecta.git

Supports authentication and works through firewalls. HTTPS adds encryption.

SSH Protocol (Secure and Efficient)

Deploy the bare repo too an SSH-accessible server:

scp -r projecta.git user@server:/shared/gitrepos/

Clone using:

git clone user@server:/shared/gitrepos/projecta.git

Authentication and permissions are handled by SSH and filesystem ACLs. Highly secure and efficient, but requires user accounts on the server. Tools like Gitolite can simplify permission management down to the branch level.

Alternative: Pull-Request Based Collaboration

In open-source or contributor-driven models, developers lack direct push access. Instead:

1. Each forks or clones the central repo.
2. They push changes to their own public repository.
3. They submit a pull request to the integrator.
4. The integrator reviews and merges approved changes.

This decouples contribution from integration but introduces latency and potential data loss if contributor repos aren’t backed up. Platforms like GitHub automate this model.

Regardless of the chosen method, the initial repository setup lays the groundwork for all future collaboration patterns.