Git — Version Control for Engineers

Git is the industry-standard distributed version control system for tracking changes in source code. Engineers use it to collaborate without overwriting each other's work, to maintain a full history of every change, and to manage parallel streams of development using branches. It is a required tool in virtually every software and firmware engineering role.

Why companies use it

·Enables parallel development across large teams without merge conflicts destroying each other's work
·Provides a complete audit trail of who changed what and why — critical for regulated software (IEC 62304, DO-178C)
·Git branching strategies (GitFlow, trunk-based development) structure the release process and reduce integration risk
·Platforms built on Git (GitHub, GitLab, Bitbucket) add code review, CI/CD, and issue tracking to the core version control

What hiring managers look for

·Git proficiency is a baseline expectation for all software and firmware engineers — gaps are a red flag
·Understanding branching strategies (feature branches, release branches, hotfix) shows that a candidate can work in a structured team
·Comfort with rebase, cherry-pick, and conflict resolution shows depth beyond basic commit/push usage
·Engineers who write clear, atomic commit messages with meaningful descriptions make the team's codebase easier to maintain

Typical interview questions

What is the difference between git merge and git rebase? When would you use each?

Describe the GitFlow branching strategy. What branches are always present?

You have accidentally committed sensitive credentials to a public repository. What do you do immediately?

What is a git stash and when would you use it?

How do you resolve a merge conflict in Git?

Common mistakes

·Committing directly to main/master in a team — always use feature branches and pull requests
·Writing vague commit messages like "fix bug" or "update" — commit messages are the primary documentation of why changes were made
·Force-pushing to shared branches — this rewrites history that other team members have pulled, causing difficult-to-resolve divergence
·Creating long-lived feature branches that diverge far from main — merge conflicts compound over time; prefer short-lived branches
·Not using .gitignore — committing build artefacts, IDE files, and secrets to the repository

Real engineering example

An embedded firmware team was losing an average of 3 hours per week to merge conflicts because all developers committed to a single development branch. By adopting a trunk-based development model with feature branches limited to 2-day lifetimes and automated pre-merge tests, merge conflicts dropped by 80% and the team recovered 2.5 hours per developer per week — equivalent to one additional feature per sprint.

Topics covered

Gitversion controlbranchingGitFlowmergerebasesoftware engineering

Related interview guides

Software Engineer →Embedded Software Engineer →Firmware Engineer →Devops Engineer →Machine Learning Engineer →

More in Software Engineering

CI/CD — Continuous Integration and Delivery5 min TDD — Test-Driven Development4 min Code Review — Engineering Quality Gate4 min Software Architecture — Design for Scale6 min DevOps — Development and Operations Integration5 min

Preparing for an interview?

Browse our role-specific interview guides written by engineers who know what hiring managers at ASML, NXP, and Philips look for.

Browse Interview Guides →