DEV Community: Mercy Moraa

Git Graph Explained: Visualizing Merge, Rebase, and Cherry-Pick

Mercy Moraa — Mon, 03 Aug 2026 06:30:00 +0000

Git is the ultimate tool for developers. Yet, branching strategies still confuse many of us.
Commands like merge, rebase, and cherry-pick manipulate your commit history in completely different ways. If you just guess what they do, you risk ruining your team's shared history or losing track of your changes.

The easiest way to understand Git is to visualize it. Let us look at exactly what happens to your Git graph when you run these three critical commands.

🏗️ Starting Point: Our Example Repository

Imagine we have a standard repository. We branched off the main branch from commit B to work on a new feature in a feature branch.
While we worked on our feature, someone else pushed commit C and D to main.
Here is what our history looks like right now:

  C --- D  [main]
 /

A --- B
\
E --- F [feature]

main has two new commits: C and D.
feature has two new commits: E and F.

🔀 1. Git Merge (The Safe Record Keeper)

When you merge main into your feature branch (or vice versa), Git creates a special, brand-new commit called a merge commit.

git checkout feature
git merge main

The Visual Graph After Merge:

  C ------- D ------ [main]
 /           \

A --- B \
\ v
E --- F --- G [feature]

What happened under the hood?

Git looked at the common ancestor (B), took the history of main (C and D), took the history of feature (E and F), and combined them. Commit G is the merge commit. It has two parent commits: F and D.

Pros: 100% non-destructive. It preserves the exact historical timeline of when things actually happened.
Cons: Your Git graph can quickly become a messy "train track" web if you have many developers merging constantly.

🚀 2. Git Rebase (The Clean History Rewriter)

Rebase takes all the commits from your current branch, lifts them up, and replants them on top of the very last commit of the target branch.

git checkout feature
git rebase main

The Visual Graph After Rebase:

  C --- D [main]
 /       \

A --- B E' --- F' [feature]

What happened under the hood?

Git temporarily blew away commits E and F. It caught your feature branch up to main's latest commit (D). Then, it applied your changes back on top as brand-new commits (E' and F').
Notice they are named E' and F' now. They have entirely new SHA hashes because their parent commit changed from B to D.

Pros: Creates a perfectly linear, beautiful history. No messy merge commits.
Cons: It rewrites history. Never rebase a public branch that other people are actively pulling from. You will break their local repositories.

🍒 3. Git Cherry-Pick (The Surgical Precision Tool)

Sometimes you do not want an entire branch. You just want one specific fix or feature from another branch. Cherry-picking grabs a single commit by its SHA hash and copies it onto your current branch.
Imagine we are back at our starting point, and we only want commit C from main, but we want to ignore commit D.

git checkout feature
git cherry-pick

The Visual Graph After Cherry-Pick:

  C --- D  [main]
 /

A --- B
\
E --- F --- C' [feature]

What happened under the hood?

Git copied the exact code changes introduced in C, generated a brand-new commit (C'), and pasted it right onto the tip of your feature branch.

Pros: Highly targeted. Great for pulling a critical bug fix into a release branch without pulling unfinished features.
Cons: It duplicates commits. C and C' contain the exact same changes but live in different places with different hashes.

🧠 Cheat Sheet: When to Use Which?

Command	Best Use Case	Risk Level	Effect on History
git merge	Merging a completed feature into main.	🟢 Safe	Preserves actual history; adds a merge commit.
git rebase	Updating your local feature branch with upstream changes before making a PR.	🔴 High	Rewrites history; keeps graph completely linear.
git cherry-pick	Grabbing a hotfix from a dev branch straight into production.	🟡 Medium	Duplicates a single commit onto your current branch.

The Golden Rule of Git: If your branch is shared with other developers on GitHub, use merge. If the branch exists only on your local computer, use rebase to keep things clean.

Which of these strategies does your team use at work or on open-source projects? Let me know in the comments!

How I Pushed My .env and Database to GitHub (And How to Fix It)

Mercy Moraa — Thu, 30 Jul 2026 08:41:33 +0000

We have all been there. You are excited about a project, your code finally works, and you rush to push it to GitHub. You type git add ., git commit, and git push.
Then, reality hits you. You just published your database credentials and secret API keys to a public repository.
When I was an amateur developer, I did exactly this. I accidentally pushed both my .env file and a local SQLite database file to GitHub. It felt like the end of the world, but it was one of the best learning experiences of my career.

Here is exactly what went wrong, how I fixed it, and how you can prevent it from ever happening to you.

🚨 The Disaster: What Actually Happened

Like many beginners, I treated Git like a simple backup tool rather than a version control system. I had a standard Node.js project structure:

my-awesome-app/
├── node_modules/
├── src/
├── .env <-- Contains database passwords & API keys!
├── database.db <-- Contains actual application data!
├── package.json
└── server.js

I blindly ran git add .. Because I had not configured my project to ignore confidential files, Git happily tracked .env and database.db and pushed them straight to a public GitHub repository.

Why this is dangerous:

GitHub Scrapers: Bots constantly scan public commits for terms like DB_PASSWORD or AWS_SECRET. Your credentials can be stolen within seconds.
Data Leakage: Pushing a database file exposes your users' private data or your hard-earned test data to the entire world.

🛠️ The Immediate Fix: How to Clean It Up

Simply deleting the file and making a new commit does not work. Git remembers everything. The sensitive files will still exist in your commit history, and anyone can look back and find them.
If you just did this, follow these steps immediately to wipe the files from your history and secure your project.

Step 1: Add the files to .gitignore

Create a file named .gitignore in your root folder (if you do not have one yet) and add these lines:

.env
*.db

Step 2: Purge the files from Git tracking

Tell Git to stop tracking these files without deleting them from your local computer:

git rm --cached .env
git rm --cached database.db

Step 3: Completely wipe them from your history

To completely erase the files from past commits, use the filter-repo tool or this built-in Git command:

git filter-branch --force --index-filter \"git rm --cached --ignore-unmatch .env database.db" \
--prune-empty --tag-name-filter cat -- --all

Step 4: Force push the clean history

Update GitHub with your scrubbed history. Warning: This overwrites the remote repository.

git push origin --force --all

Step 5: Rotate your secrets! (Crucial)

Assume your keys are already compromised. Go to your database provider or API dashboard and regenerate every single password and token that was in that .env file.

🛡️ Prevention: How to Protect Your Code Moving Forward

Mistakes happen, but automation ensures they only happen once. Here is how to bulletproof your future repositories.

1. Use an .env.example file

Never leave future developers (or yourself) guessing what variables the project needs. Create an .env.example file that contains the keys but leaves the values blank. Commit this file safely to GitHub.

.env.example

PORT=3000
DATABASE_URL=your_database_url_here
API_SECRET_KEY=your_secret_key_here

2. Install a Global Gitignore

Prevent yourself from making this mistake across all future projects. Set up a global ignore file on your computer for databases and system files.

git config --global core.excludesfile ~/.gitignore_global
echo "*.db" >> ~/.gitignore_global

3. Use git-secrets or Pre-Commit Hooks

You can install tools like git-secrets or use a pre-commit hook package like husky. These tools automatically scan your code for secrets before allowing a commit to go through, blocking the action if a password or .env pattern is detected.

💡 Conclusion: Normalize Mistakes, Maximize Security

Making mistakes is a fundamental part of the developer journey. Pushing a secret to GitHub feels terrible in the moment, but it forces you to learn about Git history management, environment isolation, and security best practices.
Have you ever accidentally leaked a credential? What tools do you use to prevent it? Let me know in the comments below!

Navigating Bitcoin Core: A Developer Introduction to Scripting the Blockchain

Mercy Moraa — Mon, 08 Jun 2026 19:31:34 +0000

Most developers look at blockchain technology from a high-level perspective, interacting only with distant third-party APIs or abstract web3 libraries. But if you want to understand the raw operational realities of decentralized networks, you have to look under the hood.

Interacting directly with a local node bypasses the middleman, offering complete control over wallet structures, manual block mining, and ledger analysis.

Let us break down the exact operational steps required to initialize a local Bitcoin testing architecture, manage automated transaction states, and lay the foundation for script-driven interactions.

The Foundation: Localized Testing Environments

When developing network applications, testing logic on a live public network is highly inefficient. Instead, developers rely on local environments like Regtest (Regression Test).

Unlike a public Testnet, a Regtest environment is a completely private, isolated blockchain network created instantly on your local machine. You possess absolute authority over the network dynamics: you can simulate network latency, generate blocks on demand without complex computing hardware, and instantly fund test wallets.

Initializing Bitcoin Core for Development

To configure a local sandbox, your daemon configuration file (bitcoin.conf) requires explicit settings to ensure isolation and enable external control capabilities:

# Force running on a local, private regression testing network
regtest=1

# Run the daemon in the background as a headless service
daemon=1

# Enable the JSON-RPC HTTP server for external application scripts
server=1

# Explicit authentication credentials for software connections
rpcuser=dev_user
rpcpassword=secure_dev_password

With these parameters active, starting the service creates a fresh genesis block, ready for programmatic operations.

Step 1: Wallet Topology and Address Derivation

In modern cryptographic ledgers, wallets are collections of keys rather than physical containers of coins. Interaction begins by initializing a dedicated descriptor wallet via the Command Line Interface (CLI).

Using the native interface, creating a baseline wallet requires pointing directly to your local runtime instance:

bitcoin-cli -regtest createwallet "dev_wallet_alpha"

Once a secure container exists, the node can calculate individual receiving destinations.

Address Variations and SegWit

When requesting a new address, you have to choose an address format. Bitcoin architecture has evolved through several major structural shifts, impacting fee optimization and validation rules:

Legacy (P2PKH): Addresses starting with a 1. They represent old-school transaction structures where scripts are explicitly exposed on the ledger.
Nested SegWit (P2SH): Addresses starting with a 3. This format acts as a wrapper, allowing legacy software to interact with modernized protocol optimizations.
Native SegWit (Bech32): Addresses starting with bc1q. This is the optimized standard for modern systems. It drastically reduces transaction data size by splitting signature data (witness) from the main transactional block, directly lowering transaction fees.

To generate a modern Native SegWit destination key for testing, execute:

bitcoin-cli -regtest getnewaddress "funding_node" "bech32"

Step 2: Minting Blocks and Earning Coinbase Rewards

On a live network, mining blocks requires immense thermodynamic computational energy. On a Regtest node, however, you can trigger block production instantly using structural developer commands.

When a block is appended to the ledger, the system awards a Coinbase Reward—newly minted tokens allocated to the block producer. This is the mechanism used to fund a local development environment.

To mint blocks and deposit the rewards into your newly generated address:

bitcoin-cli -regtest generatetoaddress 101 "bc1q..."

The 100-Block Maturity Rule

Notice the parameter 101. In the protocol code, coinbase rewards cannot be spent immediately. They are subject to a 100-block maturity rule. A minted reward must be buried under at least 100 subsequent blocks before the network consensus rules permit it to be used as an input for a standard transaction. Minting 101 blocks unlocks the reward from the very first block, giving you an active spendable balance.

Step 3: Transaction Structuring and Ledger Analysis

With an active spendable balance, you can simulate asset movement across separate local entities.

When you instruct a wallet to transfer value, the node automatically builds a new transaction, signs it using your private keys, and broadcasts it to the local memory pool (mempool) awaiting validation:

bitcoin-cli -regtest sendtoaddress "bc1q_destination_address_here" 1.5

At this stage, the transaction is unconfirmed. It sits in a pending state until you execute another generatetoaddress command to forge a new block, sealing the transaction into the ledger history.

Programmatic Inspection

To analyze the block contents or inspect individual transaction data arrays directly from the node storage records, use the tracking hashes provided by the runtime logs:

# Retrieve full data array regarding a specific block ID
bitcoin-cli -regtest getblock "block_hash_string"

# Inspect the exact inputs, outputs, and validation signatures of a transaction
bitcoin-cli -regtest getrawtransaction "txid_string" true

Analyzing this raw JSON data exposes the core design of the network: an interconnected chain of UTXOs (Unspent Transaction Outputs), where every transaction completely consumes old outputs to generate fresh ones.

Moving Forward: Automation with Python

Manually typing terminal commands is fine for initial exploration, but production-grade development requires automation. Because Bitcoin Core exposes a standard JSON-RPC interface, you can completely automate your local node using Python.

Instead of writing raw HTTP network wrappers, you can leverage the native authproxy library provided in the official source code, allowing you to trigger actions programmatically:

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

# Connect directly to the local Regtest daemon using your configuration file settings
rpc_connection = AuthServiceProxy("http://dev_user:secure_dev_password@127.0.0.1:18443")

try:
    # Retrieve system info programmatically
    blockchain_info = rpc_connection.getblockchaininfo()
    print(f"Current Block Height: {blockchain_info['blocks']}")

    # Automate address creation
    new_addr = rpc_connection.getnewaddress("automated_script_wallet")
    print(f"Generated Automated Destination: {new_addr}")

except JSONRPCException as e:
    print(f"RPC Error detected: {e}")

Connecting Python automation scripts directly to a secure local node unlocks endless possibilities. You can safely build automated tax compliance tools, custom auditing trackers, or real-time cryptographic accounting systems without any reliance on third-party frameworks.

The power of the decentralized web lies in self-sovereign code execution. Run your own nodes, analyze the raw primitives, and write clean, resilient systems.

Happy coding!

Building ML Pipelines with Python: From Data to Insights

Mercy Moraa — Sun, 07 Jun 2026 01:32:13 +0000

In machine learning, writing a script that trains a model on a clean dataset is only a fraction of the work. The real challenge lies in building a system that can reliably ingest raw data, transform it, train a model, and serve predictions in production.

When code is written as a series of disconnected Jupyter Notebook cells, it inevitably becomes brittle, difficult to test, and prone to data leakage. The solution is to transition from isolated scripts to structured Machine Learning Pipelines. A pipeline automates the workflow, ensures reproducibility, and bridges the gap between data science and software engineering.

Let us build an end-to-end Machine Learning pipeline using pure Python and the industry-standard scikit-learn framework.

What is an ML Pipeline?

An ML pipeline binds data preprocessing steps and model execution into a single, cohesive software element.

Instead of manually applying transformations to your training data and remembering to apply those exact same transformations to your testing data, the pipeline executes the sequence automatically. This design completely eliminates data leakage—a common error where information from outside the training dataset is accidentally used to train the model, leading to overly optimistic but invalid evaluation metrics.

Step 1: Setting Up the Environment

To follow along, initialize a clean workspace and install the core data science libraries:

pip install numpy pandas scikit-learn

Step 2: Designing the Complete Pipeline Code

We will build a pipeline that handles a realistic, messy dataset containing both numerical features (which need scaling) and categorical features (which need encoding), followed by a classification model.

Create a file named pipeline.py and implement the following structure:

import numpy as np
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.impute import SimpleImputer
from sklearn.preprocessing import StandardScaler, OneHotEncoder
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report

# 1. Simulate a realistic raw dataset
def generate_mock_data():
    np.random.seed(42)
    n_samples = 1000

    data = {
        'age': np.random.choice([np.nan, 25, 34, 45, 52, 61], size=n_samples),
        'income': np.random.choice([50000, 80000, 120000, np.nan], size=n_samples),
        'department': np.random.choice(['Sales', 'Engineering', 'Marketing', None], size=n_samples),
        'purchased': np.random.choice([0, 1], size=n_samples, p=[0.7, 0.3])
    }

    df = pd.DataFrame(data)
    # Replace the string "None" with proper NaN values so the imputer can detect them
    df['department'] = df['department'].replace('None', np.nan)
    return df

def main():
    # Load raw data
    df = generate_mock_data()

    # Separate features (X) and target label (y)
    X = df.drop(columns=['purchased'])
    y = df['purchased']

    # Split into train and test sets before any preprocessing occurs
    X_train, X_test, y_train, y_test = train_test_split(
        X, y, test_size=0.2, random_state=42
    )

    # 2. Define feature groups
    numeric_features = ['age', 'income']
    categorical_features = ['department']

    # 3. Create sub-transformers for different data types
    numeric_transformer = Pipeline(steps=[
        ('imputer', SimpleImputer(strategy='median')),   # Fill missing values with median
        ('scaler', StandardScaler())                     # Scale values to standard normal distribution
    ])

    categorical_transformer = Pipeline(steps=[
        ('imputer', SimpleImputer(strategy='most_frequent')),  # Fill missing text with mode
        ('encoder', OneHotEncoder(handle_unknown='ignore'))     # Convert text strings to numeric vectors
    ])

    # 4. Combine transformers using ColumnTransformer
    preprocessor = ColumnTransformer(
        transformers=[
            ('num', numeric_transformer, numeric_features),
            ('cat', categorical_transformer, categorical_features)
        ]
    )

    # 5. Build the master pipeline (Preprocessing + Model Estimator)
    clf_pipeline = Pipeline(steps=[
        ('preprocessor', preprocessor),
        ('classifier', RandomForestClassifier(n_estimators=100, random_state=42))
    ])

    # 6. Train the entire pipeline with a single call
    # Transformations are fitted strictly on training data
    clf_pipeline.fit(X_train, y_train)

    # 7. Evaluate performance
    # Test data is passed through the pre-fit transformations automatically
    predictions = clf_pipeline.predict(X_test)

    print("--- Model Performance Metrics ---")
    print(classification_report(y_test, predictions))

if __name__ == '__main__':
    main()

Step 3: Unpacking the Architectural Choices

ColumnTransformer

Real-world data is heterogeneous. Your code needs to treat numerical values differently than strings. The ColumnTransformer lets you isolate specific columns and apply dedicated processing sub-pipelines to them in parallel, before stitching them back together into a unified matrix for the machine learning algorithm.

Streamlined Inference

Notice the execution phase: clf_pipeline.fit(X_train, y_train) handles the entire transformation and training sequence. When it is time to make a prediction on new, raw data, you simply call clf_pipeline.predict(X_new). You do not need to repeat the code for scaling or filling empty data blocks; the pipeline remembers the mathematical rules established during the training step.

Step 4: Production Deployment Strategy

Once your pipeline compiles and performs well, it needs to move out of your local development environment.

Model Serialization

To save the entire trained pipeline—including both the data preprocessing weights and the model parameters—use joblib. It is the recommended serialization tool in the scikit-learn ecosystem as it handles large numpy arrays more efficiently than pickle:

import joblib

# Persist the entire trained pipeline object to disk
joblib.dump(clf_pipeline, 'ml_pipeline.pkl')

To load the pipeline later for inference:

# Load the pipeline in a production script or notebook
clf_pipeline = joblib.load('ml_pipeline.pkl')

# Predict on brand new raw data
predictions = clf_pipeline.predict(new_data)

Serving via API

In a production deployment, an API service layer (such as FastAPI) loads this single serialized file into memory on startup. When a user submits raw data via a JSON endpoint, the raw payload is converted directly into a Pandas DataFrame and passed straight to .predict(). This structural cleanliness guarantees that data transformations in production match your training conditions exactly.

Summary Principles for Clean ML Engineering

Split First, Transform Second: Always execute train_test_split before configuring transforms. If you calculate the mean or median of a column using the entire dataset, your model is subtly cheating by seeing data from the test set.
Handle Missing Values Correctly: Ensure that placeholder strings like "None" or "NaN" are converted to proper np.nan values so that SimpleImputer can detect and fill them appropriately. Failing to do this treats them as valid categories and introduces noise into your model.
Handle Unknown Labels: When configuring categorical encoders, always include parameters like handle_unknown='ignore'. This prevents your API from crashing if a user inputs a completely new category in production that wasn't present during training.
Version Your Artifacts: Treat your pipeline binary file like source code. If the data schemas or hyperparameters change, tag the exported file version cleanly so you can easily rollback if production anomalies occur.

Transitioning from raw scripting blocks to structured object-oriented pipelines makes your code reliable, clean, and immediately ready for modern deployment architectures.

Happy coding!

Getting Started with Go: A Beginner's Journey

Mercy Moraa — Sun, 07 Jun 2026 01:14:00 +0000

If you told me a few months ago that I would be obsessed with pointers, memory allocation, and low-level strings manipulation, I probably would have laughed. But here I am, deep into a rigorous technical software development program, and completely falling in love with Go (Golang).

Go was designed by Google to be simple, blazing fast, and highly concurrent. While it handles heavy backend architectures globally, it is also one of the most rewarding languages to learn as a beginner, no matter where you are in the world.

In this article, I want to share my raw insights from an intense tech training environment, unpack Go's fundamental layout, and help you build your very first Command Line Interface (CLI) application using nothing but the Go Standard Library. No cheat frameworks. No heavy external dependencies. Just raw logic.

Why Go?

When you start learning Go in a strict environment, you quickly realize it doesn't hold your hand like Python, but it isn't as terrifyingly manual as C. It sits in the perfect sweet spot:

Strict Compilation: If you import a package or declare a variable and don't use it, your code will not compile. This forces you to write clean, minimal code from day one.
Blazing Fast: It compiles directly to machine code, which means it runs incredibly fast.
Standard Library Power: Go’s built-in tools (net/http, os, strconv) are so powerful that you rarely need to download external packages to build production-grade tools.

Step 1: Setting Up Your Workspace

Before writing code, initialize your project workspace. Open your terminal and run:

mkdir go-beginner-cli
cd go-beginner-cli
go mod init go-beginner-cli

This creates a go.mod file, which manages your application's path and dependencies.

Step 2: Understanding the Base Structure

Every execution file in Go follows a strict anatomy. Create a main.go file and inspect this template:

package main

import (
    "fmt"
)

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

The Breakdown:

package main: Tells the Go compiler that this file should compile as an executable program rather than a shared utility library.
import: Brings in standard tools. Here, "fmt" (Format) handles console input and output.
func main(): The ultimate entry point. When you run your program, execution starts exactly here.

To execute it, run:

go run main.go

Step 3: Building Your First App ; A Dynamic CLI Case Converter

Let’s move past "Hello World" and build a practical CLI application. We will write a tool that accepts a string argument from the terminal and modifies it based on what the user wants (Uppercase or Lowercase).

We will use the native os package to capture terminal input arguments (os.Args).

Replace the contents of main.go with the following code:

package main

import (
    "fmt"
    "os"
    "strings"
)

func main() {
    // os.Args[0] is always the program name itself.
    // We expect: program_name, string_to_modify, and mode (up/low)
    if len(os.Args) < 3 {
        fmt.Println("Usage: go run . [text] [up|low]")
        return
    }

    inputText := os.Args[1]
    mode := os.Args[2]

    switch mode {
    case "up":
        result := strings.ToUpper(inputText)
        fmt.Println("Result:", result)
    case "low":
        result := strings.ToLower(inputText)
        fmt.Println("Result:", result)
    default:
        fmt.Println("Unknown mode! Use 'up' for uppercase or 'low' for lowercase.")
    }
}

How to Run Your New CLI Tool:

Test your application directly from your terminal pane by passing arguments:

Test 1: Uppercase Mod

go run . "learning go is awesome" up
# Output: Result: LEARNING GO IS AWESOME

Test 2: Lowercase Mod

go run . "GLOBAL DEVELOPERS" low
# Output: Result: global developers

Key Takeaways from My Learning Journey

Building text manipulation tools and algorithmic blueprints from scratch taught me three vital lessons:

Think in Runes, Not Just Strings: In Go, strings are read-only slices of bytes. If you want to handle text properly without breaking special characters, learn to convert your data into []rune.
Handle Errors Safely: Go doesn't use traditional try/catch exceptions. Functions return data and errors explicitly side-by-side. It forces you to deal with errors immediately.
Keep it Simple: The beauty of Go lies in its minimalism. If your function is getting too complex, break it down into smaller structural files under package main.

Wrap Up

This is just the baseline of what you can accomplish. Once you master string tracking and the basic os filesystem controls, you can transition into building full file processors, custom parsers, or high-performance APIs.

Are you currently learning Go or thinking about diving in? Let’s connect in the comments below! Share your favorite Go optimization tips or ask any questions if you are stuck on your own learning pipeline.

Happy coding!