Share code with git bundles instead of zip files

I’m sure many of you have sent code to someone else as a zip file (or any other compressed archive file type). Usually this happens when you want to share code with someone outside of your organization, and you want them to have a copy of the code instead of direct access to the repository and all its history. Sometimes it’s done to share code with someone who cannot connect to your servers for any number of reasons. Maybe you release code to people in an archive. Maybe a vendor releases code to you via an archive.

This approach of sharing code in a zip file is often “good enough” for many use cases. But any time it’s not meant as a one-off delivery, it can be problematic, especially if you’re making your own changes to the file or trying to send modifications back to the originator. Managing source code this way quickly becomes a nightmare.

An alternative that we can use for sharing our code is to generate a git bundle. Essentially, a bundle is an archive file that a user can use with the git clone command to create a local repository. The bundle contains your source code, as well as the change history for the commits and branches that you reference during the bundle creation step.

Even though I have been using git for most of my career, I only heard about git bundles thanks to Klemens Morgenstern and his Heapless C++ course. As with all of our courses, the exercise code is kept under source control. One of the course design problems was having a way to share the source code and the solutions with users without sharing the solutions in an obvious way. Klemens’s idea was to generate a git bundle that contained the source code for the exercises on the primary branch. Each solution would have its own branch. This meant that solutions were locally available to users, but they had to take an explicit step to see them: changing to the target branch.

We’ve come to see how this is useful for code distribution in general:

  • We can easily share private code with students without making repositories public for the world to access
  • It’s easier to incorporate updates to a bundle you’re working in, since you can control how/what gets merged without destroying your own work
  • Students can send us bundles when we need to investigate problems
  • Students can send us bundles with corrections/improvements that we can easily merge upstream

Want to learn more about working with git bundles? Check out our workflow notes.

References

Share Your Thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.