Git, GitHub, and the Bittensor Time Machine: Why Version Control Matters

Git’s history is the only thing that remembers what I did before my toddler unplugged my VM

Photo by Roger Ce on Unsplash

After finishing a Machine Learning course and an absolute fail in installing the Bittensor SDK on my desktop this week, I wanted to write today about how Git & GitHub can help me with my folder structure for future projects and how this applies to Bittensor.

Right now my GitHub repository doesn't have much more in it than a few "Hello World"`, "Spot the Beginner" and I_don't_know_what_I'm_doing.py files along with a confusing README, but it doesn't distract me from the knowledge that this is going to be used a lot in future if I am to progress.

So, for the uninitiated, what's the difference between Git and GitHub?

To anyone who does not have a tech background, GitHub is something you are vaguely aware of but run a mile from when you accidentally click into a random repo. Its not all that complicated though and something that just makes sense when you see it.

Git

Git is an open source software for tracking changes in a distributed version control system. It lets you track and manage your projects while you're developing them and is distributed because you can access your code files from anywhere along with anyone else.

Controlling each version of your project is also much easier using the repositories in working directory, index and git directories.

GitHub

GitHub is an actual platform that allows Git users to host their code, share repositories and collaborate on open source projects.

It also allows you to create isolated branches for different features or fixes, allowing multiple people to work on the same project without conflicts.

Being a long time Excel fan, I've countless versions of spreadsheets saved down with no idea what the changes are or relate to, only knowing that V56 is the one to continue with as its the latest version.

And that's even without working in parallel with anyone on the same files! So this makes a lot of sense to me.

Also, GitHub has a very helpful Copilot that does not mind being bombarded with simple bug fixes and ELI5 questions in my VS Code, the embarrassment is a lot less when you don't have to ask these questions of a real person.

Git for Bittensor Model Iterations

Version control being so important for any development work, I can see how you would use Git branches to track Bittensor miner model versions, like in Issue 3 committing improved tensor encoding for validator consensus.

Imagine a list of commits in the below, from oldest at the top to newest at the bottom (credit https://github.com/crc8/GitVersionTree for the great visualization tool)

This is so much easier to organize and avoids the mess of a set of folders let loose and garbage version control. Any tensor shape mismatch could easily be rolled back to an earlier version or a different branch in your workflow.

Branches as Miners' Independent Work

So just like I would create a new Git branch for every Bittensor experiment (and inevitably break most of them), miners could spin up their own models without disrupting the network and messing up their validator scores.

The tensors represent the miners branch of intelligence and these outputs are isolated until validators decide to merge them into the network's consensus.

When I merge a branch into main in my GitHub, I'm resolving conflicts and integrating changes that align with the projects goals, this aligns with Bittensor validators evaluating miners' tensors and accepting only the highest quality contributions.

Getting validator feedback via weighting is nowhere near my grade yet though, my coding conflicts are currently at the level of my youngest toddler screaming at me to open my office door, come out to play and chase him around the house again pretending to be a bee.

Git History as Bittensor’s Blockchain Ledger

In Git, every commit, merge, and branch is tracked in history and you can roll back if something breaks. Similarly, the Bittensor blockchain records every miner’s contribution as permanent data. If a model’s performance tanks, the network rolls back its influence via consensus.

Both systems are like their own versions of merging a branch. In Bittensor's case you may possibly even get some TAO in return. Those sweet incentives are great to see.

Questions

Is there anything big I am missing on Git and GitHub setup for building on Bittensor? A robust GitHub repository template is on my to-do list in the near future, with a basic version to iterate as I improve.

Also my travails in setting up the Bittensor SDK are worthy of a future post, but I need to succeed at it first!

If you have any tips on how to do this, please do reach out and in any case subscribe for future updates. I'm all ears and thanks for reading.

Until next week.

Cheers,

Brian