Git Version Control

From Server rent store
Jump to navigation Jump to search
  1. Git Version Control

This article details the configuration and utilization of Git version control for managing MediaWiki installations. It is aimed at system administrators and developers responsible for maintaining and updating the MediaWiki software. Utilizing Git is crucial for collaborative development, tracking changes, and facilitating easy rollback to previous versions. This guide assumes a basic familiarity with the command line.

Why Use Git with MediaWiki?

MediaWiki is a complex software package, and managing changes directly on a production server is highly discouraged. Git provides a safe and organized way to:

  • Track all modifications made to the MediaWiki codebase.
  • Collaborate with other developers without conflicting changes.
  • Easily revert to previous versions if issues arise after an update.
  • Create branches for testing new features or bug fixes.
  • Maintain a complete history of the MediaWiki installation.

Setting up a Git Repository

The first step is to initialize a Git repository. This can be done on a development machine or a dedicated server. Avoid directly initializing a repository *inside* the live webroot if possible; instead, clone from a remote repository.

Initializing a Local Repository

If you are starting from scratch:

1. Navigate to the MediaWiki directory in your terminal. 2. Run the command: `git init`

This creates a hidden `.git` directory, which stores all Git-related data.

Cloning from a Remote Repository

This is the recommended approach for most scenarios. It allows for collaboration and backups.

1. If you have a remote repository (e.g., on GitHub, GitLab, or a self-hosted server), obtain the repository URL. 2. In your terminal, run: `git clone <repository_url>`

This downloads the entire repository to your local machine.

Configuring Git Ignore

It is essential to create a `.gitignore` file to prevent unwanted files from being tracked by Git. These typically include:

  • Configuration files containing sensitive information (e.g., `LocalSettings.php`).
  • Cache directories (e.g., `cache/`).
  • Log files.
  • Temporary files.

Here's an example `.gitignore` file:

File/Directory Reason
LocalSettings.php Contains sensitive database credentials
cache/ Contains cached data that changes frequently
images/thumb/ Automatically generated thumbnails
logs/ Log files are not version controlled
extensions/BlueSpice/data/ Extension-specific data (if applicable)

Basic Git Workflow

The typical Git workflow involves the following steps:

1. **Pull:** `git pull origin main` - Download the latest changes from the remote repository. `main` is the default branch name; adjust as necessary. 2. **Branch:** `git checkout -b feature/my-new-feature` - Create a new branch for your changes. 3. **Modify:** Make the necessary changes to the MediaWiki files. 4. **Stage:** `git add .` - Stage all modified files. Be careful with `git add .`; review `git status` first! 5. **Commit:** `git commit -m "Implemented my new feature"` - Commit the staged changes with a descriptive message. 6. **Push:** `git push origin feature/my-new-feature` - Upload the branch to the remote repository. 7. **Merge Request/Pull Request:** Create a merge request or pull request on the remote repository to merge your changes into the main branch.

Important Files and Directories to Track

Here's a breakdown of key files and directories to track within the Git repository:

File/Directory Description
includes/ Core MediaWiki code
extensions/ Installed extensions
skins/ Installed skins
config/ Configuration files (except for `LocalSettings.php` which should be ignored.)
maintenance/ Scripts for database maintenance and other tasks
LocalSettings.php.sample Sample configuration file (track this as a template)

Security Considerations

  • Never commit sensitive information, such as database passwords or API keys, directly to the Git repository. Use environment variables or secure configuration management tools instead.
  • Restrict access to the Git repository to authorized personnel only.
  • Regularly review the commit history for any suspicious activity.

Rolling Back Changes

Git makes it easy to revert to previous versions of the MediaWiki installation.

1. `git log` - View the commit history. 2. `git checkout <commit_hash>` - Checkout the specific commit you want to revert to. Be cautious with this; it will put you in a "detached HEAD" state. 3. To create a branch from the commit: `git checkout -b rollback/<commit_hash> <commit_hash>` 4. Compare the reverted version with the current version using `diff`. 5. If satisfied, merge the rollback branch into the main branch or deploy the reverted version to the production server.

Advanced Git Concepts

  • **Branching Strategies:** Explore different branching strategies, such as Gitflow or GitHub Flow, to manage complex development workflows. See Branching Models.
  • **Tagging:** Use tags to mark specific releases of the MediaWiki installation.
  • **Stashing:** Use stashing to temporarily save changes without committing them.
  • **Rebasing:** Understand the implications of rebasing and use it carefully. See Git Rebasing.
  • **Hooks:** Implement Git hooks to automate tasks, such as running tests or deploying changes.

Troubleshooting

  • **Conflicts:** Conflicts can occur when merging branches. Resolve them carefully by editing the conflicting files and choosing the desired changes. See Conflict Resolution.
  • **Large Files:** Avoid tracking extremely large files in Git. Use Git Large File Storage (LFS) if necessary.
  • **Repository Size:** Keep the repository size manageable by removing unnecessary files and using Git's garbage collection features.

Resources


Special:MyLanguage/Help:Contents Special:MyLanguage/Help:Wiki_syntax Special:MyLanguage/Help:Linking Help:Table Manual:Configuration settings Manual:Database setup Manual:Installing MediaWiki Manual:Extension installation Manual:Skin installation Help:Tracking changes Manual:Command-line tools Manual:API Help:External links Help:File upload Special:Search Special:Random Project:Administration


Intel-Based Server Configurations

Configuration Specifications Benchmark
Core i7-6700K/7700 Server 64 GB DDR4, NVMe SSD 2 x 512 GB CPU Benchmark: 8046
Core i7-8700 Server 64 GB DDR4, NVMe SSD 2x1 TB CPU Benchmark: 13124
Core i9-9900K Server 128 GB DDR4, NVMe SSD 2 x 1 TB CPU Benchmark: 49969
Core i9-13900 Server (64GB) 64 GB RAM, 2x2 TB NVMe SSD
Core i9-13900 Server (128GB) 128 GB RAM, 2x2 TB NVMe SSD
Core i5-13500 Server (64GB) 64 GB RAM, 2x500 GB NVMe SSD
Core i5-13500 Server (128GB) 128 GB RAM, 2x500 GB NVMe SSD
Core i5-13500 Workstation 64 GB DDR5 RAM, 2 NVMe SSD, NVIDIA RTX 4000

AMD-Based Server Configurations

Configuration Specifications Benchmark
Ryzen 5 3600 Server 64 GB RAM, 2x480 GB NVMe CPU Benchmark: 17849
Ryzen 7 7700 Server 64 GB DDR5 RAM, 2x1 TB NVMe CPU Benchmark: 35224
Ryzen 9 5950X Server 128 GB RAM, 2x4 TB NVMe CPU Benchmark: 46045
Ryzen 9 7950X Server 128 GB DDR5 ECC, 2x2 TB NVMe CPU Benchmark: 63561
EPYC 7502P Server (128GB/1TB) 128 GB RAM, 1 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (128GB/2TB) 128 GB RAM, 2 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (128GB/4TB) 128 GB RAM, 2x2 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (256GB/1TB) 256 GB RAM, 1 TB NVMe CPU Benchmark: 48021
EPYC 7502P Server (256GB/4TB) 256 GB RAM, 2x2 TB NVMe CPU Benchmark: 48021
EPYC 9454P Server 256 GB RAM, 2x2 TB NVMe

Order Your Dedicated Server

Configure and order your ideal server configuration

Need Assistance?

⚠️ *Note: All benchmark scores are approximate and may vary based on configuration. Server availability subject to stock.* ⚠️

Retrieved from "https://server-rental.store/index.php?title=Git_Version_Control&oldid=1594"