Blog

• How to Contribute a Blog Post to GITx Documentation
• Intro to github actions
• Git Commands That Will Actually Save Your Day
• How I Resolve Merge Conflicts Easily

How to Contribute a Blog Post to GITx Documentation

Welcome to the GITx blog! We’re excited to have you here and even more excited if you’re thinking about contributing your own post. This guide will walk you through the entire process of creating and submitting a blog post to our documentation site.

What Should You Write About?

We welcome blog posts on any topic related to Git! Here are some ideas to get you started:

• Git Commands Deep Dive: Explain a specific Git command in detail (like git bisect, git rebase, or git cherry-pick)
• Git Workflows: Share best practices for team collaboration using Git
• Git History & Fun Facts: Interesting trivia about Git’s development or its creator
• Personal Stories: How Git helped you solve a problem or improved your workflow
• Tips & Tricks: Lesser-known Git features that make developers more productive
• Tutorials: Step-by-step guides for achieving specific tasks with Git

Step-by-Step: How to Contribute

1. Fork the Repository

Start by forking the gitxtui/docs repository on GitHub. Click the “Fork” button in the top-right corner of the repository page.

# Clone your forked repository
git clone https://github.com/YOUR_USERNAME/docs.git
cd docs

2. Create Your Blog Post File

Navigate to the blog directory and create a new Markdown file:

cd content/en/blog
touch my-awesome-git-post.md

Choose a descriptive filename using lowercase letters and hyphens (e.g., git-rebase-explained.md, my-first-git-contribution.md).

3. Add the Front Matter

Every blog post needs front matter at the top. This is metadata that Hugo (our static site generator) uses to organize and display your post. Here’s the required format:

---
title: "Your Blog Post Title"
linkTitle: "Short Title"
date: 2025-10-02
description: "A brief description of what your post is about (1-2 sentences)."
author: "Your Name or GitHub Username"
---

Explanation:

• title: The full title that appears at the top of your post
• linkTitle: A shorter version for navigation menus
• date: The publication date (use today’s date)
• description: A brief summary for SEO and previews
• author: Your name or GitHub username

4. Write Your Content

Now comes the fun part! Write your blog post using Markdown. Here are some formatting tips:

Headers:

# Heading 1
## Heading 2
### Heading 3

Code Blocks:

```go
package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}
```

Emphasis:

**bold text**
*italic text*
`inline code`

Links:

[link text](https://example.com)

5. Preview Your Post Locally

If you want to see how your post looks before submitting, you can run Hugo locally:

# From the docs root directory
hugo server -D

hen open http://localhost:1313/docs/blog in your browser to preview your post.

6. Submit Your Pull Request

Once you’re happy with your post, it’s time to submit it:

# switch to a new branch
git switch -c docs-add-blog

# Add your new file
git add content/en/blog/my-awesome-git-post.md

# Commit with a descriptive message
git commit -m "feat: Add blog post about [your topic]"

# Push to your fork
git push origin docs-add-blog

Now go to GitHub and create a pull request from your fork to the main gitxtui/docs repository. In your PR description, briefly explain what your blog post is about.

7. Review Process

After you submit your PR:

• Our team will review your submission
• We may provide feedback or suggestions for improvement
• Once everything looks good, we’ll merge your post
• Your contribution will be live on the GITx documentation site! 🎉

Tips for Great Blog Posts:

• Keep it focused: Cover one main topic per post
• Use examples: Code examples and real-world scenarios help readers understand
• Break it up: Use headers, lists, and short paragraphs for readability
• Proofread: Check for typos and grammar issues before submitting
• Be friendly: Write in a conversational tone—imagine you’re explaining to a friend
• Need Help?

If you have questions or need assistance:

• Open an issue on the gitxtui/docs repository
• Join our Discord community
• Comment on the blog contribution issue

We can’t wait to read your contribution! Happy writing! ✍️

Intro to github actions

The problem

Have you ever thought about how big tech companies manage to push code into production so seamlessly? How do they make sure thousands of test cases run automatically, catch issues before they break things, and still ship updates quickly? It almost feels like magic—code goes in, and polished features come out the other side without chaos.

The Solution

The secret isn’t magic at all—it’s automation. In this blog post, we’ll explore how GitHub Actions, developer workflows, and CI/CD pipelines work together to handle testing, automatic deployments, and smooth releases. By the end, you’ll see how these tools make modern software development faster, safer, and much less stressful.

What is CI/CD

Continuous Integration (CI) is the practice of automatically building and testing code every time a team member commits changes to version control. This helps catch bugs early, ensures code quality, and makes collaboration smoother.

Continuous Delivery (CD) is a software development approach where code changes are automatically prepared for a release to production. After passing all automated tests, the code is packaged and made ready for deployment, ensuring that new features and fixes can be delivered to users quickly, safely, and with minimal manual intervention.

Together, CI/CD forms a pipeline that automates the process of integrating code, running tests, and delivering applications. This reduces manual work, speeds up releases, and increases confidence in the software you ship.

Let’s explore

Gitx Docs actions page , here you can see there are workflows that run on every code commit to master branch the GitHub Actions workflow configuration, in this file the github spins up a linux instance and runs hugo(SSG generator to generate static files from a readme) and then deploys it to github pages, no need of manual testing of code, no need of manual deplyment of the code, all things got covered by Github itself.

What happen’s exactly

• The workflow file (hugo.yaml) defines a pipeline that triggers automatically on every commit or push to the master branch.

• GitHub provides a Linux virtual environment (runner) where all commands specified in the workflow are executed.

• The workflow installs Hugo, builds the static site from the Markdown/README files, and outputs the final HTML files into the public directory.

• The generated static files are then automatically deployed to the gh-pages branch, which GitHub Pages serves publicly.

How GitHub Actions Works Behind the Scenes

A GitHub Action workflow is made up of three key components:

• Events: Triggers that start your workflow — like push, pull_request, or a scheduled cron job.
• Jobs: Each job runs a series of steps in a virtual environment. Jobs can run in parallel or depend on each other.
• Runners: The virtual machines (Linux, macOS, or Windows) where your jobs are executed.

For example, when you push new code to the main branch, GitHub detects that event, spins up a Linux runner, installs dependencies, runs your tests, and deploys the result automatically.

Example: Simple GitHub Actions Workflow

Here’s a basic example of a CI/CD pipeline using Node.js:

name: Node CI/CD

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

What happens exactly

Whenever someone pushes code to the main branch, GitHub Actions automatically spins up a new Ubuntu virtual machine (called a runner).
This runner is completely fresh — meaning it doesn’t have any of your project dependencies or tools installed.

Here’s what happens step by step:

1. Checkout the Code:
   The first step uses the actions/checkout action to clone your repository into the runner’s environment so that other steps can access your files.

2. Set up Node.js:
   Since the runner is a clean machine, it doesn’t have Node.js installed by default.
   The actions/setup-node action is used to install the required Node.js version defined in your workflow file.

3. Install Dependencies:
   Once Node.js is available, the workflow runs npm install (or yarn install) to download and set up all the required project dependencies.

4. Run Tests:
   Next, npm test executes your automated tests to ensure that your latest changes didn’t break any existing functionality.

5. Build or Deploy:
   If all tests pass successfully, the workflow can then build the project and deploy it automatically — for example, to GitHub Pages, AWS, or another hosting service.

Each time the workflow runs, GitHub creates a fresh environment, ensuring your build process is reproducible and isolated from previous runs — a key reason CI/CD pipelines are so reliable.

Git Commands That Will Actually Save Your Day

Look, we all know git commit, git push, and git pull. But Git has a treasure trove of commands that can save you hours of frustration—if only you knew they existed. Here are the genuinely useful ones that deserve way more attention.

git reflog — Your Time Machine When Things Go Wrong

Ever executed git reset --hard and immediately regretted it? Or accidentally deleted a branch you needed? This is your safety net.

git reflog

Reflog shows you everything you’ve done—every commit, reset, checkout, merge. Find the SHA of where you want to be, and:

git reset --hard HEAD@{2}

Real-world scenario: You force-pushed to the wrong branch and wiped out work. Reflog lets you recover it. This has saved me more times than I’d like to admit.

git add -p — Stage Like a Pro

Stop staging entire files when you only want some changes. Interactive staging lets you review and stage chunks individually:

git add -p

Git walks you through each change, asking y/n/s (yes/no/split). Press ? for options.

Why this matters: You worked on multiple features in one file. This lets you create clean, atomic commits instead of a messy “fixed stuff” commit.

git bisect — Find Bugs Like a Detective

Your code worked last week. Now it doesn’t. But there are 50 commits in between. Instead of checking each one manually:

git bisect start
git bisect bad                 # Current commit is broken
git bisect good <commit-sha>   # This old commit worked

Git binary-searches through commits. Mark each one as good or bad, and it finds the exact commit that introduced the bug.

Time saved: Instead of checking 50 commits, you check ~6 (log₂ 50).

git stash --include-untracked — Actually Save Everything

Regular git stash only saves tracked files. Add new files? They’re ignored. This version saves everything:

git stash -u
# or
git stash --include-untracked

The situation: You’re mid-feature when production breaks. Stash everything (including those new files), fix prod, then pop your stash and continue.

git commit --fixup — Clean History Without the Hassle

You find a typo in a commit from 5 commits ago. Instead of creating “fix typo” commits:

git commit --fixup <commit-sha>
git rebase -i --autosquash <base-commit>

Git automatically marks it as a fixup and merges it into the original commit during interactive rebase.

Result: Clean history that doesn’t show your mistakes (we all make them, but PRs don’t need to know).

git worktree — Multiple Branches, Zero Context Switching

Need to check another branch but don’t want to stash or commit your current work?

git worktree add ../hotfix-branch hotfix

This creates a separate working directory for that branch. Work on both simultaneously.

Game changer for: Reviewing PRs while keeping your current work untouched, or testing a feature while developing another.

git log --graph --oneline --all — Visualize Your History

Understanding branch topology is hard. This makes it crystal clear:

git log --graph --oneline --all

Add an alias to make it permanent:

git config --global alias.lol "log --graph --oneline --all"
# Now just use: git lol

Pro tip: Add --decorate to see branch and tag names in the visualization.

The Bottom Line

These aren’t party tricks—they’re practical tools that solve real problems. The difference between a Git novice and someone comfortable with Git isn’t knowing more commands; it’s knowing which commands solve which problems.

Bookmark this. Next time you’re stuck, one of these will probably save you.

What’s your underrated Git command? Let me know—I’m always looking for new workflow improvements.

How I Resolve Merge Conflicts Easily

How I Resolve Merge Conflicts Easily

Merge conflicts happen when Git can’t automatically combine changes from different people. It’s not scary — it just means Git needs you to decide which changes to keep.

Steps I Follow to Resolve Conflicts

1. Check the conflicted files
   Git will tell you which files have conflicts after a merge or pull.

2. Open the files and look for conflict markers
   You’ll see things like <<<<<<< HEAD, =======, and >>>>>>> branch-name.

3. Decide which changes to keep
   You can keep your changes, the other person’s changes, or combine both.

4. Remove the conflict markers
   Make sure the file looks exactly how you want it after merging.

5. Save the file
   Confirm that it works and nothing is broken.

6. Stage the resolved files

   git add <file-name>
   

7. Commit the merge git commit

8. Continue working normally Pull, push, or merge as usual.

Quick Tips Communicate with teammates if unsure which changes to keep. Keep commits small and pull often — fewer conflicts that way. Don’t panic — conflicts are just Git asking for guidance.

Resolving merge conflicts is easy once you know the steps. Follow them carefully, and Git will never feel intimidating again.

Happy Coding!! -Vikas :)