Introduction to Software Development Methodologies 📊: Part 1

Software development is not just about writing code; it’s about building high-quality, maintainable, and scalable systems that deliver value to users. To achieve this consistently, teams follow structured approaches known as software development methodologies. These methodologies provide a roadmap for planning, designing, developing, testing, and delivering software.

In this three-part blog series, we’ll explore key methodologies and best practices in software development, using Ruby and Ruby on Rails examples wherever appropriate.

🌐 What Are Software Development Methodologies?

Software development methodologies are structured processes or frameworks that guide the planning and execution of software projects. They help teams manage complexity, collaborate effectively, reduce risk, and deliver projects on time.

Common Goals of Any Methodology:

  • Define clear project scope and goals
  • Break down work into manageable tasks
  • Encourage communication among team members
  • Track progress and measure success
  • Deliver working software iteratively or incrementally

💼 Why Methodologies Matter

Without a methodology, software projects often suffer from unclear requirements, missed deadlines, buggy releases, or scope creep. A good methodology:

  • Increases team productivity
  • Ensures better quality and maintainability
  • Reduces time-to-market
  • Improves customer satisfaction

In Ruby and Rails projects, where rapid development is a key feature, following a methodology keeps things under control and makes collaboration more effective.

📖 A Brief Overview of Popular Software Development Methodologies

We’ll explore these in detail in Part 2, but here are the major ones:

1. Waterfall

A linear approach where each phase (Requirements → Design → Implementation → Testing → Deployment) happens one after another.

2. Agile

An iterative and incremental model that encourages adaptive planning, early delivery, and continuous improvement.

3. Scrum

A popular Agile framework that structures work in sprints and emphasizes team roles, ceremonies, and artifacts.

4. Kanban

A flow-based Agile method that uses visual boards to manage work and improve process efficiency.

5. Extreme Programming (XP)

Focuses on engineering excellence, including practices like pair programming, TDD, and continuous integration. Ruby and Rails communities highly embrace XP.

6. DevOps

Combines software development and IT operations to shorten the development lifecycle and deliver high-quality software continuously.

✨ Ruby On Rails: A Natural Fit for Agile and XP

Ruby and Rails were built with developer happiness and productivity in mind. They naturally complement Agile and XP methodologies.

Example:

  • Ruby on Rails encourages convention over configuration, which speeds up development.
  • It supports Test-Driven Development (TDD) out of the box via tools like RSpec and Minitest.
  • Features like scaffolding align well with the iterative nature of Agile.

🔹 Coming Up in Part 2

In the next part of this series, I’ll do a deep dive into each of the above methodologies, with pros, cons, and real-world use cases. I’ll also show examples of how Rails developers apply these in practice.


Stay tuned! 🚀

📋 Software Architect Guide: Designs | Patterns | Coding | Architectures

📝 About

Technical assessment platforms used by employers to screen candidates via timed online tests. Key characteristics include:

  • Mixed question formats: multiple-choice, fill-in-the-blank, coding tasks, and design scenarios.
  • Language & framework coverage: supports Ruby, Rails, React, Angular, AWS, SQL, DevOps and more.
  • Time-boxed: each test typically runs 30–60 minutes, depending on role complexity. Each tests (1/12) allocated 2-8 mins depending on complexity.
  • Auto-grading + manual review: coding tasks are auto-checked against test cases; system-design answers may be manually reviewed.
  • Real-world scenarios: questions often mimic production challenges rather than classic white-board puzzles.

📋 Software Architect Test Structure

On these type of platforms, a Software Architect assessment usually combines:

  1. System & API Design
  2. Coding & Code Review
  3. Architecture Patterns
  4. DevOps & Cloud
  5. Database & Performance
  6. Front-end Integration

Below is a breakdown with sample questions you can practice.

🔧 1. System & API Design

1.1 Design a RESTful API

  • Prompt: Sketch endpoints (URL, HTTP verbs, request/response JSON) for a multi-tenant blogging platform.
  • What’s tested: URI naming, resource nesting, versioning, authentication.

https://railsdrop.com/2025/07/02/software-architect-guide-designing-a-restful-api-for-a-multi-tenant-blogging-platform/

1.2 High-Level Architecture Diagram

  • Prompt: Draw (in ASCII or pseudo-UML) a scalable order-processing system that integrates with payment gateways, queues, and microservices.
  • What’s tested: service decomposition, message brokering, fault tolerance.

Premium: https://railsdrop.com/2025/07/03/software-architect-guide-designing-a-scalable-order-processing-architecture-with-micro-services/


❓Questions

Q) Why is layering an application important while executing a project?

https://railsdrop.com/2025/07/04/software-architect-guide-layering-an-app/

💻 2. Coding & Code Review

2.1 Ruby/Rails Coding Task

2.2 Code Quality Review


🏗️ 3. Architecture Patterns

3.1 Design Patterns Identification

3.2 Event-Driven vs Request-Driven


☁️ 4. DevOps & Cloud (AWS)

4.1 AWS CI/CD Pipeline

4.2 Server Scaling Strategy


🗄️ 5. Database & Performance (SQL)

5.1 Query Optimization

5.2 Schema Design

  • Prompt: Design a relational schema for a multi-language product catalog, ensuring easy localization and high read throughput.
  • What’s tested: normalization, partitioning/sharding strategies.

🌐 6. Front-end Integration

6.1 React Component Design

  • Prompt: Build a stateless React component that fetches and paginates API data. Outline props, state hooks, and error handling.
  • What’s tested: Hooks, prop-drilling vs context, error boundaries.

6.2 Angular vs React Trade-offs

  • Prompt: Compare how you’d structure a large-scale dashboard in Angular vs React. Focus on modules, lazy loading, and state management.
  • What’s tested: NgModules, Redux/MobX/NgRx, bundle splitting.

6.3 React Native Considerations

  • Prompt: You don’t have React Native experience—explain how you’d architect code-sharing between web (React) and mobile (React Native).
  • What’s tested: Monorepo setups (e.g. Yarn Workspaces), shared business logic, native module stubs.

💡Preparation Tips

  • Hands-on practice: Spin up mini-projects (e.g. Rails API with React front-end, deployed on AWS).
  • Mock interviews: Time yourself on similar Platform problems—aim for clarity and brevity.
  • Review fundamentals: Brush up on design patterns, AWS core services, SQL indexing strategies, and front-end state management.
  • Document trade-offs: Always justify architecture decisions with pros/cons.

Good luck, Architect to Greatness! 🚀

The Container ⛴️ Revolution: How Docker 🐳 Transformed Dev & What’s Ahead

Containerization has reshaped the way we build, ship, and run applications. From simplifying dependency management to enabling micro-services architectures at scale, containers and orchestration platforms like Kubernetes have become cornerstones of modern DevOps. In this post, we’ll explore:

  1. What are containers, and what is containerization?
  2. A brief history and evolution of Kubernetes.
  3. Docker: what it is, how it works, and why it matters.
  4. When Docker emerged and the context before and after.
  5. The impact on the development lifecycle.
  6. Docker’s relevance in 2025 and beyond.
  7. Use cases: when to use—or avoid—Docker.
  8. Feature evolution in Docker.
  9. The future of Docker and containerization in web development.
  10. Where Do Developers Get Containers? How Do They Find the Right Ones?
  11. What Is Docker Hub? How Do You Use It?
  12. Can You Use Docker Without Docker Hub?

1. What Are Containers ⛴️ and What Is Containerization?

  • Containers are lightweight, standalone units that package an application’s code along with its dependencies (libraries, system tools, runtime) into a single image.
  • Containerization is the process of creating, deploying, and running applications within these containers.
  • Unlike virtual machines, containers share the host OS kernel and isolate applications at the process level, resulting in minimal overhead, rapid startup times, and consistent behavior across environments.

Key benefits of containerization

  • Portability: “Build once, run anywhere” consistency across dev, test, and prod.
  • Efficiency: Higher density—hundreds of containers can run on a single host.
  • Isolation: Separate dependencies and runtime environments per app.
  • Scalability: Containers can be replicated and orchestrated quickly.

2. ☸️ Kubernetes: A Brief History and Evolution

  • Origins (2014–2015): Google donated its internal Borg system concepts to the Cloud Native Computing Foundation (CNCF), and Kubernetes 1.0 was released in July 2015.
  • Key milestones:
    • 2016–2017: Rapid ecosystem growth—Helm (package manager), StatefulSets, DaemonSets.
    • 2018–2019: CRDs (Custom Resource Definitions) and Operators enabled richer automation.
    • 2020–2022: Focus on security (Pod Security Admission), multi-cluster federation (KubeFed), and edge computing.
    • 2023–2025: Simplified configurations (Kustomize built-in), tighter GitOps integrations, serverless frameworks (Knative).

Why Kubernetes matters

  • Automated scheduling & self-healing: Pods restart on failure; replicas ensure availability.
  • Declarative model: Desired state is continuously reconciled.
  • Extensibility: CRDs and Operators let you automate almost any workflow.

3. What Is Docker 🐳 and How It Works?

  • Docker is an open-source platform introduced in 2013 that automates container creation, distribution, and execution.
  • Core components:
    • Dockerfile: Text file defining how to build your image (base image, dependencies, commands).
    • Docker Engine: Runtime that builds, runs, and manages containers.
    • Docker Hub (and other registries): Repositories for sharing images.

How Docker works

  1. Build: docker build reads a Dockerfile, producing a layered image.
  2. Ship: docker push uploads the image to a registry.
  3. Run: docker run instantiates a container from the image, leveraging Linux kernel features (namespaces, cgroups) for isolation.

4. When Did Docker Emerge, and Why?

  • Launch: March 13, 2013, with the first open-source release of Docker 0.1 by dotCloud (now Docker, Inc.).
  • Why Docker?
    • Prior container tooling (LXC) was fragmented and complex.
    • Developers needed a standardized, user-friendly workflow for packaging apps.
    • Docker introduced a simple CLI, robust image layering, and a vibrant community ecosystem almost overnight.

5. Scenario Before and After Docker: Shifting the Development Lifecycle ♻️

AspectBefore DockerAfter Docker
Environment parity“It works on my machine” frustrations.Identical containers in dev, test, prod.
Dependency hellManual installs; conflicts between apps.Encapsulated in image layers; side-by-side.
CI/CD pipelinesCustom scripts per environment.Standard docker builddocker run steps.
ScalingVM spin-ups with heavy resource use.Rapid container spin-up, minimal overhead.
IsolationLesser isolation; port conflicts.Namespace and cgroup isolation per container.

Docker transformed workflows by making builds deterministic, tests repeatable, and deployments faster—key enablers of continuous delivery and microservices.


6. Should We Use Docker in 2025?

Absolutely—Docker (and its underlying container technologies) remains foundational in 2025:

  • Cloud-native architectures place containers at their core.
  • Serverless platforms often run functions inside containers (AWS Lambda, Azure Functions).
  • Edge deployments leverage containers for lightweight, consistent runtimes.
  • Developer expectations: Instant local environments via docker-compose.

However, the ecosystem has matured, and alternatives like Podman (daemonless) and lightweight sandboxing (Firecracker VMs) also coexist.


7. When to Use or Not Use Docker

Use CaseDocker Fits Well?Notes
Microservices / APIs✔ YesIndividual services packaged and scaled independently.
Monolithic apps✔ Generally beneficialSimplifies env setup, but added container overhead may be minimal.
High-load, high-latency apps✔ Yes, with orchestration (K8s).Autoscaling, rolling updates, resource quotas critical.
Simple frontend only apps✔ YesServe static assets via lightweight Nginx container.
Legacy desktop-style apps⚠️ MaybeMight add unnecessary complexity if no cloud target.

Key considerations

  • Use Docker for consistent environments, CI/CD integration, and horizontal scaling.
  • Avoid Docker when low latency on bare metal is paramount, or where container overhead cannot be tolerated (e.g., certain HPC workloads).

8. Is Docker Evolving? Key Feature 🧩Highlights

Docker continues to innovate:

  • Rootless mode (runs without root privileges) for enhanced security.
  • BuildKit improvements for faster, cache-efficient image builds.
  • Docker Extensions for community-driven tooling inside the Docker Desktop UI.
  • Improved Windows support with Windows containers and WSL2 integrations.
  • OCI compliance: Better compatibility with other runtimes (runc, crun) and registries.

9. Is Docker Needed for Future Web Development? What’s Next?

  • Containerization as standard: Even if Docker itself evolves or gives way to new runtimes, the model of packaging apps in isolated, immutable units is here to stay.
  • Serverless + containers: The blending of function-as-a-service and container workloads will deepen.
  • Edge computing: Tiny, specialized containers will power IoT and edge gateways.
  • Security focus: Sandboxing (gVisor, Firecracker) and supply-chain scanning will become default.

While tooling names may shift, the core paradigm—lightweight, reproducible application environments—remains indispensable.


10. Where Do Developers Get Containers? How Do They Find the Right Ones?

Developers get containers in the form of Docker images, which are blueprints for running containers.

These images can come from:

  • Docker Hub (most popular)
  • Private registries like GitHub Container Registry, AWS ECR, Google Container Registry, etc.
  • Custom-built images using Dockerfile

When looking for the right image, developers usually:

  • Search Docker Hub or other registries (e.g., redis, nginx, node, postgres)
  • Use official images, which are verified and maintained by Docker or vendors
  • Use community images, but carefully—check for:
    • Dockerfile transparency
    • Recent updates
    • Number of pulls and stars
    • Trust status (verified publisher)

Example search:
If you want Redis:

docker search redis


11. What Is Docker Hub? How Do You Use It?

Docker Hub is Docker’s official cloud-based registry service where:

  • Developers publish, store, share, and distribute container images.
  • It hosts both public (free and open) and private (restricted access) repositories.

Key Features:

  • Official images (e.g., python, mysql, ubuntu)
  • User & org accounts
  • Web UI for managing repositories
  • Pull/push image support
  • Image tags (e.g., node:18-alpine)

Basic usage:

🔍 Find an image
You can search on https://hub.docker.com or via CLI:

docker search nginx

📥 Pull an image

docker pull nginx:latest

▶️ Run a container from it

docker run -d -p 80:80 nginx

📤 Push your image

  1. Log in:
docker login

  1. Tag and push:
docker tag myapp myusername/myapp:1.0  
docker push myusername/myapp:1.0


12. Can You Use Docker Without Docker Hub?

Yes, absolutely!
You don’t have to use Docker Hub if you prefer alternatives or need a private environment.

Alternatives:

  • Private Docker Registry: Host your own with registry:2 image docker run -d -p 5000:5000 --name registry registry:2
  • GitHub Container Registry (GHCR)
  • Amazon ECR, Google GCR, Azure ACR
  • Harbor – open-source enterprise container registry

Use case examples:

  • Enterprise teams: often use private registries for security and control.
  • CI/CD pipelines: use cloud provider registries like ECR or GCR for tighter cloud integration.
  • Offline deployments: air-gapped environments use custom registries or local tarball image transfers.

✅ Summary

QuestionAnswer
Where do devs get containers?From Docker Hub, private registries, or by building their own images.
What is Docker Hub?A public registry for discovering, pulling, and sharing Docker images.
Can Docker work without Docker Hub?Yes—via self-hosted registries or cloud provider registries.

Conclusion

From Docker’s debut in 2013 to Kubernetes’ rise in 2015 and beyond, containerization has fundamentally altered software delivery. In 2025, containers are ubiquitous: in microservices, CI/CD, serverless platforms, and edge computing. Understanding when—and why—to use Docker (or its successors) is critical for modern developers. As the ecosystem evolves, containerization principles will underpin the next generation of web and cloud-native applications.

Happy Dockerizing! 🚀


Setting Up ⚙️ SSH in your system

SSH (Secure Shell) is used to establish secure remote connections over an unsecured network, enabling secure access, management, and data transfer on remote systems, including running commands, transferring files, and managing applications.

Setup SSH keys:

To create an SSH key and add it to your GitHub account, follow these steps:

1. Generate an SSH Key

ssh-keygen -t ed25519 -C "your-email@example.com"
  • Replace "your-email@example.com" with your GitHub email.
  • If prompted, press Enter to save the key in the default location (~/.ssh/id_ed25519).
  • Set a passphrase (optional for security).

2. Start the SSH Agent

eval "$(ssh-agent -s)"

3. Add the SSH Key to the Agent

ssh-add ~/.ssh/id_ed25519

4. Copy the SSH Key to Clipboard

cat ~/.ssh/id_ed25519.pub | pbcopy   # macOS
cat ~/.ssh/id_ed25519.pub | xclip -selection clipboard   # Linux
clip < ~/.ssh/id_ed25519.pub   # Windows (Git Bash)

(If xclip is not installed, use sudo apt install xclip on Linux)


5. Add the SSH Key to GitHub

  • Go to GitHub → Settings → SSH and GPG keys (GitHub SSH Keys).
  • Click New SSH Key.
  • Paste the copied key into the field and give it a title.
  • Click Add SSH Key.

6. Test the SSH Connection

ssh -T git@github.com

You should see a message like:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Now you can clone, push, and pull repositories without entering your GitHub password!

You may be wondering what is ed25519 ?

ed25519 is a modern cryptographic algorithm used for generating SSH keys. It is an alternative to the older RSA algorithm and is considered more secure and faster.

Why Use ed25519 Instead of RSA?

  1. Stronger Securityed25519 provides 128-bit security, while RSA requires a 4096-bit key for similar security.
  2. Smaller Key Size – The generated keys are much shorter than RSA keys, making them faster to use.
  3. Faster Performanceed25519 is optimized for speed, especially on modern hardware.
  4. Resistant to Certain Attacks – Unlike RSA, ed25519 is resistant to side-channel attacks.

Why GitHub Recommends ed25519?

  • Since 2021, GitHub suggests using ed25519 over RSA because of better security and efficiency.
  • Older RSA keys (e.g., 1024-bit) are now considered weak.

When Should You Use ed25519?

  • Always, unless you’re working with old systems that do not support it.
  • If you need maximum security, speed, and smaller key sizes.

Example: Creating an ed25519 SSH Key

ssh-keygen -t ed25519 -C "your-email@example.com"

This creates a strong and secure SSH key for GitHub authentication.

What is the SSH Agent?

The SSH agent is a background process that securely stores your SSH private keys and manages authentication.

Instead of entering your private key passphrase every time you use SSH (e.g., for git push), the agent remembers your key after you add it.


Why Do We Need the SSH Agent?

  1. Avoid Entering Your Passphrase Repeatedly
  • If your SSH key has a passphrase, you would normally need to enter it every time you use git push or ssh.
  • The agent caches the key in memory so you don’t need to enter the passphrase every time.
  1. Automatic Authentication
  • Once the agent has your key, it can sign SSH requests for authentication automatically.
  1. Keeps Your Private Key Secure
  • Your private key stays in memory and is not exposed on disk after adding it.

What Do These Commands Do?

1️⃣ Start the SSH Agent

eval "$(ssh-agent -s)"
  • This starts the SSH agent in the background.
  • The eval "$(ssh-agent -s)" command initializes the agent and prints its process ID (PID), confirming it’s running.

2️⃣ Add the SSH Key to the Agent

ssh-add ~/.ssh/id_ed25519
  • This adds your private key (~/.ssh/id_ed25519) to the agent.
  • Now, the agent will remember the key and use it when making SSH connections.

How to Check If Your Key is Added?

Run:

ssh-add -l

This lists all keys currently added to the agent. If your key is listed, it means the agent is working correctly.


Example: How This Helps?

Without the agent:

git push origin main
# Every time, you need to enter your SSH passphrase

With the agent:

ssh-add ~/.ssh/id_ed25519
git push origin main
# No need to enter your passphrase again!

Conclusion
  • The SSH agent stores your private key securely in memory.
  • It automates authentication, so you don’t need to enter your passphrase for every SSH request.
  • Adding the key with ssh-add lets Git and SSH use it without prompting.

Now, you can git push and git pull seamlessly!

But the question is: Can this make unauthorized persons to access with this commands without ssh passphrase?


Does using ssh-agent make your system less secure? Let’s break it down.

Can Someone Else Use My SSH Key Without a Passphrase?

✅ No, If Your System is Secure

  • The SSH agent only runs under your user session.
  • Other users on the same machine cannot access your agent.
  • Your private key is never written to disk in an unprotected way.
  • The agent only allows authentication, not direct access to your key.

⚠️ Yes, If Someone Gets Access to Your Session

  • If an attacker gains access to your system (e.g., via malware, or if you leave your computer unlocked), they might use your active SSH agent to authenticate without needing your passphrase.
  • However, they cannot extract your private key from the agent.

How to Improve Security?

If you want extra security, here are a few things you can do:

1️⃣ Remove Keys from Agent When Not Needed

After using your SSH key, you can remove it from the agent:

ssh-add -D

This removes all stored keys. Next time you push, you’ll need to re-enter your passphrase.


2️⃣ Use -t (Timeout) for Auto Removal

To automatically remove the key after a set time:

ssh-add -t 3600 ~/.ssh/id_ed25519  # Removes the key after 1 hour


3️⃣ Lock Your Screen When Away

If someone gets access to your logged-in session, they could use your agent to authenticate without needing the passphrase.

Always lock your screen (Ctrl + L or Win + L on Windows/Linux, Cmd + Ctrl + Q on Mac) when stepping away.


4️⃣ Disable Agent Forwarding (Extra Security)

By default, SSH agent forwarding (ssh -A) can expose your keys to remote servers. If you don’t need it, disable it by editing:

nano ~/.ssh/config

And adding:

Host *
    ForwardAgent no

Summary
  1. The SSH agent only runs in your session, so no one else can access it unless they get control of your user session.
  2. Attackers cannot steal your private key from the agent, but if they have access to your session, they could use it.
  3. To be safe, remove keys when not needed (ssh-add -D), use timeouts (-t), and always lock your computer.

You’re now both secure and productive with SSH! 🚀

Setup 🛠 Rails 8 App – Part 3: Git setup, modify gitignore, git config

So now let’s push the code to github repository. Before that there is some final checks need to be done from our end.

Check .gitignore file and update

✅ Files/Folders to Include in .gitignore

Here’s a breakdown of which files/folders should be added to .gitignore in your Rails project:

These files are user-specific or environment-specific and should not be committed to Git.

1️⃣ .dockerignore → ❌ Ignore from .gitignore

  • Keep this file if you’re using Docker.
  • It’s like .gitignore but for Docker, helping to reduce Docker image size.
  • Do not add it to .gitignore if you need it.

2️⃣ .github/ → ✅ Add to .gitignore (If personal CI/CD configs)

  • If this contains GitHub Actions or issue templates, keep it in the repo.
  • If it’s just for personal workflows, add it to .gitignore.

3️⃣ .kamal/ → ✅ Add to .gitignore

  • This contains deployment secrets and configuration files for Kamal (deployment tool).
  • It’s usually auto-generated and should not be committed.

4️⃣ .vscode/ → ✅ Add to .gitignore

  • User-specific VSCode settings, should not be committed.
  • Different developers use different editors.

Keep These Files in Git (Don’t Add to .gitignore)

These files are important for project configuration.

1️⃣ .gitattributes → ❌ Keep in Git

  • Defines how Git handles line endings and binary files.
  • Helps avoid conflicts on Windows/Linux/Mac.

2️⃣ .gitignore → ❌ Keep in Git

  • Defines ignored files, obviously should not be ignored itself.

3️⃣ .rubocop.yml → ❌ Keep in Git

  • This is for Rubocop linting rules, which helps maintain coding style.
  • All developers should follow the same rules.

4️⃣ .ruby-version → ❌ Keep in Git

  • Defines the Ruby version for the project.
  • Ensures all team members use the same Ruby version.

Final .gitignore Entries Based on Your Files

# Ignore log files, temp files, and dependencies
/log/
/tmp/
.bundle/
/node_modules/

# Manually added
# Ignore editor & environment-specific configs
.vscode/

# Ignore deployment configs
.kamal/

# Ignore personal GitHub configs (if applicable)
.github/

Final Summary

FolderInclude in Git?Why?
log/❌ IgnoreDynamically generated logs
public/✅ Keep (except public/assets/)Static files like favicon, error pages
script/✅ KeepOld Rails script files (if used)
storage/❌ IgnoreActiveStorage uploads (except seed/)
test/✅ KeepContains important test cases
tmp/❌ IgnoreTemporary runtime files
vendor/❌ Ignore (except custom libraries)Third-party libraries

First time git setup

# You can view all of your settings and where they are coming from using

git config --list --show-origin

# Your Identity: The first thing you should do is to set your user name and email address.

git config --global user.name "Abhilash"
git config --global user.email abhilash@example.com

# configure the default text editor that will be used when Git needs you to type in a message

git config --global core.editor emacs
git config --global core.editor "code --wait"     # vs code
git config --global -e      # verify editor

# command to list all the settings Git can find at that point

git config --list
git config user.name

Add your ssh key to your github. Check the post: https://railsdrop.com/2025/03/30/setting-up-ssh-in-your-system/

Initial commit: Execute the Git commands

Run the following commands in your rails app folder:

git add .
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:abhilashak/design_studio.git
git remote -v     # check the remote endpoints
git push -u origin main

git log      # check commit details

What It Does:

git branch -M main
  1. Renames the current branch to main.
  2. The -M flag forcefully renames the branch (overwrites if needed).

Common Use Case:

  • If your branch is named master and you want to rename it to main (which is now the default in many repositories).
  • If you created a branch with a different name and want to standardise it as main.

Example Usage:

git branch -M main
git push -u origin main

This renames the current branch to main and then pushes it to the remote repository.

Use github ssh option: it checks the ssh key that you setup in your github account for that machine.
http option asks your github credentials to login.

The -u option in the command:

git push -u origin main

What Does -u Do?

The -u flag stands for --set-upstream. It sets the upstream branch for main, which means:

  • It links your local branch (main) to the remote branch (main on origin).
  • After running this command once, you can simply use:
  git push

instead of git push origin main, because Git now knows where to push.

Example Use Case:

If you just created a new branch (main in this case) and are pushing it for the first time:

git push -u origin main

This ensures that main always pushes to origin/main without needing to specify it every time.

After Running This Command:

✅ Next time, you can simply use:

git push
git pull

without needing to specify origin main again.

For better git work flow

Check the post: https://railsdrop.com/2025/03/29/git-workflow-best-practices-for-your-development-process/

Want to See Your Upstream Branch?

Run:

git branch -vv

This shows which remote branch your local branches are tracking.

to be continued.. 🚀