mapas-mentales/mindmap/Git on the Server.md

Git on the Server

Purpose & context

• Current baseline
  • You should now be able to handle most day-to-day Git tasks
• Why a remote repository is needed for collaboration
  • Collaboration requires a remote Git repository
  • While you can push/pull directly between individuals’ repositories:
    • It’s discouraged (easy to confuse what others are working on)
    • Collaborators need access even if your computer is offline
  • Preferred approach
    • Set up an intermediate repository that everyone can access
    • Everyone pushes to / pulls from that common repository
• Running a Git server (high-level)
  • Choose which protocols your server should support
  • Chapter structure
    • Protocol options + pros/cons
    • Typical setups and how to get them running
    • Hosted options (if you don’t want to self-host)
  • If you don’t want to run your own server
    • Skip to “Third Party Hosted Options”
    • Then continue to the next chapter about distributed workflows
• What a “remote repository” usually is
  • Generally a bare repository
    • No working directory
    • Used only as a collaboration point
  • Bare repository in simplest terms
    • Contents of your project’s .git directory
    • And nothing else

The Protocols (ways Git transfers data)

• Four distinct protocols
  • Local
  • HTTP (Smart + Dumb)
  • SSH
  • Git (git://)
• Selection depends on
  • Authentication requirements
  • Public vs private access needs
  • Firewall constraints
  • Ease of setup/maintenance
  • Performance expectations

Local Protocol

• Definition
  • Remote repository is just another directory on the same host
• Typical use cases
  • Team shares a filesystem (e.g., NFS mount)
  • Less likely: everyone logs into the same computer
    • Not ideal: all repos on one machine → catastrophic loss risk higher
• How to use (clone / add remote)
  • Clone using a filesystem path
    • git clone /srv/git/project.git
  • Clone explicitly using file://
    • git clone file:///srv/git/project.git
  • Add as a remote to an existing project
    • git remote add local_proj /srv/git/project.git
    • Then push/pull using local_proj like a network remote
• Path vs file:// behavior
  • Plain path (no file://)
    • Git tries to use hardlinks or directly copies needed files
  • With file://
    • Git uses network-style transfer processes
    • Generally less efficient
  • Why ever use file://?
    • To get a “clean” copy (leave out extraneous refs/objects)
    • Often after importing from another VCS (maintenance tasks noted in “Git Internals”)
  • Recommended in this chapter
    • Use the normal path (almost always faster)
• Pros
  • Simple to set up
  • Uses existing filesystem permissions and access
  • Easy when you already have a shared filesystem
    • Put a bare repo where everyone can access it
    • Set read/write permissions like any shared directory
  • Convenient for quick sharing from someone’s working repo
    • e.g., git pull /home/john/project can be simpler than using a server
• Cons
  • Shared filesystem access can be harder from multiple locations than network access
    • Example: pushing from home may require mounting a remote disk (slow/difficult)
  • Performance caveat on shared mounts
    • “Local” is fast only if data access is fast
    • NFS can be slower than SSH (even to same server) because SSH lets Git use local disks
  • Risk of accidental repository damage
    • Users have full shell access to the “remote” directory
    • Nothing prevents deleting/modifying internal Git files → corruption risk

HTTP Protocols

• Two modes
  • Dumb HTTP
    • Older (pre Git 1.6.6)
    • Simple, generally read-only
  • Smart HTTP
    • Introduced in Git 1.6.6
    • More capable: negotiates transfers intelligently (similar to SSH)
    • Has become very popular due to usability + efficiency

Smart HTTP

• How it works (conceptually)
  • Similar to SSH/Git protocols but runs over standard HTTPS ports
  • Can use multiple HTTP authentication mechanisms
    • Often easier than SSH key setup
    • Supports username/password prompting
• Usability benefits
  • Single URL can support
    • Anonymous reads (like git://)
    • Authenticated/encrypted pushes (like SSH)
  • Client behavior
    • If push requires auth → server prompts for username/password
    • Same for reads if configured
• Example behavior (hosted services)
  • For GitHub-like services
    • The web URL (e.g., https://github.com/...) can also be used to clone/push (if authorized)

Dumb HTTP

• When used
  • Git client falls back to Dumb HTTP if server doesn’t respond with a smart HTTP service
• Expectations
  • Bare Git repository is served as static files by a web server
• Setup (read access)
  • Place bare repo under HTTP document root + enable a post-update hook
  • Example sequence
    • cd /var/www/htdocs/
    • git clone --bare /path/to/git_project gitproject.git
    • cd gitproject.git
    • mv hooks/post-update.sample hooks/post-update
    • chmod a+x hooks/post-update
• Why the hook matters
  • Default post-update runs git update-server-info
  • That makes HTTP fetching/cloning work properly
  • Typically triggered when someone pushes to the repo (often over SSH)
• Cloning from Dumb HTTP
  • git clone https://example.com/gitproject.git
• Server flexibility
  • Apache example uses /var/www/htdocs
  • Any static web server works if it can serve the bare repo files
  • “Git Internals” referenced for details of how the data is served
• Common deployment choice
  • Usually you run either:
    • Smart HTTP read/write, or
    • Dumb HTTP read-only
  • Rare to run a mix

HTTP Pros (focus on Smart HTTP)

• Single URL for all access types
  • Server prompts only when authentication is needed
• Username/password authentication
  • Avoids SSH key generation/upload steps
  • Especially useful for less sophisticated users or environments where SSH is uncommon
• Performance
  • Fast and efficient (comparable to SSH)
• Security options
  • Serve read-only over HTTPS with encrypted transfer
  • Can require signed SSL client certificates (stronger client auth)
• Firewall friendliness
  • HTTP/HTTPS ports are commonly allowed through corporate firewalls

HTTP Cons

• Setup complexity
  • HTTPS Git can be trickier to set up than SSH on some servers
  • Otherwise, other protocols offer little advantage over Smart HTTP for serving Git content
• Credential handling for authenticated pushes
  • Sometimes more complicated than SSH keys
  • Mitigations (credential caching tools)
    • Keychain access (macOS)
    • Credential Manager (Windows)
  • “Credential Storage” referenced for secure password caching setup

SSH Protocol

• Why it’s common for self-hosting
  • SSH is often already installed/configured on servers
  • If not, it’s generally easy to set up
  • Provides authenticated, encrypted transport
• Clone URL forms
  • Explicit SSH URL
    • git clone ssh://[user@]server/project.git
  • scp-like shorthand
    • git clone [user@]server:project.git
  • Username handling
    • If not specified, Git assumes your current local username
• Pros
  • Easy to set up (SSH daemon is common; admins often know it; OS tools exist)
  • Secure
    • Encrypted + authenticated transfer
  • Efficient
    • Data compacted before transfer (like HTTPS/Git/Local)
• Cons
  • No anonymous access
    • Users need SSH access even for read-only cloning
  • Not ideal for open source “browse/clone without accounts”
  • If you want anonymous read-only + authenticated writes
    • Use SSH for push
    • Add another protocol for public fetch (e.g., HTTPS or git://)

Git Protocol (git://)

• What it is
  • A Git-provided daemon
  • Listens on port 9418
  • Similar transfer behavior to SSH but:
    • No authentication
    • (No encryption/auth overhead)
• Repository export control
  • Repo must contain a file named git-daemon-export-ok
  • Without it, the daemon won’t serve the repository
• Push behavior
  • Typically no pushing
  • You can enable pushes, but it’s insecure:
    • Anyone who discovers the URL could push
    • Rare in practice
• Pros
  • Often the fastest network transfer option
  • Useful for
    • high-traffic public projects, or
    • very large projects
    • when no user authentication is required for read access
  • Uses SSH-like transfer mechanism without encryption/auth overhead
• Cons
  • No authentication (major downside)
  • Usually should not be the only access method
    • Common pairing
      • Developers: SSH or HTTPS (write access)
      • Everyone else: git:// (read-only)
  • Harder to set up than others
    • Requires its own daemon
    • Needs system integration (xinetd, systemd, etc.)
  • Firewall constraints
    • Requires port 9418
    • Often blocked behind corporate firewalls

Getting Git on a Server (self-host setup)

• Scope note (environment assumptions)
  • Commands shown are simplified for a Linux-based server
  • Possible on macOS or Windows servers too
  • Production deployments will differ:
    • security measures
    • OS tooling
• Step 1: create/export a bare repository
  • Requirement
    • Export an existing repo into a new bare repository (no working dir)
  • Create a bare clone
    • git clone --bare my_project my_project.git
  • Naming convention
    • bare repos typically end with .git
  • Rough equivalent (not identical)
    • cp -Rf my_project/.git my_project.git
  • Result
    • Git data only (no checked-out snapshot)
    • Directory dedicated to the repository’s internal data
• Step 2: put the bare repository on a server
  • Example environment
    • Server: git.example.com
    • Repos stored under: /srv/git
    • SSH access available
  • Copy bare repo to server
    • scp -r my_project.git user@git.example.com:/srv/git
  • Cloning for other users (with SSH read access to /srv/git)
    • git clone user@git.example.com:/srv/git/my_project.git
  • Push access rule of thumb
    • SSH + filesystem write permissions to /srv/git/my_project.git ⇒ push access
  • Group write permissions (recommended)
    • Run inside the repo:
      • git init --bare --shared
    • Effects
      • Adds group write permissions appropriately
      • Does not remove commits/refs/etc.
• Minimal “useful Git server” takeaway
  • Add SSH-capable accounts for collaborators
  • Place a bare repository where they have read/write permissions
  • That’s enough for private collaboration
• What later sections add (optional sophistication)
  • avoid per-user accounts
  • add public read access
  • add web UIs
  • etc.

Small Setups (few developers / trying Git)

• Common pain point
  • User management + permissions
    • Some repos read-only for some users
    • Read/write for others
• SSH Access approach
  • If everyone already has SSH access to a server
    • Easiest initial setup (almost no additional work)
  • For more complex access control
    • Use OS filesystem permissions
  • If server has no accounts for all writers
    • Set up SSH access for those users
  • Assumption stated
    • If you have a server for this, you likely already have SSH installed and use it to access the server
• Ways to grant SSH write access
  • Option 1: create an account for each person
    • Straightforward
    • Can be cumbersome (adduser/useradd + temporary passwords)
  • Option 2: single shared git account using authorized_keys
    • Create one git user on server
    • Collect users’ SSH public keys
    • Append to ~git/.ssh/authorized_keys
    • Everyone connects as git
    • Commit data unaffected by SSH username used to connect
  • Option 3: centralized auth
    • LDAP or other central auth source
    • Any SSH authentication method works if user can get shell access

Generating an SSH public key (client side)

• Purpose
  • Many Git servers authenticate using SSH public keys
  • Each user must generate a key pair if they don’t have one
• Check for an existing key
  • SSH keys usually stored in ~/.ssh
  • Example checks
    • cd ~/.ssh
    • ls
  • Look for pairs like
    • id_dsa + id_dsa.pub
    • id_rsa + id_rsa.pub
  • Meaning
    • .pub file = public key
    • non-.pub file = private key
• Generate a key if missing
  • Tool
    • ssh-keygen (Linux/macOS SSH package; also included with Git for Windows)
  • Recommended command shown
    • ssh-keygen -o
  • Prompts and outputs
    • Choose file path (default ~/.ssh/id_rsa)
    • Enter passphrase twice (optional)
    • Key is saved as:
      • private key: ~/.ssh/id_rsa
      • public key: ~/.ssh/id_rsa.pub
• Passphrase guidance
  • Can be empty (no password prompts when using the key)
  • If you do set a password
    • use -o (more resistant key format than default)
  • ssh-agent can help avoid typing passphrase repeatedly
• Sharing the public key
  • User sends the contents of the .pub file to the admin
  • Example command
    • cat ~/.ssh/id_rsa.pub
• Reference link mentioned
  • GitHub SSH key guide:
    • https://docs.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

Setting up the server (authorized_keys method)

• Note about automation
  • Much can be automated with ssh-copy-id (instead of manual key install)
• Create the git user and SSH directory
  • sudo adduser git
  • su git
  • cd
  • mkdir .ssh && chmod 700 .ssh
  • touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
• Add developer public keys
  • Assumption
    • Trusted public keys saved to temporary files (e.g., /tmp/id_rsa.john.pub)
  • Append to authorized_keys
    • cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
    • cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
    • cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
• Create a bare repository on the server
  • cd /srv/git
  • mkdir project.git
  • cd project.git
  • git init --bare
• First push into the empty bare repository (example workflow)
  • Note
    • Someone must create a bare repo on the server for each new project
  • Example (on John’s computer)
    • cd myproject
    • git init
    • git add .
    • git commit -m 'Initial commit'
    • git remote add origin git@gitserver:/srv/git/project.git
    • git push origin master
• Typical collaboration thereafter
  • Clone
    • git clone git@gitserver:/srv/git/project.git
  • Edit/commit/push example
    • cd project
    • vim README
    • git commit -am 'Fix for README file'
    • git push origin master
• Restricting interactive shell access (optional)
  • Default situation
    • Users can log in and get a shell as git
  • Approach
    • Change shell in /etc/passwd
  • Use git-shell (limited shell bundled with Git)
    • Allows Git push/pull via SSH
    • Denies normal interactive shell access
  • Ensure git-shell is listed as a valid shell
    • Check /etc/shells
      • cat /etc/shells
    • Find git-shell
      • which git-shell
    • Add its path to /etc/shells if missing
      • sudo -e /etc/shells
  • Set login shell for user
    • sudo chsh git -s $(which git-shell)
  • Result of interactive SSH attempt
    • ssh git@gitserver
    • Message includes
      • fatal: Interactive git shell is not enabled.
      • hint about ~/git-shell-commands existing and being executable/readable
  • Customize git-shell behavior
    • Create ~/git-shell-commands
    • Possible customizations
      • restrict accepted Git commands
      • customize the SSH login rejection message
    • Reference
      • git help shell
• Preventing SSH forwarding features (optional hardening)
  • Even with git-shell, users may still use SSH port forwarding
  • To prevent, prepend options to each key line in authorized_keys
    • no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
  • Effect
    • Git network commands still work
    • Users can’t get a shell / can’t use those forwarding mechanisms

Git Daemon (Git protocol: git://)

• Purpose
  • Fast, unauthenticated access to Git data
• Security reminder
  • Not authenticated
  • Anything served is public within its network
  • Recommended use
    • Outside firewall: only for publicly visible projects
    • Inside firewall: useful for many read-only consumers (e.g., CI/build servers) without managing many SSH keys
• Run the daemon (base command)
  • git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
  • Options
    • --reuseaddr
      • Restart without waiting for old connections to time out
    • --base-path=/srv/git/
      • Allows cloning without specifying full paths
    • Trailing /srv/git/
      • Where to look for repos to export
• Firewall
  • Open port 9418
• Daemonizing & supervising the process
  • Depends on OS/init system
  • systemd example (common on modern Linux)
    • Create /etc/systemd/system/git-daemon.service:
      • [Unit]
        • Description=Start Git Daemon
      • [Service]
        • ExecStart=/usr/bin/git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
        • Restart=always
        • RestartSec=500ms
        • StandardOutput=syslog
        • StandardError=syslog
        • SyslogIdentifier=git-daemon
        • User=git
        • Group=git
      • [Install]
        • WantedBy=multi-user.target
    • Adjust as needed
      • Ensure the git user exists or change user/group
      • Verify Git binary path is /usr/bin/git (change if needed)
    • Service control
      • Enable on boot: systemctl enable git-daemon
      • Start: systemctl start git-daemon
      • Stop: systemctl stop git-daemon
  • Other alternatives mentioned
    • xinetd
    • sysvinit scripts
    • anything that daemonizes + monitors the process
• Exporting repositories over git://
  • Per-repository opt-in via file:
    • cd /path/to/project.git
    • touch git-daemon-export-ok

Smart HTTP (Git over HTTP with smart negotiation)

• Goal
  • One protocol that can provide both:
    • authenticated push/pull
    • unauthenticated read-only access
• Mechanism
  • Enable Git’s CGI script: git-http-backend
• How it behaves
  • CGI reads URL path + headers from git fetch / git push
  • Determines if client supports Smart HTTP (true for clients since Git 1.6.6)
  • If client is smart
    • speaks Smart HTTP
  • Else
    • falls back to Dumb HTTP behavior (backward-compatible reads)
• Basic Apache setup example
  • Install Apache + utilities
    • sudo apt-get install apache2 apache2-utils
  • Enable needed modules
    • a2enmod cgi alias env
    • Enables: mod_cgi, mod_alias, mod_env
  • Ensure Apache can read/write repositories
    • Set group of /srv/git to www-data:
      • chgrp -R www-data /srv/git
    • Rationale
      • Apache CGI runs as www-data by default
  • Apache configuration for /git path
    • Environment variables
      • SetEnv GIT_PROJECT_ROOT /srv/git
      • SetEnv GIT_HTTP_EXPORT_ALL
    • Route /git/ to the backend
      • ScriptAlias /git/ /usr/lib/git-core/git-http-backend/
    • Note about GIT_HTTP_EXPORT_ALL
      • If omitted:
        • unauthenticated clients can only access repos containing git-daemon-export-ok
  • Authenticate writes (example Auth block)
    • <Files "git-http-backend">
      • AuthType Basic
      • AuthName "Git Access"
      • AuthUserFile /srv/git/.htpasswd
      • Require expr !(%{QUERY_STRING} -strmatch '*service=git-receive-pack*' || %{REQUEST_URI} =~ m#/git-receive-pack$#)
      • Require valid-user
    • Create .htpasswd (example user schacon)
      • htpasswd -c /srv/git/.htpasswd schacon
    • Notes
      • Many authentication methods exist in Apache; this is just a simple example
      • Strongly recommended to use SSL so data is encrypted
• Key architectural point
  • git-http-backend handles Git protocol negotiation and data transfer
  • Authentication is handled by the web server layer (Apache or other CGI-capable server)
• Web server flexibility
  • Works with nearly any CGI-capable web server
• Reference (Apache auth docs)
  • https://httpd.apache.org/docs/current/howto/auth.html

GitWeb (simple web UI)

• Motivation
  • After enabling read/write and/or read-only access, you may want a basic web visualizer
• What it is
  • Git includes a CGI script called GitWeb
  • (Figure 49 referenced as the GitWeb UI screenshot)
• Quick temporary instance: git instaweb
  • Uses a lightweight web server (e.g., lighttpd or webrick)
  • Linux note
    • lighttpd often installed → git instaweb may “just work”
  • macOS note (example)
    • Ruby (and thus webrick) may be a convenient choice
  • Start with a specified handler
    • git instaweb --httpd=webrick
    • Starts HTTP server on port 1234 and opens a browser automatically
    • Example log lines shown include WEBrick and Ruby version info
  • Stop the server
    • git instaweb --httpd=webrick --stop
• Running GitWeb continuously (server deployment)
  • Option 1: install a distro package
    • Some distros offer a gitweb package (via apt or dnf)
  • Option 2: install manually (quick walkthrough)
    • Clone Git source (GitWeb included)
      • git clone git://git.kernel.org/pub/scm/git/git.git
    • Build GitWeb with project root configured
      • cd git/
      • make GITWEB_PROJECTROOT="/srv/git" prefix=/usr gitweb
      • Generates gitweb.cgi + static assets (e.g., static/gitweb.js)
    • Deploy to web directory
      • sudo cp -Rf gitweb /var/www/
    • Apache VirtualHost example (CGI enablement)
      • <VirtualHost *:80>
        • ServerName gitserver
        • DocumentRoot /var/www/gitweb
        • <Directory /var/www/gitweb>
          • Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
          • AllowOverride All
          • order allow,deny
          • Allow from all
          • AddHandler cgi-script cgi
          • DirectoryIndex gitweb.cgi
        • </Directory>
      • </VirtualHost>
    • Result
      • Visit http://gitserver/ to browse repositories
  • Server flexibility
    • Can be served by any CGI-/Perl-capable web server

GitLab (modern, fully featured Git server example)

• Why mentioned
  • GitWeb is simplistic
  • GitLab is a popular open source alternative:
    • more capable
    • more complex to install/maintain
    • database-backed web application

Installation

• Recommended approach
  • Install via official Omnibus GitLab package
• Other installation options listed
  • GitLab Helm chart (Kubernetes)
  • Dockerized GitLab packages (Docker)
  • Install from source
  • Cloud providers / platforms
    • AWS
    • Google Cloud Platform
    • Azure
    • OpenShift
    • Digital Ocean
• Reference mentioned
  • GitLab Community Edition (CE) README

Administration (web UI)

• Access method
  • Browser to GitLab hostname/IP
  • Log in as admin
• Default credentials (must change immediately)
  • Username: admin@local.host
  • Password: 5iveL!fe
• Entering admin interface
  • Click “Admin area” icon (top right menu)
  • (Figure 50 referenced)

Users

• Requirement
  • Everyone must have a GitLab user account
• Account contents
  • Personal info tied to login data
• Namespaces
  • Each user has a namespace grouping their projects
  • Example
    • user jane, project project
    • URL: http://server/jane/project
• Removing accounts (two modes)
  • Blocking
    • Prevents login
    • Preserves namespace data
    • Commits signed with that email still link to profile
  • Destroying
    • Removes user from database and filesystem
    • Deletes projects/data in their namespace
    • Removes groups they own
    • More permanent/destructive; rarely needed
• (Figure 51 referenced as user admin screen)

Groups

• Definition
  • Collection of projects + access control data for those projects
• Group namespace
  • Similar to user namespaces
  • Example
    • group training, project materials
    • URL: http://server/training/materials
• Permissions
  • Group users have permission levels for group and projects
  • Range example
    • Guest: issues/chat only
    • Owner: full control (group, members, projects)
  • Too numerous to list (GitLab links from admin screen)
• (Figure 52 referenced as group admin screen)

Projects

• Meaning
  • Roughly corresponds to a single Git repository
• Namespace association
  • Every project belongs to exactly one namespace:
    • user, or
    • group
• Access control behavior
  • User-owned project
    • owner directly controls access
  • Group-owned project
    • group member permissions apply
• Visibility levels (read access control)
  • Private
    • owner explicitly grants access to specific users
  • Internal
    • visible to any logged-in user
  • Public
    • visible to anyone
  • Applies to both
    • git fetch access
    • web UI access

Hooks

• Hook support
  • Project-level hooks
  • System-level hooks
• Behavior
  • GitLab sends HTTP POST with descriptive JSON when events occur
• Purpose
  • Integrate with automation and tooling
    • CI servers
    • chat rooms
    • deployment tools

Basic Usage

• Create a project
  • Click “+” icon on toolbar
  • Provide
    • project name
    • namespace
    • visibility level
  • Most settings can be changed later
  • Click “Create Project”
• Connect project to local Git workflow
  • Access methods
    • HTTPS
    • SSH
  • URLs shown at top of project home page
  • Add remote for an existing local repository (example remote name gitlab)
    • git remote add gitlab https://server/namespace/project.git
  • Or clone if you don’t have a local copy
    • git clone https://server/namespace/project.git
• Web UI repository views
  • Project home: recent activity
  • Navigation links: files view + commit log

Working Together

• Model 1: direct push access
  • Add users via project settings → “Members”
  • Assign access level
  • “Developer” or above can push commits/branches directly
• Model 2: merge requests (more decoupled)
  • Users with push access
    • create branch
    • push commits
    • open merge request back into master (or another branch)
  • Users without push permission
    • fork project
    • push to fork
    • open merge request from fork into main project
  • Benefits
    • owner controls what/when changes merge
    • supports contributions from untrusted users
• Discussion units
  • Merge requests + issues are main long-lived discussion objects
  • Merge requests support
    • line-by-line discussion (lightweight code review)
    • overall discussion thread
  • Both can be
    • assigned to users
    • organized into milestones
• Broader feature note (beyond Git)
  • Also provides features like
    • project wikis
    • system maintenance tools
  • Operational benefit
    • after initial setup, little need for config-file edits or SSHing to server
    • most admin/usage via browser UI

Third Party Hosted Options

• When to choose
  • You don’t want to set up/maintain your own Git server
• Advantages
  • quick setup
  • easy project creation
  • no maintenance/monitoring
  • even if you self-host internally:
    • public hosting for open source can be easier for the community to find/contribute
• Choosing a host
  • Many options with different pros/cons
  • Up-to-date list referenced
    • GitHosting page on the main Git wiki:
      • https://git.wiki.kernel.org/index.php/GitHosting
• GitHub note
  • GitHub covered in detail in the “GitHub” chapter
  • It’s the largest Git host, and you may need to interact with GitHub-hosted projects
  • Many other hosts exist if you prefer alternatives

Summary (decision guidance)

• You have multiple options for running a remote Git repository to collaborate/share work
• Self-hosting
  • Pros
    • high control
    • can run within your firewall
  • Cons
    • time/effort to set up
    • ongoing maintenance burden
• Hosted services
  • Pros
    • easy to set up and maintain
  • Cons
    • your code resides on someone else’s servers
    • some organizations prohibit this
• Practical takeaway
  • Choose the solution (or combination) that fits your organization’s needs