# Discussion: What open source tools make up your developer stack? >> below is a copy(for reference purpose instead of going back to the mailing list) of the content we're discussing in the mailing list(link here: https://groups.google.com/g/nairobi-gnu/c/PhnHsZo5yyg) I would like to discuss and propose this to be written as a blog(Anyone up for it can write it). Could be a series of blogs if we want to dig more into them. I would like to see a practical open source options available for software development from the local setup to production ready systems. The idea here is to make it beginner-friendly for people who may not be familiar with open source alternatives. Some areas we may want to cover can include: * Code editors and IDEs * Development tools and workflows (Git, package managers, debugging) * Containerization (Docker, Podman - when and why to use each) * Databases and storage options * Deployment strategies (VPS, self-hosting, CI/CD) * Monitoring and observability * Optional advanced topics like systems tooling (e.g., eBPF) We can also frame this around real scenarios. For example: >> “If I want to build a production-ready project using only open source tools, what would my stack look like?” The idea is to keep it practical, and maybe we can have a simple project walkthrough we might do. ================================================================== The project idea is portfolio. I'll open this soon in the repo after we've got the idea of how we're going to do it. ## Introduction # Git Reference Guide *Core commands for version control — configuration through branching* --- ## 01 — git config Before using Git, you need to introduce yourself by setting your name and email address. These details are attached to every commit you make. ```bash # Set your name and email globally $ git config --global user.name "username" $ git config --global user.email "email" ``` Configuration can be applied at three levels: - **system** — applies to all users and all repositories on the machine - **global** — applies to all repositories belonging to a specific user - **local** — applies only to a single repository To verify that your configuration has been saved, run: ```bash $ git config --list ``` --- ## 02 — git init Use `git init` to initialise a new Git repository and begin tracking an existing directory. Running this command creates a hidden `.git` directory that holds all the dependencies Git needs for version control. ```bash # Create a new directory and initialise a repo inside it $ mkdir microservices-repo $ cd microservices-repo $ git init ``` You can also pass a directory name as an argument to create and initialise in one step: ```bash $ git init microservices-repo ``` > **Note:** Changes to files are tracked under the `.git/` directory. Git does not automatically save your files — you must stage and commit them manually. --- ## 03 — git add `git add` is the bridge between making changes in your working directory and getting them ready to be permanently stored in the repository. Changes are recognised by Git but not automatically recorded — you must stage them first. ```bash # Create a README file then stage it $ echo "#microservices" > README.md $ git add README.md ``` To stage all files in the current directory at once, use the wildcard: ```bash $ git add * ``` > **Note:** Files that have been changed but not yet staged are said to reside in the **workspace**. Once staged, they are in the **staged** state, ready to be committed. --- ## 04 — git status `git status` shows the current state of your repository — which files have tracked changes and which are untracked. ```bash $ git status ``` After staging a file with `git add`, running `git status` again will confirm that Git now recognises the file as tracked and staged for the next commit. --- ## 05 — git commit `git commit` records the staged changes into the repository's history. Each commit acts as a save point you can return to if needed. ```bash $ git commit -m "Initial commit with microservices" ``` The `-m` flag is followed by a short, descriptive message summarising the changes made. After committing, run `git status` to confirm — if it returns *nothing to commit*, all changes have been saved. A typical workflow follows three steps: 1. Edit your files and make the necessary changes. 2. Stage the files you want included using `git add`. 3. Commit the staged changes with a clear message using `git commit`. --- ## 06 — git log `git log` displays a list of all commits made in a repository in reverse chronological order, with the most recent commit shown first. ```bash $ git log ``` Each entry in the log contains four pieces of information: - **SHA-1 identifier** — a unique signature for the commit, used to reference it in other Git commands - **Committer details** — the name and email of the person who made the commit - **Timestamp** — when the commit was made - **Commit message** — a brief note describing the changes The output can be customised using several flags: | Command | Description | |---|---| | `git log -p` | Shows the full difference introduced at each commit | | `git log --stat` | Shows abbreviated stats for each commit | | `git log --oneline` | Shows each commit as a single compact line | | `git log --graph` | Draws the branch and merge history as an ASCII diagram | | `git log --author="username"` | Filters commits by a specific author | --- ## 07 — git branch While `git commit` builds a linear history, `git branch` lets you create parallel lines of development. Branches can later be merged back together, allowing multiple people to work on different features simultaneously. When a repository is initialised, Git automatically creates a default branch called `main`. Running `git branch` on its own lists all current branches. ```bash # List all branches $ git branch # Create a new branch $ git branch <branch-name> # Create a branch from a specific existing branch $ git branch <new-branch-name> <base-branch-name> # Create a branch from a specific commit $ git branch <new-branch-name> <commit-hash> ``` --- ## 08 — git checkout / git switch In Git, **HEAD** refers to the tip of the branch you are currently working on. Switching your active branch is called checking out. The traditional command for this is `git checkout`; newer versions of Git also offer `git switch` as a more intuitive alternative. ```bash # Switch to an existing branch (classic) $ git checkout app/api.py # Switch to an existing branch (modern) $ git switch app/api.py ``` To create a new branch and switch to it immediately, combine the commands using a single flag: ```bash # Create and switch — classic method $ git checkout -b app/api.py # Create and switch — modern method $ git switch -c app/api.py ``` --- ## 09 — git merge Once work on a branch is complete, use `git merge` to integrate those changes into another branch, typically `main`. ```bash # First switch to the target branch $ git checkout main # Merge the feature branch into main $ git merge app/api.py ``` > **Note:** If both branches contain changes to the same part of a file, Git will flag a conflict and require you to resolve it manually before the merge can complete. --- ## 10 — git branch -d Once a branch has been merged and is no longer needed, it can be deleted to keep the repository clean. ```bash # Delete a local branch $ git branch -d app/api.py ``` > **Note:** Git will prevent deletion if the branch has unmerged changes. Use `-D` (uppercase) to force deletion, though this should be done with care. ---