hpr-knowledge-base/hpr_transcripts/hpr0223.txt

Episode: 223
Title: HPR0223: git
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0223/hpr0223.mp3
Transcribed: 2025-10-07 14:16:53

---

**Music**
Hello, welcome to Hacker Club Radio. My name is Quattu. I will be your host on this episode.
We're going to talk about Git, that is GIT. Git, you've probably heard of it. It's a versioning control system,
which, you know, if you're like me, that is basically completely meaningless. Git is famous
because it, I guess it was developed and is used by the Linux kernel developers. So it's,
and it's gaining momentum, at least from what I can perceive. I just see a lot of different projects
kind of going over to it or starting out, you know, with Git. And of course that is,
as opposed to using another system like CVS, concurrent version system,
or SVN, which stands for something similar, you know, system version something.
So the idea behind it all is that you've got code that is being changed by a lot of different people.
And so the concept, and this used to confuse me a lot, but the concept is that you just,
you basically copy the entire code base, you know, the whole project
as just one big folder from, you know, a Git repository or an SVN repository.
So you're just going over onto someone's server and you're taking that whole folder
and you're pulling it down onto your local machine. And then you create a new branch
on your local machine within that project. And you can make whatever changes you want.
And then you can push it back, at least that this is Git. You can push your changes back to the server
so that everyone can see your changes, integrate it into the main branch, you know, whatever.
So my usage of Git is very, very minimal and light.
So I'm going to be talking about just how to get it set up so that if you ever
do come across a project that is using Git and you decide that you want to compile
the latest greatest version, you know, straight out of their code base,
then you'll be able to do that.
I haven't actually done this with CVS and I've only done it once with SVN.
But the concepts are really, really the same. So it's going to be pretty similar no matter what.
But I just find that Git is one of the, for me, the easier one to understand.
And it just happens to be the one that I actually use, you know, on a daily basis.
And the cool thing about Git, well I'm sure SVN as well and CVS, but Git at least is being used
for like designing icons and things like that, at least on the Fedora project.
So it's kind of cool because it can be used as a version control, you know, for anything.
It doesn't have to be, oh, I'm a programmer and I want to contribute to code.
It could just as easily be, I'm a graphic designer and I want to, you know, make a new icon
for something that doesn't have its own icon, you know, in this theme or whatever.
So it's kind of neat.
So installing Git two different ways, obviously if you're using a Linux distro with one of the traditional package managers,
you can just say, you know, apt Git install Git dash all or yum install Git dash all.
And that will just pull it from your main repo and install it for you.
If on the other hand you are either using something without a traditional package manager
where you have to go get the packages yourself or you just want to go compile it yourself,
then again, it's pretty simple and you just go to Git. Git.org.cz, I think.
That is git.org.cz, I don't know, checklist of akia or something.
CZ, Charlie Zebra.
So you can just download the whole source there.
You can also get pre-built binaries.
So if maybe, I don't know, maybe you're using something that doesn't have it in its repo.
If it's an RPM based distro, you can download the RPM from the git.org.cz or the .deb.
You can also get it for Solaris. You can get it for OS 10. You can get it for Windows.
So you're covered, you know, whether you're at work, you're at home, you know, you're on your devian system,
you're on your Fedora system, you're on your Slackware system.
It doesn't matter, you've got fairly easy ways of installing this.
So do that.
And then the first step is going to want to be, you're going to want to download the code or the stuff that you're trying to synchronize with.
And the way that you do that is you type in Git. Again, it's G-I-T.
Git space, clone, space.
And there are two different ways to do this.
What I do is I just do Git, colon slash slash, and then whatever the server is.
So it could be like Git.You know, openproject.org slash icons, for instance.
And that's just going to take sort of, it's going to be like an anonymous login.
So you, in this case, you wouldn't have like SSH privileges.
You're just pointing your computer at the folder that you want from them and you're pulling it down and just copying it to your local hard drive.
Now this, this, you're not going to be able to do some of the nice Git like things, like just automatically push your changes back into the,
onto their server because you don't have SSH access in the read and write permission, in this case.
Now if you do, I mean, if you're, if you're well integrated into the project, they've given you full permission to, to read and then write back to their server,
they've given you a login and stuff like that, then you just type in Git, space, clone, space, SSH, colon slash slash.
Git.OpenProject.org slash icons.
And that's just an example of server. I made that up.
So that will take a while depending on the size of the project and your network connection.
And eventually it will create a directory that, you know, mirrors the master directory on the server.
Now the way I organize this usually is I do slash home slash, class 2 slash.
I have a slash, I have a code directory that I have in my home folder, just called code.
And in there I put all of my quasi programming projects that I'm not really understanding yet.
But you know, so anything that I'm working on that is contributing to open source, then I will have it pretty much in there.
So, so I'll have like slash code and then I'll make a directory, you know, in there the Git directories,
that's where I'll make my Git directories.
So I would copy it into, for instance, Git, you know, open project, something like that.
That's what I named the directory.
And that just makes a complete mirror within that directory.
So it's slash home slash, class 2 slash code, slash Git open project.
And then in there there's a complete mirror.
Git going, Git going along, Git going and make it too strong.
So now that you've got your local copy, you can start playing around with it.
Now, you don't really have to worry about messing up anyone's code because this is your, you know, especially if you're not committing,
especially if you don't have the SSH permission for the server.
You're just playing around with a local copy.
So don't worry about messing anything up.
And if you do mess anything up on your local copy, you can also, you can always just go back and repul the branch.
You know, you can just delete the whole folder and redo what we just did basically and start from scratch.
So just to prevent ourselves from screwing anything up, what we can do is we can create a new branch.
So one of the main things you'll see a lot of times on a version control system,
like when you go to compile it from source or something, like a project, you'll see that there's the main branch
and then there's the experimental branch, right?
Well, we can make an experimental branch for ourselves.
So if this is our icon team or something, then we can make an experimental branch that we can get in there and screw around with
and not really care about ever touching that, what would be called the master branch.
To make a new branch, you simply type in git space branch, space, for instance, experimental.
So now if we just run that, and that created an experimental branch,
so now if we just run git space branch, that will list all of our branches
and the feedback that you would see from what we've just done is a list containing two items,
one is experimental and one is master, and master will have a little star by it, a little asterisk by it,
meaning that that's the branch that we're in right now.
So we want to switch over to our experimental branch, probably.
So you're going to say git space, checkout space, experimental.
And now if you do git space branch, you will see that we are in the experimental branch.
Now, what you could do is you could grab a file and you could go and edit it, you know,
whether it's code that you're going to add some lines to or subtract something from,
whether it's an icon file that you're going to modify, whatever it is, whatever they're using in, you know,
git for, you can open it and whatever program you use, edit it, change it, do whatever you need to do to it.
And then what you can do, if you are, if you're very happy with that change, you feel like it's finished,
is that you can commit that change.
And the way to commit a change is git space commit space dash a.
And you wouldn't really want to commit anything until you can, until you've decided that that is what you are happy with.
Otherwise, there's not really much of a need to commit that change.
Now, if you switch over to the master branch, like git space, checkout space, master.
So now you're in the master branch. And again, if you just run git space branch, then you'll see that the master now has the asterisk by it.
You could edit another file, or you could even edit the file that you just now edited.
And you'll see once you open it up, your changes aren't there. It's in a different branch. So it's that same old master file.
Now, if you edit it now, and you get space commit space dash a, then you have two different versions of the same file, right?
You have the master version, and you have the experimental version.
Interesting, right? Now, for code, especially, because git tracks content, not files.
So for code, especially, you can, you could do a git space merge space experimental, because we're in master right now.
So you can say git space merge, space experimental, and that will merge the two, the two, the two different files together.
Now, if the changes do not conflict, then that has merged the two files, and that's it.
If the changes threaten one another, or take up the same space as each other's it were, then you will be warned that there are differences or conflicts.
And so you can run a git space diff to see what those changes are, the differences are, and then you can go in and resolve those differences or conflicts.
And then you can say git space commit space dash a, and then finally, really, really merge them, and that is just git k, g-i-t-k.
And that, that merges those two, the two different files from two different branches into one big master file in your master branch.
Pretty fancy stuff. I've never tried to do that kind of file jockeying with graphic files. I'm not really sure how that would work necessarily.
But certainly for code, or for documentation, or whatever, that is something that you can do.
Now, there's one thing that you might have the occasion to do, and that is to add a completely new file to the branch.
If you're contributing to something, for instance, for an icon theme, maybe someone just haven't come up with an icon for trash can yet.
So you're creating something from nothing. To do that, it's just git space add a-d-d space, and then the name of the file.
Now, make sure that you're in the right branch, of course. So first, since where we left off, I think, was in the master branch, I would first say, OK, git space branch, it would tell me what branch I'm in, and then if I need to switch, I would say git checkout experimental.
OK, so now I'm an experimental. Now, I would say git space add space, trashcan.png, and that brings the file into the git repository.
Well, at that point, you've come up with a new file, you've added it to your repository, your local copy. The only thing left to do, once you're finished with that file, you believe that your contribution is worthy of being reviewed by the main project leaders.
What you're going to want to do is push your changes back to them. Now, again, you can only do this if you've already got SSH permission.
Otherwise, you will probably just have to contact the project leaders and tell them that you've got this great idea and emailed them the file or however they want to deal with it.
But if you have SSH access, then it's a simple matter of saying git space push space origin, and that takes the file and pushes it back to the main repository.
Variable there would be in your dot git folder, which would be in that little repository directory, you want to make sure that you review the config file in there and make sure that origin is set up to be the correct server that you think it is set up to be.
It should be, if you just clone the entire thing, then it should have brought all that kind of configuration along with it, but you might want to just double check on that to make sure that it's all configured correctly.
And I failed to mention that there was a dot git directory, so after you clone it initially, if you do an LF space dash A, you will see that the only, you know, basically it's an exact copy of all the files from the main server, and the only real mention of git at all is that dot git folder right in there, and that's got config files and things like that in there.
So that's the main, that's really about it. I mean, that's from setting it up to editing to committing to pushing, and that's about as much as I know on this subject.
If you want to know more, there's a great git tutorial on, that is accessible from git.or.cz. It's actually on kernel.org, but I wouldn't know how to get to it from there, but there's definitely a really quick and easy tutorial.
I drew a little bit from that for this episode, so it will be familiar. The thing that confused me about it when I first did that particular tutorial was that it seems to be coming from the perspective of someone setting up their own git repository.
So it kind of talks at first as if though you were the project leader deciding to use git for your project, rather than you being an average Joe coming to a project that is using git and you having to integrate yourself to that.
So that's the perspective I've been doing this episode from. You're just an average Joe wanting to get involved with a project that is using git.
git tutorial will tell you more about it if you're starting project and you're deciding, I think I'll use git. So that's the two differences. Either way, it's a good tutorial. I would check it out. It is accessible via git.or.cz.
And there's a lot of links on that page as well for just a lot more information, you know, the official documentation, just really the nitty gritty stuff.
And like I say, this is pretty similar to, you know, in concept, this is pretty similar to SVN and probably to CVS as well. So you can certainly, you can certainly probably use this as a jumping off point.
You know, if you come across a project that isn't using git and using SVN and you just have to have the latest and greatest version and you want to compile it straight out SVN, I think you'll find that after you've played around with git a little bit, SVN becomes pretty easy as well.
So I hope this has been helpful and thanks for listening as always to Hacker Public Radio.
Thank you for listening to Hacker Public Radio, HPR is sponsored by Carol.net, so head on over to CARO.NAT for all of us in need.
Thank you for listening to Hacker Public Radio.
You