Writing→Gear→Travel→Contact Me→
← back to writing
software-engineering · github · git · source-control · ci-cd

Getting Started with Software Engineering. CH.1: Source Control with Git

Abed A.·30 August 2026

Lately, I have noticed an increasing pattern from graduates fresh out of university. I mean you've completed countless assignments, sat exams, and covered the fundamentals of computer science.

And yet this feels like you do not understand what it feels like to be a developer as part of a software team.

This is where I think a lot of you, and people trying to break into tech/dev, struggle.

You know how to write code, but you may not have had to think about maintaining it, or what happens when somebody else has to have a look at your code six months later.

Now this isn't me selling you a 0–100 guide to Software Engineering. My goal is more to try give my own take on some of the things that helped me get into the industry, and grow.

My route into Software Engineering

My route into Software Engineering wasn't particularly conventional.

I started out by graduating in Aerospace Engineering, looking at CFD for aerofoils and understanding the thermodynamics of 3D turbomachinery. I then moved into Systems Engineering, which gave me my first real reality check when it came to product development.

I had to learn about requirements, customers, and the difference between Verification and Validation.

From there, I started looking more closely at data and how it could be utilised. This was my first real exposure to APIs, data stores, to cloud web development.

And then the questions started raining:

  • How should this data platform be designed?
  • Should reads and writes be separated?
  • What are the implications of different architectural decisions?
  • How do you secure the system?
  • What does clean code actually mean when other devs need to maintain it?
  • How do you test it, deploy it and eventually support it?

The further I went, the more I realised that Software Engineering is about everything, far from just writing code. As part of this series, in this blogpost I will briefly dive into source control.

Treat your projects like production level software

The easiest way to start is to take a project you've already built and start treating it like a real software product.

You don't need a complicated architecture to start doing this.

  • Put it under source control.
  • Learn how to work with branches.
  • Write meaningful commits.
  • Create Pull Requests.
  • Review your changes.

Start with a repository and a git management tool. My suggestion is GitHub's own Desktop UI App.

Why GitHub Desktop?

If you're new to Git, the command line can be a tad confusing.

You start reading through the docs and already come across so many commands:

git clone
git add
git commit
git push
git pull
git merge

Sure, they are are absolutely worth learning, but I don't think they need to be your introduction to source control.

This is where I think GitHub Desktop is a fantastic starter.

It provides a visual interface for many of the core Git commands, including creating repositories, working with branches, reviewing changes, committing, pushing and previewing Pull Requests. It lets you see what is happening. What files you've changed, the branch you're working on, the commits you've made and the changes you're preparing to push.

For somebody learning source control, I think that is extremely useful. GitHub Desktop isn't CI/CD. Think of it as a tool used within the developer's workflow in this:

Write code
    ↓
Create branch
    ↓
Commit changes
    ↓
Push
    ↓
Pull Request
    ↓
Review
    ↓
Merge
    ↓
CI/CD
    ↓
Build / Test / Deploy

Once your code reaches GitHub, automation such as GitHub Actions or DevOps Pipelines can take over the CI/CD side of the process.

How to set up your repository

If you're starting from scratch, I'd recommend following GitHub's own Getting Started with GitHub Desktop guide rather than me reproducing the entire walkthrough here. It covers installation, authentication, creating repositories, branches, commits, pushing and Pull Requests.

If you want to create your first repository yourself, GitHub also has a dedicated Creating your first repository using GitHub Desktop guide.

A few things I'd recommend from the start:

1. Keep your repository private initially.

You can make it public later once you're happy with the project.

2. Add a README.

This is where you explain what the project does, how to run it, what technologies it uses and anything else another developer would need to know.

3. Use a .gitignore.

Don't commit build artefacts, local configuration files, virtual environments or secrets. The gitignore documentation is worth understanding early. Also checkout this collection of useful .gitignore

4. Don't work directly on main.

Create a branch for your work. For example:

feature
   ↓
develop
   ↓
main

This isn't the only branching strategy. Some teams use feature branches directly into main, while others use trunk-based development or different variations of Git Flow.

The important thing is understanding why you're using branches in the first place.

GitHub's documentation on managing branches is a good place to start.

Keep your commits meaningful

Your commit history should tell a story.

Try to avoid:

update
fix
changes
final
final2

Instead, aim for something descriptive:

Added authentication middleware
Updated null response from user endpoint added custom error handling with try catch block
TODO: create data contracts for username input field validation + unit/contract tests

Keep the summary clean and use the description when additional information is useful to you (& others).

I also tend to favour squash-and-merge for Pull Requests so that main contains the major changes rather than every small development commit.

Again, that's my preference rather than a stated framework.

Learn Pull Requests early

Pull Requests are a big part when working in a dev work setting.

Instead of simply making changes and pushing them directly into main, you commit your changes in a feature branch, review the differences, receive feedback and then merge them onto a master branch.

You can then use the github repository pull request link to go through the wider review functionality.

I'd recommend getting into the habit of reviewing your own Pull Requests.

A few sanity check questions for yourself:

  • Does this change do what I want?
  • Is there unnecessary code?
  • Are there any tests?
  • Have I introduced anything that could break existing functionality?
  • Would another developer understand few months from now?

That last question is particularly important.

Next Steps

Once you're comfortable with the basic workflow, I'd recommend reading some of the underlying Git concepts below:

  1. GitHub's Git documentation
  2. Git branching
  3. GitHub Pull Requests
  4. GitHub Actions
  5. GitHub repository rules and branch protection

You don't need to learn all of this in one sitting. Take an existing university project, put it into GitHub, create a branch, make a change, commit it, open a Pull Request and review it.

That's how I'd start bridging the gap between "I know how to write code" and "I understand how software is actually developed."

← all posts