Version Control

In episode 3 of the Small Tech Podcast, we dive into the world of version control systems, discussing how they make collaborating with other developers a breeze. We take a look at popular platforms like GitHub, Bitbucket, and GitLab, breaking down their main features and what makes each one unique. So, if you're trying to figure out which platform to use for your project, give this episode a listen – we've got you covered!

🗣️ Got feedback? Want to be a part of this? Contact us!
[e-mail]

🚀 Subscribe to the podcast:
https://smalltechpodcast.com/

✉️ Subscribe to the newsletter:
https://s.goec.io/stp-newsletter

🎥 Watch on YouTube:
https://s.goec.io/stp-youtube

📄 Read the EC blog:
https://s.goec.io/ec-blog

🛠️ Need help building something?
https://s.goec.io/build-together

Creators & Guests

Host

Raphaël Titsworth-Morin

Trying to do good in the world with tech and design. I also take the occasional photograph. Co-founder of Éphémère Creative. He/him.

What is The Sustainable Tech Podcast?

The Sustainable Tech Podcast explores the intersection of technology, sustainability, and impact. Hear stories from tech startups, software companies, non-profits, and small businesses using technology to drive environmental and social change. Each episode features entrepreneurs, nonprofit leaders, and tech experts who share practical advice, success stories, and insights on building a sustainable future. Perfect for founders, tech enthusiasts, and sustainability advocates looking to stay ahead in the world of tech and impact-driven innovation. Subscribe now for inspiring conversations on the future of sustainable technology!

🗣️ Got feedback? Want to be a part of this? Contact us!
[e-mail]

🚀 Subscribe to the podcast:
https://sustainabletechpodcast.com/

Hey folks, and welcome to the Small
Tech Podcast from Éphémère Creative.

I'm your host Raph and today we are going
to be talking about version control.

So the first episode was very scripted.

The second episode was
a little bit scripted.

I had some notes and stuff, but this
episode, I just haven't had the time

to put a lot of thought into it.

Um, but I figured this is something
that, uh, this is something that I

know this is something that I deal with
on a regular basis and have explored

various options over the years.

So maybe this is a good candidate
for something to sort of wing it on.

Um, and I would love to hear what you
all have to say about this subject.

Um, so version control.

I remember the first time I dealt with
any kind of version control was back in.

2011, I think was a project
that was using subversion.

This was, my first time really
working on any kind of web project.

And I wasn't allowed anywhere
near the repo, but there was a...

I was allowed to access some code
at some point and not contribute,

but I could poke around at it.

So.

Since then.

A lot of things have changed.

And there used to be Mercurial.

What was the other one?

Like Tortoise SVN, some other
stuff like that in the meantime,

git took over the world.

And for people who are more new
to, technology and development,

you might have heard of GitHub.

But a lot of people make the mistake
when they first get into this field

of a conflating GitHub with git,
git is the actual system you can

think of it kind of like a protocol.

It's the tool that we use to, to
manage version control, uh, for code.

Yeah.

So you might've heard of GitHub.

That is a system that uses get,
but there are plenty of others.

And in the context of building
tech in a small company.

Or a small organization.

There are a lot of different options
actually, and GitHub might not be the

one that makes the most sense for you.

Let's back up a second, And talk
a little bit about what git is and

why you might use it and why you
use version control more generally.

So version control systems,
like subversion, git,

mercurial and these other ones.

Allow you to commit changes to your
code, and so as you're working, you'll

say, yep, this is ready to go and so
I'm going to commit the changes to

all of these files and say, this is a.

Uh, step in this, uh, in this
project, in the right direction.

And you can do, what's called branching.

So you'll create a branch
to work on a feature.

And if stuff doesn't work out,
you can revert back to the other

branch that you sourced it from.

And so you can just ignore all of the
work that you did and sort of rewind

back to the point that you branch
from and you can merge branches.

And so these systems.

Allow you through this sort of merging
and, uh, splitting and committing.

The allow you to work collaboratively
with people because the software can

track who made, what changes when
and help you merge them all together.

So you might all be working on
the same file and running this

software on separate machines.

And when you say, yep,
this is ready to go you...

with...

in GitHubs parlance, you will submit
a PR a pull request in GitLab.

They call it a Merge Request.

But one way or another, what, what that
saying is, Hey, can someone look at my

code and look at the differences between
the sort of production branch, if you

want to call it that though there's...

you can go into how, how you
want to deal with branches and

what's production or whatever.

But you're basically asking someone,
"Hey, can you check if this is ready?"

I want to merge it back.

And the system.

Often not always.

We'll be able to take
care of that for you.

And so you can say, yep.

I've looked at all of the differences
and I think this is good to go.

Let's merge it back.

And it will figure out, based off of
the timing of the different commits, if

anyone else has made any commits, in the
meantime how they should come together.

In some cases that's not possible.

And then we get merged conflicts and that,
uh, is something that someone somewhere

on the team is going to have to deal with.

There's different ways of dealing with
it, from an operational perspective,

from a technological perspective.

But yeah, that's, that's there.

The crux of it.

So essentially.

Version control systems allow you to
work collaboratively and independently.

And bring your work back together
into one cohesive product.

And platforms like GitHub
have made it really easy to do

that in the open source world.

And so you'll know, GitHub primarily
because most open source projects.

Host their stuff on GitHub.

Their code is there.

Uh, for the world to see.

But there's also private repositories on.

And so organizations, uh, companies, uh,
individuals will host their code on GitHub

as well, uh, in private repositories
that they don't want the world to see.

Now, this is something that actually
only was made possible in the

last few years on a free tier.

It used to be that if you
wanted to use GitHub for private

projects, you had to pay.

And so that's actually why I
initially started using other tools.

For example, two of the other big ones
are Bitbucket, which is by Atlassian.

And GitLab

.
For those who don't know also
GitHub is owned by Microsoft.

They acquired them for many
billions of dollars a few years ago.

So why might you choose
one over the other?

I initially started using Bitbucket
because it had free private repos.

I think this was.

At a time where GitLab
wasn't really well known.

I think I started using them
in 2014 or something like that.

GitLab may not even have existed.

I don't know what the timeline is there.

But Bitbucket was
available and it was free.

Uh, for private repositories.

So you could use it for your company and
on top of it, all it integrated really

well with Atlassian's other projects.

You might remember our
little discussion last week.

About Atlassia n JIRA.

Product, which is their
project management tool.

So Bitbucket integrates nicely with JIRA.

So I was using Bitbucket at the time.

Also used JIRA.

Uh, since then, I had a friend,
point out to me that there's this

fantastic new platform called GitLab.

And he explained that he liked it
a lot because it was open source.

Uh, so you can run it yourself
on your own servers using just

their open source version.

Or you can use their hosted version.

Uh, GitLab.com.

And one of the things that was neat
about GitLab is that it integrated.

Continuous delivery tools,
CI/CD can do continuous

integration, continuous delivery.

That's a weird mashup of
terms that essentially mean.

Tools to run tests and
builds and deployments of

your code onto your servers.

And at the time.

Bitbucket and GitHub did
not offer anything like that

built into their platform.

I previously was using a tool called
Circle CI to do that sort of stuff.

Now all of them offer this out of the box.

They all now also offer a free
private repos, which was another

selling point for GitLab.

They had free private repos and, uh, the,

The CIC D tooling built in.

And so it was a great way to run a
repo for a private, private project.

Um, They also offered a lot of other
stuff like hosting of a Docker registry.

You could push different types
of packages and host them there.

And they also offered a bunch of
other tooling to do monitoring

and all kinds of other stuff.

So that was really, really useful to me.

Since then I've started doing a
lot more, open source stuff with

our project called the Chewy Stack.

And I am drifting back towards GitHub.

And my reason for that is that for
open source, it's really great to be

on GitHub because that's where all of
the other open source projects are.

So you just gain visibility, by
being there there's more potential

for connections to other projects.

People are there already
and they trust the platform.

So we're going to put a little sponsorship
button on the project and see if

anyone's interested in sponsoring.

And that whole ecosystem is really.

Really nice to be a part of,
for an open source project.

My instinct is that with that
will come some other tie-ins that

make it valuable to stick around.

So a company might find it valuable
to use, GitHub for their open source

projects, but because they're already
there then they might want to keep their

enterprise projects in there as well
because everyone knows the workflow.

Yeah, I think that's, that's
mostly it there, there are other,

there are other tools out there.

Other platforms, I think
one of them is called Gitea.

Uh, git tea I'm just going to
take that out and see, I think

this is another open source one.

Gitea to you as a forge software
package for hosting software development

version control using get as well
as other collaborative features

like bug tracking, code review,
Kanban boards, tickets and wikis.

Um, yeah, so that's kind of cool.

It's another one.

I'm sure there's others too.

My instinct generally is if you
work with JIRA or other Atlassian

tools, go with BitBucket.

If you want to run your own.

Uh, server or if you value the open
source and community driven development

of a platform then go with, GitLab.

If you're in open source or you're
more new to this stuff, then GitHub

is probably a nice place to go.

For open source, obviously, as
we discussed everyone's there

anyway, so might as well be there.

But I think it's also a
very friendly platform.

It's pretty easy to get started with.

GitLab can be a bit overwhelming.

Bit bucket is easy, but is tightly
integrated with a lot of Atlassian

stuff and perhaps less flexible.

So yeah.

GitHub is probably your best bet
if you're just getting started.

And that is pretty much it.

I would love to hear why you choose
the version control software that

you do and more specifically,
cause it's almost certainly git

which platform you use and why.

Did the things I just outlined
actually makes sense to you?

Does that help you make a decision
about which platform you want to use?

Yeah, let us know.

Shoot us an email at
[e-mail].

Or, I don't know, find us on YouTube
or on the website or elsewhere.

If you want to keep up with this
stuff with building small tech

then make sure to subscribe.

I have been your host Raph, and we
all want to do some good in the world.

So go out and build
something good friends.