Git Basics for Junior Developers: Branches, Commits and Pull Requests

Git is the version control system used by most development teams. It records every change to code, lets several developers work in parallel and makes it possible to undo mistakes. For junior developers, Git can feel confusing at first, with its branches, merges and occasional scary error messages.

This guide covers the everyday Git skills that matter most on real projects, especially in small Malaysian agencies and SME tech teams where good habits make collaboration much smoother.

Commits: Small, Focused and Well Described

A commit is a saved snapshot of changes with a message describing them. Good commits are small and focused on one logical change, such as "Fix checkout total rounding" or "Add delivery date field to order form". This makes history easy to read and problems easier to trace.

• Commit often, in small steps
• Write messages that explain what changed and why
• Avoid vague messages like "update" or "fix stuff"
• Review your changes before committing with git diff or your editor

Never commit secrets such as API keys, passwords or environment files. Use a .gitignore file to exclude them. Once a secret is pushed to a shared repository, treat it as exposed and rotate it.

A useful pattern for commit messages is a short summary line under about 50 to 70 characters, followed by a blank line and more detail if needed. Teams often agree on a convention, so check your project's existing history and follow its style.

Branches: Work Without Breaking Main

Branches let you work on a feature or fix without affecting the main codebase. A common workflow is to create a branch for each task, commit changes there, then merge it back into the main branch once reviewed.

Name branches clearly, such as feature/booking-calendar or fix/invoice-pdf-layout. Keep branches short-lived; long-running branches drift away from main and become painful to merge. Pull the latest main branch into your work regularly to stay up to date.

Tip: before starting new work, always update your local main branch. Many merge headaches come from starting on outdated code.

Some teams use more structured workflows with separate development, staging and production branches. Others deploy straight from main with feature flags. Learn your team's model before creating branches, and ask if anything is unclear.

Pull Requests: Collaboration and Review

A pull request, or merge request on some platforms, asks the team to review and merge your branch. It is where discussion, feedback and automated checks happen.

1. Keep pull requests small enough to review in one sitting.
2. Write a clear description: what changed, why, and how to test it.
3. Include screenshots for visual changes.
4. Respond to feedback politely and update the branch.
5. Ensure automated tests and checks pass before requesting final approval.

Code review is a learning opportunity, not a judgement. See code review habits for small dev teams for how to give and receive feedback well.

Recovering From Common Mistakes

Mistakes happen to everyone. Common situations and safe approaches:

• Committed to the wrong branch: create a branch from the current state, then reset the original branch carefully, or ask a teammate to help.
• Need to undo a pushed commit: use git revert, which creates a new commit undoing the change without rewriting shared history.
• Merge conflicts: read both versions, decide what the code should be, test and commit the resolution.
• Lost work: git reflog often helps find commits that seem to have disappeared.

Avoid force-pushing to shared branches unless your team agrees. Rewriting shared history can erase other people's work.

When in doubt, stop and ask before running a command you do not fully understand. Making a backup branch first, with a simple git branch backup-name, gives you a safe point to return to.

Connect Git to the Bigger Workflow

Git is the foundation for continuous integration and deployment, where every push runs tests and approved merges deploy automatically. Learning Git well prepares you for these practices; see CI/CD for SME sites.

For small businesses, make sure the company owns the repository account, not just an individual freelancer. Store repositories on a platform the business controls, with access removed when people leave. Good Git habits and clear ownership make it much easier to change developers in the future without losing the project's history.

FAQ

Should I use the command line or a GUI?

Either works. Learning basic commands helps you understand what GUIs do and troubleshoot problems.

How often should I commit?

Whenever you complete a small logical step. Several commits a day is normal.

What is the difference between merge and rebase?

Merge combines branches with a merge commit; rebase replays commits on top of another branch. Follow your team's convention.

Good Git habits make teamwork smoother and mistakes recoverable. Write small, clear commits, use short-lived branches, open focused pull requests, learn safe recovery commands and make sure the business owns its repositories.