Version-Control Your EV Project with Git

Why this happens

EV projects mix firmware, scripts, spreadsheets, CAD and reports, and changes by several team members easily overwrite each other. Git records every change with a message and author, lets you return to any earlier working state and lets a team work in parallel on branches without losing work.

What you need

Step by step

1. 1

   Install Git and set your identity

   Install Git and set your name and email in the global configuration so every commit is labelled correctly. Use the email you are happy for recruiters to see if the repository will be public. Choose a default branch name, commonly main, and confirm the setup by checking the version from the command line or your editor.

2. 2

   Organise the folder before the first commit

   Arrange the project into clear folders such as firmware, simulation, data, cad, docs and report. Move personal or unrelated files out. A tidy structure from day one makes history easier to follow and helps a reviewer understand the project in a minute. Add a README with the project goal, folder guide and how to run the code.

3. 3

   Write a .gitignore

   Create a .gitignore file listing things that should not be tracked: build outputs, compiled binaries, virtual environments, editor settings, temporary files and large raw logs. Also list any file holding passwords, API keys or Wi-Fi credentials. Keeping these out from the start is much easier than removing them from history later.

   Tip: Store secrets in a separate local config file that is listed in .gitignore.

4. 4

   Initialise and make the first commit

   Initialise the repository, check the status to see what will be included, stage the files and commit with a clear message such as 'Initial project structure and README'. Review the list of staged files before committing to confirm nothing sensitive or huge slipped in. This first commit is the safe baseline you can always return to.

5. 5

   Commit small and often

   Commit each logical change separately: 'Add road-load function', 'Fix unit error in drag term', 'Update wiring diagram for fuse box'. Small commits with specific messages make it easy to find when a bug was introduced and to undo one change without losing others. Commit at least at the end of every work session.

6. 6

   Use branches for experiments

   Before trying something risky, such as a new control algorithm or restructured report chapter, create a branch. Work and commit there; if it works, merge it into main, and if not, simply switch back. Team members should each work on their own branch and merge through reviews, which avoids overwriting each other's files.

7. 7

   Handle large and binary files sensibly

   CAD models, videos and large datasets bloat a repository and cannot be compared line by line. Keep big raw data outside the repository with a note on where it lives, or use a large-file extension if your hosting supports it. Export key results such as plots and summary tables in small formats that can be tracked.

8. 8

   Back up to a remote and tag milestones

   Push the repository to a remote host your college allows, or at least to an external drive, so a laptop failure does not wipe the project. Tag milestones such as 'review-1' and 'final-submission'. Before making a repository public, check with your guide and any industry partner that no confidential data or code is included.

How to tell it worked

Your project has a readable commit history, a README and .gitignore, branches for experiments, tagged milestones and an off-laptop backup, and you can restore any earlier version in under a minute.

Questions