Let's be honest. Almost every developer has done this at least once:

git add . git commit -m "fix issue" git push

And then we close the terminal like we've completed something extraordinary. 😂

But wait...

What issue did we fix?

Nobody knows. Not even the developer who wrote the code.

Sometimes our commit history looks like this:

fix issue bug fix changes update final changes final changes 2 final changes latest now working

If someone opens this repository after six months, they might need a detective instead of a developer to understand what happened.

But Git and GitHub were not created just to help us push code with mysterious commit messages.

Let's understand why they exist, why developers use them, and how we should actually use them.

1. Why Was Git Created?

Before Git, developers faced a common problem: managing changes in source code, especially when multiple developers were working on the same project.

Imagine three developers working on the same application:

  • Developer A is working on the login module.
  • Developer B is working on the dashboard.
  • Developer C is fixing a payment bug.

Now imagine all three are modifying the same project files.

Questions start coming up:

  • Who changed this line?
  • Why did this code stop working?
  • How can we restore the previous version?
  • What happens if two developers modify the same file?

This is where version control becomes important.

Git was created by Linus Torvalds in 2005, initially to help manage the Linux kernel's source code development.

Git is a distributed version control system that helps developers:

  • Track code changes.
  • Maintain project history.
  • Work on different branches.
  • Collaborate with other developers.
  • Restore previous versions when needed.

In simple words:

Git remembers what changed, who changed it, and when it changed.

2. Then Why Do We Need GitHub?

Okay, we have Git. So why GitHub?

Think of it this way:

  • Git is the tool that tracks your code changes.
  • GitHub is an online platform where you can host Git repositories and collaborate with other developers.

Git works locally on your computer. GitHub makes it easier to share repositories, review code, manage issues, discuss changes, and collaborate with teams.

GitHub provides features such as:

  • Pull Requests
  • Issues
  • Code Reviews
  • GitHub Actions
  • Project Management
  • Repository Management

For example, when you work in a company, you might create a feature branch, push your code to GitHub, and open a Pull Request.

Your teammates can review your changes before they are merged into the main branch.

That's collaboration!

3. The Developer's Favourite Git Workflow 😂

Let's talk about our daily routine.

You start working on a feature.

You write some code, change a few files, fix some bugs, and suddenly it's time to push.

Your terminal:

git add . git commit -m "changes" git push

Mission accomplished! 🚀

But there is a small problem.

What exactly did you change?

Imagine your teammate checking the commit history:

changes fix issue update code bug resolved

They ask you:

"What did you fix in this commit?"

And your answer:

"I don't remember. Just check the code." 😂

We've all seen this situation.

The problem isn't Git. The problem is how we use it.

4. How Should We Actually Use Git?

Let's improve our workflow with a few simple habits.

Step 1: Check What You Have Changed

Before staging everything, check your changes:

git status

This tells you which files are modified, untracked, or staged.

You can also inspect the actual changes:

git diff

This helps you understand what you're about to commit.

Step 2: Don't Always Use git add .

Yes, git add . is convenient, but it stages all eligible changes in the current directory and its subdirectories.

Sometimes you don't want to commit every modified file.

Instead, stage specific files:

git add src/login/login.component.ts git add src/login/login.component.html

Or stage everything intentionally after reviewing your changes:

git add .

Step 3: Write Meaningful Commit Messages

Instead of:

git commit -m "fix issue"

Write something meaningful:

git commit -m "fix login validation error"

Or:

git commit -m "add pagination to customer listing"

Or:

git commit -m "update client profile form validation"

A good commit message should explain what changed.

Your commit message is a small piece of documentation for your future self and your teammates.

Step 4: Use Branches for Different Tasks

Don't do all your development directly on the main branch.

Create a separate branch for each feature or bug fix:

git checkout -b feature/user-profile

For a bug fix:

git checkout -b fix/login-validation

This keeps different tasks isolated and makes code reviews easier.

Step 5: Push Your Changes

Once your changes are reviewed and committed:

git push origin feature/user-profile

Then create a Pull Request on GitHub.

Your teammates can review the code, suggest improvements, and approve the changes before merging.

5. A Simple Git Workflow Every Developer Should Follow

Here is a practical workflow you can use in your daily development:

# 1. Check current branch git branch # 2. Create a new feature branch git checkout -b feature/add-user-management # 3. Check modified files git status # 4. Review code changes git diff # 5. Stage required files git add . # 6. Commit with a meaningful message git commit -m "add user management module" # 7. Push your branch git push origin feature/add-user-management

After that, open a Pull Request on GitHub.

Simple, right?

6. A Few Git Habits That Can Save Your Life

Here are some habits worth developing:

  • Always check git status before committing.
  • Write meaningful commit messages.
  • Create separate branches for features and bug fixes.
  • Review your changes before staging.
  • Pull the latest changes before starting work.
  • Never commit passwords, API keys, or environment secrets.
  • Don't blindly force-push to shared branches.
  • Use Pull Requests for code reviews.

These small habits can save hours of debugging and confusion.

Final Thoughts

Git and GitHub are not just tools for uploading code.

They help us maintain project history, collaborate with teammates, understand changes, and build software in a more organized way.

We all start somewhere. Even experienced developers sometimes write a commit message like fix issue.

But the goal should be to make our code and our commit history understandable.

Because six months from now, you might be the person asking:

"Who wrote this code, and what was I thinking?"

And the answer might be sitting right there in your Git commit history.

Happy Coding! 🚀

And please, next time, instead of writing fix issue, tell Git what you actually fixed. 😂