kiran

Posted on Nov 2

GitHub Was Created for Developers, Not Just for Pushing "Fix Issue" Commits

#git #github #developers #softwaredevelopment

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