How Not to Be Afraid of Git, with O'Reilly Author Anna Skoulikari

✨Use this link for a free month of O'Reilly Learning and read Anna's book and any other resource on the platform! ✨ Meet Anna Skoulikari! She's a UX designer turned front-end developer, senior technical writer, and the author of "Learning Git" - a book published by O'Reilly Media that teaches Git in a simple, visual, and tangible manner so that you can build a solid mental model of how it all works.

Anna started teaching Git because she had to understand it herself. It's powerful but not the most user-friendly of tools. Yet, Git is what we all have in common, whether we're working on back-end or front-end development, on Windows or a Mac. Even GitHub's lawyers use Git!

If you're learning to code, you probably have many questions. Should you use GitHub, GitLab, or Bitbucket? What's the difference between a merge request and a pull request? Does it make sense to use Git from your command line, or is a GUI good enough? Where are all those files? And how, for the last time, does any of that work? This episode will help you understand Git and provide you with plenty of practical insights to navigate its complexities effectively.

🔗 Connect with Anna

• 👩‍💼 Linkedin
• 🌐 Website

⏰ Timestamps

• Anna’s journey into coding via UX design (01:44)
• How Anna decided to conquer her fear of Git (02:25)
• What is Git? (03:28)
• What can you use Git for? (04:38)
• What is GitHub, and what other platforms are out there? (05:35)
• GitHub’s lawyers also use Git (07:58)
• Should you use Git for your own projects, even if you’re not collaborating with anyone? (08:27)
• What is branching? What is merging? (10:39)
• How do companies typically use Git? (12:14)
• Community Break with Jan the Producer (16:47)
• When should a new deveoloper start learning Git? (18:36)
• Git is a unifying technology (20:27)
• Why is the terminology around Git so confusing? (21:38)
• How Anna teaches Git: the colors of the rainbow (23:08)
• Making the four areas of Git tangible (25:12)
• How to use git: command line or GUI? (28:04)
• What are merge conflicts and how to handle them? (33:24)
• How to practice merge requests and conflicts? (35:47)
• How Anna decided to write a book on Git, and how O’Reilly chooses animals for the book covers (37:57)

🧰 Resources Mentioned

• Use this link for a free month of O'Reilly Learning!
• Learning Git

⭐️ Leave a Review

If you enjoyed this episode, please leave a 5-star review here and tell us who you want to see on the next podcast.
You can also Tweet Alex from Scrimba at @bookercodes and tell them what lessons you learned from the episode so that he can thank you personally for tuning in 🙏 Or tell Jan he's butchered your name here.

Creators & Guests

Host

Alex Booker

Host of The Scrimba Podcast

Producer

Jan Gregory Arsenovic

Producer of the Scrimba Podcast

What is The Scrimba Podcast?

Learn from inspiring developers about how they found meaningful and fulfilling work that that also pays them well. On The Scrimba Podcast, you'll hear motivational advice and job-hunting strategies from developers who've been exactly where you are now. We talk to developers about their challenges, learnings, and switching industries in the hopes of inspiring YOU. This is the podcast that provides the inspiration, tools, and roadmaps to move from where you are to work that matters to you and uniquely fits your strengths and talents.

Anna Skoulikari (00:01):
I realized that the learning resources out there were not designed for someone like me that come in from a non-technical background into tech. And then this creative idea of using colors and storytelling and visuals came to me, and the first thing that I did was, actually, I made an online course. I started getting all these reviews, and then I realized, "Okay, the way that I teach Git really does make sense to people. So I'm ready to write this book."

Alex Booker (00:26):
That was Anna Skoulikari, a self-taught developer, UX designer, and the author of Learning Git. I wanted to speak with Anna because, no matter if you're doing Java or JavaScript, backend or front end, Windows or Mac, Git is the tool that all developers have in common. It's a source code version control tool used to track changes in your local code projects, but also coordinate and synchronize changes in code with a team.

(00:58):
Git is hard, or maybe it's just harder than it should be. The creator of Git is a brilliant technical mind, but usability was not their focus. Meanwhile, Anna is an expert at teaching Git to beginners. She's well-versed in the challenges newer developers face when learning Git, and she has some analogies, mental models, and a vocabulary that makes Git approachable for all. You're going to learn them in this episode today.

(01:23):
I'm your host, Alex Booker, and you're listening to the Scrimba Podcast, where we don't care who you are or where you come from. We show you that you belong in tech. Anna, welcome to the show. I'm really excited to get into Git, but tell us a bit about yourself. Were you always planning to work in tech?

Anna Skoulikari (01:40):
My journey has been a bit of a spicy one.

Alex Booker (01:42):
Spicy one.

Anna Skoulikari (01:44):
Yeah. I entered the world of tech because I was living in London and I did a UX bootcamp. I was in my early 20s and it was about time to actually get a job and do something. And I did this UX bootcamp, three-month bootcamp, learned the basics of UX design, and got a job as a UX designer, and worked in an agency in London. And while I was working as a UX designer and I'd learned to design apps and websites, I became really curious about how the developers took these designs and actually built these things. So as a UX designer, I felt like an architect, you build the blueprint, but then I had no idea how you actually built that blueprint. The construction company, what did they actually do?

(02:25):
So I got really curious about coding, and at the time, I'd moved to Barcelona and I decided to do a coding bootcamp in Barcelona to learn the basics of web development and follow my curiosity, and that's how I transitioned from UX design into coding. So I did a coding bootcamp in Barcelona and then got a job as a front-end developer. While working as a front-end developer is when my Git teaching journey began because, as a front-end dev, I had to learn Git to work with the senior developers, and I was terrified of Git.

(02:58):
So at the coding bootcamp, our Git education was, let's say, 30 minutes to an hour of Git add, Git commit, Git push, go, off you go. That was fine when you were in a coding bootcamp where you did individual projects and it was just you working on something, but once I got to the workplace and I was working in a team, and the Git workflow was a lot more complicated than that, I was terrified that I'd break something. So I decided to conquer my fear and to start learning how Git worked.

Alex Booker (03:28):
Well, that sounds like a perfect segue into the topic of today's conversation, which is, of course, Git. I thought maybe a good place to start would be with a definition. What is Git exactly?

Anna Skoulikari (03:41):
Git is a version control system. It's a technology you download onto your computer, and basically, it helps you keep track of all the versions of your code, and it also helps you collaborate with other developers. So let's say you write code on Monday, you want to save a version of your code because, when you start editing that code on Tuesday or you add more code, you want to know what you worked on on Monday and what you worked on on Tuesday.

Alex Booker (04:04):
It's a little bit like the document history in a Google Doc, or Notion or something like that.

Anna Skoulikari (04:09):
Yes, exactly. It's like that, but with superpowers, and then also collaboration. You can see exactly what different people have contributed to a project, and you can work on the same project at the same time and combine your code together or your content together.

Alex Booker (04:28):
I love that. That ability to see who else wrote the code, I think the term is Git blame, and I love that because, if there's a bug in the code, you can find out who wrote it and blame them.

Anna Skoulikari (04:38):
Yes, that's very true. And I actually work as a technical writer now. We'll get to that, but you can also, now ... I can always see, "Okay, who wrote this piece of documentation?"

Alex Booker (04:46):
Oh, my god. Yeah, that's such a good point, as well, that even though Git is primarily used for source code, it's also used for things like markdown files, which could be used for the content on a website or documentation. People even host their blogs via Git, essentially.

Anna Skoulikari (05:00):
Yeah. The diversity of people that actually use Git for various things is huge. It goes all the way from anyone working as a developer, data scientists, front-end devs, backend devs, all the way to even mechanical engineers use it. If you work in the gaming industry, game artists might use it.

Alex Booker (05:18):
Oh, really?

Anna Skoulikari (05:19):
And then technical writers, and then sometimes even a product manager or a UX designer needs to contribute something to a repository. And a repository is just a term for a project that uses Git. So a lot of different people use Git and for different kinds of projects.

Alex Booker (05:35):
The Scrimba Podcast is all about helping newer developers learn to code and break into tech. And quite early on, we tend to hear about GitHub as the place where coders hang out and share their source code and things like that. Sometimes we hear about GitLab, as well, and another similar service is called Bitbucket, but it's not as common these days. How does Git relate to GitHub and those other types of platforms?

Anna Skoulikari (05:59):
It's really good that you asked this question because I do know that a lot of people just think that Git and GitHub are the same thing.

Alex Booker (06:04):
I know. Yeah.

Anna Skoulikari (06:05):
It's really important to distinguish between the two. So Git is the version control system, it's a technology that you download onto your computer, and GitHub is a hosting service. So in other words, once you have a project that you're version controlling with Git, you can save it in GitHub, basically. It's like, if you think about having, let's say, a Word document on your computer and you have Google Drive, and Google Drive is a way to save your Word document in the cloud, it's kind of similar to that. The analogy can't go all the way. Obviously, it's not the exact same, but GitHub is just one of the hosting services, one of the ways that you can save your project that's version controlled with Git in the cloud, but GitLab and Bitbucket, like you mentioned, are other hosting services. So these are all just companies that provide this service, and that's the difference.

Alex Booker (06:59):
Yeah, maybe that analogy is the perfect one, actually, between, okay, you've got this local file, you want to put it in the cloud, so you upload it to Google Drive, say, but just like you could upload to GitHub and you could also upload to GitLab, maybe you upload that file to Dropbox or to some other cloud syncing service. It's basically that. It's the place in the cloud you can save the file, and then there's a user interface on top of that. You log into GitHub, you can view the code on the website, it can do nice syntax highlighting. Plus, as I'm sure we'll get into, there's a bunch of other tools for things like accepting contributions to the code base and talking about the code to do code reviews and things like that.

Anna Skoulikari (07:37):
Yeah, exactly. And also, you can go, let's say, to Google Drive and look at what other people are working on and maybe just download that to your computer. So in the same way, you can go to GitHub and look at, like I said, repositories or projects version controlled with Git that are on GitHub, and you can clone them or copy them down to your computer to check them out, if you have the right permissions, obviously.

Alex Booker (07:58):
We were talking about all the different examples of how people use Git, apart from source code. I don't know if this story is true, maybe you know, but I heard that lawyers at GitHub, even the lawyers, who've got nothing to do with code, they're just legal experts, at GitHub, they put contracts in markdown and then GitHub just to experience what it's like to work with Git and get a little bit closer to their product as they work at the company, but I just thought that was an interesting example of the versatility, and now we know a bit more about GitHub, it makes more sense.

(08:27):
So a big reason we use Git, I suppose, is to collaborate with other developers because, whenever we put something in the cloud, we now have a shared view of it, and that makes a ton of sense. Does it make sense to use Git for your own projects when you're just working solo?

Anna Skoulikari (08:43):
I guess it still is a good idea because, if you do do something that breaks your code, you do want to be able to still revert back or go back to a previous version of your code. Also, one of the things with Git is that you have commit messages, which are basically a message of what you updated in a particular version of your project. So there's a way for you to talk to future you and past you. You can have a track record of what you worked on at different points in time. And it is a backup mechanism if you're working on a project on your computer and your computer gets stolen. If it's in GitHub, you're totally okay. You could just re-clone that project onto a new computer-

Alex Booker (09:22):
That's right.

Anna Skoulikari (09:23):
... or copy it down again. So I think, even when you're working on your own, it's worth using. The only other reason I'd also say maybe it's worth using, at least for juniors that are hoping to then join a company, is just the practice. It looks good if you're in an interview and you can tell someone, "You can go check out my GitHub," and they can see that you commit often or that you use Git. Also, I just want to say that, and we'll get into this, but I teach Git, and I tell people, "You only need to learn Git if you really want to learn Git. It's not something that everyone needs to learn. So only learn it if you really need it."

Alex Booker (09:59):
I love what you said, that it's not just about a backup, because when you do backups via Dropbox or you're working in a Google Doc and you get that revision history thing, it's random when it does the backup, or it's based on a timer or something like that, but that doesn't make a lot of sense in code because that timer could elapse halfway between you finishing a line of code, and then you've got this weird state of the project to revert from. But then with Git specifically, you create checkpoints in the progress of the project and you associate a message with that checkpoint so that not only you can refer back to it, but as we'll continue to touch on in this episode, the team can have a bit more context to understand what's going on with that change and where it fits in the history.

(10:39):
I wanted to ask you the question, because I'm super curious about your perspective, but I learned how to use Git the hard way, which is, when I was learning to code, I would put the project on my desktop. Here's another great reason to use Git when you're working on your own projects. Sometimes you just want to go off and do something a bit experimental and you don't want to mess everything up. You just want to create a checkpoint, go and experiment, and then come back to the stable version. And that's exactly what I wanted to do. And when I wanted to do that on my desktop, I'd copy the folder, make a new one, call it version 2.2 or something, and then do you know what happened, Anna, is one day there was a glitch on my hard drive and the project just disappeared. That project had thousands and thousands of lines of code in it.

Anna Skoulikari (11:19):
Oh, no.

Alex Booker (11:19):
I was mortified. I had a local copy, but not a backup, necessarily. And yeah, of course, when it's in the cloud, if you go to a different computer, you switch between work and personal, you've got two personal computers, say, it's really handy to have it in that centralized place, don't you think?

Anna Skoulikari (11:34):
Yeah, definitely. And the feature of Git that you just basically referred to was branching, so this idea that you can create a branch off of your main project and you can work on another version of your project, let's say another implementation, and then you can decide whether you want to merge that back in or combine that back into your main project or not. And branches are just so powerful, and they allow more than thousands, millions of developers, well, maybe not millions, to work on the same project. I don't know a project that has millions of developers, but let's just stick with tons. Tons of developers-

Alex Booker (12:10):
A bunch, yeah.

Anna Skoulikari (12:10):
... can work on the same project because of this branching mechanism.

Alex Booker (12:14):
We just introduced two really key terms there, I think, which are branching and merging. How do teams typically use branches and where does this idea of a merge come in?

Anna Skoulikari (12:26):
Okay. Before I say anything, I just want to say that I'm not a Git expert. I'm really good at teaching the basics of Git and creating a really good mental model of how to understand Git. And all the teaching resources I've created, including my online course and my book, focus on helping you understand a very solid mental model of Git, and they never go into Git workflows because Git workflows are very specific to a team or a different company, and people can be really opinionated about them, and I am the opposite of opinionated.

(13:03):
However, the main basic workflow that you can think of is this idea that you work on the main project, which is on a branch. A branch is basically just a pointer to a commit, and a commit is a version of your project. So you work on this main version of your project, which is usually called main or master, and when you or one of your teammates wants to contribute to that, but they don't want to work just straight onto the main version, then they create something called a branch, another branch, which is often referred to as a feature branch if it's in the world of software development, and they can work on that feature branch, which is separate, they can do any kind of changes they want, and then once they're done, they can ask maybe their coworkers to review their work, make sure it looks good, and if it does look good and everyone's happy, then they can combine or merge their work back into that main project.

(14:02):
So the example that I use, for example, in my book is, let's say you have two co-authors that are writing a book together. They've decided that, whenever they make changes to the book, they don't want to make it directly onto the main script of the book because they want to make sure to have the other co-author review the work and an editor review the work. So they decide that you never actually work on the main script of our book, you always make a branch in our book repository, work on that branch, and then you get the editor to review your work and the other co-author to review the work, and if you get approvals from both of them, then you can merge or combine your work back into the main script. So yeah, that's the really, really basic workflow, but Git workflows can get very complicated, and in software development, they're often different just because of the mechanics of software development.

Alex Booker (14:58):
Yeah, and opinions, I guess, like how big should the branch be before you come back to the main branch, essentially? And things like that, I imagine, can change a lot, depending on the team.

Anna Skoulikari (15:09):
The world of Git is also extremely vast. We've just mentioned the term merging, but there are other ways of combining work in Git. I'm going to drop some terms, but we don't need to get into all of them, but basically, rebasing is another one. It's a little bit more advanced, usually. Cherry picking. So there's lots of different ways of combining work in Git, but merging is your bread and butter and the first one you should definitely get started with when you're a beginner.

Alex Booker (15:36):
It's not easy to understand. And I love what you did there, and you said merge, but you likened it to combining. That's something that is quite easy to see, and I get that. That's a really great way of explaining it. Just the word rebasing intimidates me to this day.

Anna Skoulikari (15:52):
Yes.

Alex Booker (15:52):
That's a lot more advanced and something we could go into at different time, perhaps. But yeah, that's brilliant. And I love this comparison with a book, as well, because, okay, you don't want an editor or the writer to make changes to the manuscript directly. Same with code, right? Ideally, somebody should get an opportunity to at least cast a second pair of eyes on it to spot any obvious errors or make sure it follows the style guide.

(16:15):
I think something else that I'm just going to throw in there, but we don't have to really understand, necessarily, so don't feel overwhelmed if we're throwing a bunch of stuff at you, is just that oftentimes there's this idea of continuous deployment, which is where, when you put something onto that main or master branch, it automatically gets deployed into production. So of course, you don't want somebody to be doing that unreservedly. You'd, of course, like to get a second pair of eyes on it. So yeah, just so many cool ideas and concepts that we've just teased in there. I hope it's exciting to people listening.

Jan Arsenovic (16:47):
Coming up, can you practice merge conflict?

Anna Skoulikari (16:50):
It's the only way. It's just practicing and developing a good breathing practice.

Alex Booker (16:54):
You said breathing practice, like in through the nose, out through the mouth?

Anna Skoulikari (16:57):
Yeah, just calm yourself down.

Jan Arsenovic (17:00):
But first, let's take a look at your social media posts mentioning our show, as well as your reviews from different podcasting platforms. Here's a new review from Apple Podcasts, "Scrimba Podcast, a developer's home. If you're into front-end development, Scrimba's Podcast is the ultimate sweet spot. I can't express how thankful I am for stumbling upon this heaven of coding wisdom. The podcast covers everything from JavaScript tricks to design principles, and it's like having a tech-savvy friend walk you through the latest trends. The hosts and guests don't just talk code, they exude a genuine passion for helping you level up," from Andy, age 27, an aspiring front-end developer from the UK, but based in Arkansas USA. Thank you, Andy, for this great review. If you are also feeling super supportive, you can also leave us a rating or a review in your podcast app of choice.

(17:53):
And Dan Atkins tweeted at Guil Hernandez about the Scrimba Podcast episode where he was on to talk about retrieval augmented generation, saying, "Absolutely incredible podcast. Thank you for sharing your views, Guil." Thank you for listening. If you're enjoying our show, the best thing you can do to support us is to tell somebody about it. You can do it on social media, you can do it in-person, or you can do it in your favorite Discord community. If you choose the social media route, as long as your tweets or LinkedIn posts contain the words Scrimba and podcast, we will find them and you'll get a shout-out right here on the show, but for now, let's go back to the interview.

Alex Booker (18:36):
As a new developer, you've got a ton of stuff to learn. I did hear what you said, and I really appreciate it, that you don't have to learn Git, but at the same time, we do know there are advantages, as you mentioned, to having contributions on GitHub. Every team is basically going to use some type of version control, and most likely Git in 2024. So we could say it's a bit of an advantage to know a little bit about it, have some experience as you approach your first developer job, but then I always get a bit overwhelmed by these subjects because there's a bunch of stuff that's really important to learn and is good to know before getting your first developer job. You have to draw the line somewhere. At what point do you think a new developer should start considering to learn Git?

Anna Skoulikari (19:19):
Well, what I meant to say by you don't have to learn Git is I just want to say that I'm not here to convince people to learn Git, basically. I'm just here to make Git easier to learn if someone does decide to learn Git. So it's more just that sometimes people are like, "Why should everyone learn Git and how should we convince them?" And I'm like, "I'm not here to convince people. If you want to learn it, I can help you if my teaching methodology matches your learning style."

(19:45):
But I would say, if you want to join a company, if you want to work as a developer, honestly, probably learning it as soon as possible is your best bet because, like I said before, even for your personal projects when you're building up your initial portfolio that you want to then show companies when you're applying to them, the more projects you have on any hosting service, GitHub, GitLab, Bitbucket, it's usually GitHub, let's be honest.

Alex Booker (20:11):
Let's be honest, yeah.

Anna Skoulikari (20:12):
Yeah, the better. And you're definitely going to need to use it at work. Git is basically the only version control system, not the only, there are others, but it's almost the only one that people really are using nowadays.

Alex Booker (20:24):
In 2024, you're right.

Anna Skoulikari (20:27):
It is just essential. And that's why it's also been so fun teaching Git because it's a unifying technology in terms of anyone in tech, almost, or almost anyone that codes experiences Git. And so we all suffer with our frustrations with it together and it's the one thing that we all have in common.

Alex Booker (20:47):
Oh, my gosh, you're so right.

Anna Skoulikari (20:49):
A data scientist and a front end dev can both just be like, "Oh, Git."

Alex Booker (20:53):
If you're on Windows, or macOS, or Java, or JavaScript/ I never thought about that. That's such an interesting perspective.

Anna Skoulikari (21:00):
Yeah, we're all just dancing with this technology, trying to make it work and trying to figure out how it works.

Alex Booker (21:05):
Wow, that's such a fascinating idea. In software products, databases, like developer tools, the databases are often really, really successful because every developer needs a database. I'm so happy you wrote a book about Git because now I'm realizing every developer needs to learn about Git, and it's hard. Well, I don't know. I think it's intimidating at first, but I think, with the right teacher and the right attitude towards learning Git, mainly focus on the basics, and sometimes you have to slow down to speed up with Git. I think if you try and rush through without understanding some of the fundamentals, that could be a bit of a problem.

(21:38):
So yes, it can look a bit intimidating. It's not necessarily complex, but the language and the terminology doesn't really help. And that's something I noted down before, because you said clone and likened it to copy, we say commit, but that's very similar to saving, we say repository, but a better word probably is project, GitHub call it pull requests, which I never understood, but then GitLab call it a merge request, and I'm like, "Okay, now you're requesting to merge the changes," or combine the changes, even better yet, as you put it before, Anna. And it just strikes me that the language does not really help make it easy sometimes.

Anna Skoulikari (22:13):
Yeah. Okay, two things. First of all, I can definitely help with the trying to make it more easily understandable, and I'll dive into that in one second, but before I do that, the person that basically invented Git, created Git is Linus Torvalds. He's also the creator of Linux. And he is extremely good at technical things. He is extremely intelligent in that realm, but I think, when he was creating Git, his priority was not making it user-friendly, it was more about incorporating all the technical features he wanted to incorporate in it. And so I agree with you that the terminology, the language is not the most approachable and easily understandable. In terms of making Git more understandable, should I dive into how I do that?

Alex Booker (23:04):
Yeah, definitely.

Anna Skoulikari (23:05):
Because I have my secret sauce.

Alex Booker (23:07):
I want some of that sauce.

Anna Skoulikari (23:08):
Okay. So the way that I teach Git is I make it very visual and I make it very tangible. And actually, using color is one of the major innovations in my teaching methodology, and making things simple. Okay. So how do I do that? Throughout my book, you're working on one repository, one project, which I call the Rainbow Project. In that project, you are just listing the colors of the rainbow. So you start off with a .TXT, a text file, a very basic text file, and you just say, "Red is the first color of the rainbow," and you save that project. So you make a commit. And I create these visuals where the commit in the diagram, which I include in the book, has the color red. So now, we're able to refer to the commit by just saying, "The red commit."

(24:01):
Something that maybe the audience, if they've never used Git before, might not know is that each commit has a 40-character commit hash. And what I mean by that is it's 40 letters and numbers that are a name for the commit, but you can imagine that, if you have a commit hash that's 1X2YB3, that is so difficult to refer to and to teach with to be like, "Oh, remember, commit, blah, blah, blah?" So instead, in my teaching methodology, I just have these colored commits. You end up having the red commit, the orange commit, the yellow commit. And so it makes the learning process so much simpler.

(24:43):
Also, it makes everything visual. I show you what commits look like with a visual representation of them. I show you what branches look like. They're literally just pointers to commits, like an arrow, just imagine an arrow to a commit. And the commits are circles. I represent them as circles, and that's a very common practice when people visualize commits. I make everything really visual. And the other-

Alex Booker (25:06):
Staging is another one that's hard to understand with text, but it's probably very easy to visualize.

Anna Skoulikari (25:12):
That's exactly what I wanted to touch upon. The other very, very important thing that I visualize for people and that I also make tangible is the areas of Git. And I basically identify four different areas. So you have your project directory or your project folder. Also, the word directory, if you're not in tech, sometimes you won't know that term and you're like, "What's a directory?"

Alex Booker (25:34):
Great point.

Anna Skoulikari (25:35):
Basically just a folder, people. Let's not overcomplicate it. It's basically just a folder. It's a fancy name for a folder, let's just say. And then there's the working directory, the staging area, the commit history, and then your local repository. And what I do at the very start of the book is I create a diagram, which I call the Git diagram, where I create a visual representation for each of these and I actually show you where to find them inside the .Git directory, which represents your local repository, your local version of your Git project. I don't know how many people in the audience will know this, but your local repository is represented by this .git directory and it's a hidden directory. So unless you've learned how to see hidden files on your computer, you're never going to see it. So that's a really important concept, and I go over that in the book, as well.

Alex Booker (26:25):
I'm hearing a few things here, which is, is this idea of using more approachable language, folder over directory, using visuals and supporting that with color, because the text in the docs and some articles, it can feel quite dense, but it's very breathable when you visualize it. And then, yeah, this idea of the .git folder, I love that because it kind of ...

(26:46):
People use the word magic a lot, but the thing about magic is you don't really know how it works. Git is not magic because you can explain how it works, and it really is that .git folder, that's where, when you do Git and Nits and you initialize a Git project or repository, I should maybe say, at which point that Git folder is a little local database with some context, and just knowing that demystifies it so much. Now, you understand, if you delete that .git folder, it's no longer a Git repository, and if you get yourself in some trouble, you can just delete it and do Git and Nits again. And I love this idea of bringing it back to the basics.

Anna Skoulikari (27:21):
And also making things tangible. Like you said, the staging area is often this confusing concept, but what I do in the book is I take you inside that .git folder and we look at the index file, and the index file represents your staging area. So you can literally just be like, "Okay, it's not these behind-the-scenes things that don't exist somewhere." And also, the commit history, it's represented by a folder in the .git folder called objects. So when you actually go into those folders, they're really hard to understand, but you don't need to understand what's going on inside them. Just knowing that they're there and knowing that they represent those different areas of Git makes things more tangible and makes them more approachable and digestible for people.

Alex Booker (28:04):
Anna, I realize we're speaking about some of the details of Git, but someone listening might not necessarily know what Git looks like as a tool.

Anna Skoulikari (28:15):
The original way to use Git is through the command line, and then other than that, you can use a graphical user interface. I think GitKraken might be one. I've never really used graphical user interfaces. I think Sourcetree is another.

Alex Booker (28:29):
Even GitHub have a desktop app. And what I see a lot of devs do these days is use Git from within Visual Studio directly, and they write the commit message in there.

Anna Skoulikari (28:39):
Yeah. Different IDEs also have just Git integrations. So when you're using a graphical user interface, you can just use buttons to do the same thing that you would have to do writing commands in the command line. I'm not opinionated. People can use Git in whatever way they want.

Alex Booker (28:55):
I respect that, but you revealed that you don't use the graphical user interface, and I wondered if you could tell us your perspective. Why is that?

Anna Skoulikari (29:04):
Ooh. I think sometimes it's just down to what you're used to. I do sometimes use it in the IDE, a couple of the features, and to be honest, I did just start a new job at JetBrains and-

Alex Booker (29:15):
They have a lot of IDEs. That's their thing, really.

Anna Skoulikari (29:17):
Yeah, and I'm working with IntelliJ IDEA. So I am also, as part of my job, I do need to actually know how things work in the IDE. So I do sometimes use that, but I think I've just gotten really used to doing things in the command line.

Alex Booker (29:31):
Very fair reason.

Anna Skoulikari (29:32):
And it is important to note that, even though you can do things in the graphical user interface, I don't think any graphical user interface can cover all of the features of Git. So you will be limited to some extent. Usually, you don't even need all the other features. Usually, a graphical user interface can cover most of your use cases, but the command line will always be the most powerful.

(29:54):
The only other thing I would say, though, is that it really does help to have a mental model of how Git works. And if starting off in the command line helps you to build that mental model before you go onto a graphical user interface, that might be helpful, but if you're someone that can build that mental model while just using the graphical user interface, then it's not up to me to decide how you're going to use Git.

Alex Booker (30:20):
I really appreciate that. I haven't got a strong opinion, but I have a thought, a lot of the time, what the graphical interfaces are doing is they're generating the same commands you would've previously typed as a command into the shell. And I sometimes, when I'm learning anything to do with technology, and I'm quite curious about your perspective of this as a teacher, I quite like to understand how things work just one layer beneath. I don't need to go all the way down and know how assembly code works or how the process of the zeros and ones, but when it comes to coding concepts or tools like Git, personally, I quite like going that level below, and then if I want the expediency and the convenience of a GUI, or G-U-I, before I get obliterated, then I can use it and I can know what's happening.

(31:04):
Maybe the risk of a graphical interface is that, even if you don't know much about Git, even if you don't have this really good mental model, as you describe it, you probably can make it work. You can smash the buttons, make something upload to GitHub, and that's pretty good, but then as soon as something goes wrong, you're going to struggle to understand why a little bit, and these are my loose fours. I agree. It's not important to be opinionated. You, as a learner, should pick whatever makes the most sense to you. I can also acknowledge that, if you have no experience with the terminal or command line, if the concept of a dot file is totally new, maybe you just want to stay away from that world for a bit, which is fair enough, as well. But yeah, what's your thought from a pedagogical perspective? Does it make a little bit of sense to go that layer beneath, perhaps?

Anna Skoulikari (31:47):
Yeah, I do think it makes sense, especially if, let's say, one button does two commands because then someone's not aware that it does more than one command, or if that one button adds certain modifying options that you don't actually know that it's doing that, I agree that sometimes it is good to just first understand how things are working with the original way, and then you can use whatever other thing. It's kind of like learning, let's say, JavaScript, vanilla JavaScript a little bit before you go into a framework, maybe. It's been a long time since I was coding, but I agree, that could definitely help a lot of people initially.

Alex Booker (32:23):
What was the hardest concept to teach in your book?

Anna Skoulikari (32:28):
That's a really good question. I don't think I have an answer for that. I think, because I have a very clear approach to teaching, all the features fell into that, and I can't really pick one that was the hardest to create a learning experience for. I'm not going to give you a really eloquent answer on this one, Alex.

Alex Booker (32:49):
No, that's totally fair enough. I guess I was assuming that something like rebasing might be hard to teach or sometimes ... You gave some really good analogies today. I wonder if some other features that are more advanced in Git ... It's hard to find that perfect analogy because sometimes the analogy falls down quite quickly, too quickly, almost.

Anna Skoulikari (33:08):
Yeah. I think, with rebasing, I had to go back and really understand the internals of how it works. So maybe, if I had to pick one, it would be the rebasing chapter.

Alex Booker (33:17):
You can't just take my answer, Anna.

Anna Skoulikari (33:19):
That's also the most advanced thing that I go over in the book, so let's just go with that one.

Alex Booker (33:24):
I code a lot by myself these days, more so than working within a team, and I think you can definitely and probably should learn the fundamentals of rebasing. It's super interesting. And many years ago, I did go down that path. So I get the basics at least, but so much of ... Well, you described these different workflows at companies, but also, you're going to end up in slightly different situations.

(33:45):
What if you're merging three branches instead of two, for example, or something we haven't spoken about at all, one of the most intimidating ideas in Git, is this idea of, okay, we have two branches and we're trying to merge one into the other, maybe we're trying to merge two into one, potentially, if we have multiple collaborators, but what happens if two developers edited the same line of code, for example, or they were stepping on each other's toes, or they overwrote another function, or even very innocent mistakes, like just the white space and the padding between the functions is wrong, and that's somehow messed things up? The way we've been speaking about it, it sounds like there are times when a merge is really just one action, it's almost automatic, but it's not hard to imagine that there could be conflicts at times, as well.

Anna Skoulikari (34:32):
Yeah, merge conflicts are definitely a spicy thing in Git. In the book, I explain the two steps of solving merge conflicts, and honestly, the only way at getting good and confident at solving merge conflicts is just practicing and also maybe developing a good breathing practice. The moment they happen, just take a deep breath. It's okay. You can always abort. And abort just means to exit it, go back, if you're just not ready for it in that moment, if you need a moment.

Alex Booker (35:00):
Did I get you right? You said breathing practice, like in through the nose, out through the mouth?

Anna Skoulikari (35:04):
Yeah, just calm yourself down because I think, in that moment, you get so-

Alex Booker (35:08):
It's scary.

Anna Skoulikari (35:09):
... fearful and scared. You're just like, "Oh, no, what's going to happen?" Because again, yeah, Git is not really user-friendly. I don't know, it's like, in capital letters, conflict and in red in the terminal, and you're just like, "Ah, what's happening?"

Alex Booker (35:23):
Overwhelming is a good word, right? And it's not even code you're familiar with if it's someone else's, what you're incorporating.

Anna Skoulikari (35:30):
Yeah, exactly, but once you figure out what the steps of solving merge conflicts are and once you've done it a couple times, you realize, "Okay, it's not the end of the world. We'll figure it out." And like I said, if a merge conflict ever happens, you can always just go back. So Git is powerful.

Alex Booker (35:47):
That's really good to know. Did you ever, by chance, during your bootcamps and experience teaching Git ... Well, you mentioned practicing merge requests or merge conflicts. Say you want to deliberately practice them, did you ever come across a way of doing that?

Anna Skoulikari (36:01):
You can just make two copies of your project on your computer and just practice breaking stuff. So yeah, there you go. In the book, you actually do that because, from chapter eight onwards, I simulate that you are working with a friend on this rainbow project.

(36:20):
So you start off with this rainbow repository that you're working on, and then you push or upload that to whichever hosting service you're using, and then in the eighth chapter, we pretend that a friend of yours clones that repository, downloads it down to their computer, copies it down to their computer, and starts working on it, as well. They're both probably on your computer because you probably don't have a friend to actually simulate this with, but then your friend has their own, we call the second repository friend Rainbow, and then they can add code and push it up to the remote repository, and then you can pull it down. So in one of the chapters, we go over a merge conflict, which you've basically created yourself, simulating that you are your friend and you at the same time. So you can definitely practice doing that.

Alex Booker (37:04):
I wish I had some better examples, not better than yours, but better than what I'm about to share, which is this idea that there are some GitHub organizations, I don't mean a GitHub organization, I mean there are groups of people who practice together and they have a GitHub repo, what they challenge you to incorporate a pull request, and then every week or once all the pull requests are merged, it resets back to the initial point where new people get a chance to try and do that. There are some groups that encourage you, as a new developer, to work on a project together. Could be for a nonprofit, could just be for fun and to practice. And I think, in doing that, you're inevitably going to use Git. And this is a really realistic example of how to ... Again, I say I wish I had better examples because I know things like this exist, I just can't remember them specifically right now.

Anna Skoulikari (37:54):
Open source projects can be a good place for that.

Alex Booker (37:57):
For sure. Thank you so much for coming on and telling us more about Git and your book. By the way, what was the process like, writing a book with O'Reilly? That's pretty cool, and I'm curious how it came to be in the first place.

Anna Skoulikari (38:10):
Yeah. So like I mentioned, I was working as a front-end dev, and that's when I decided to conquer my fear of Git, I guess a fear that many of us share.

Alex Booker (38:19):
Is that why there's a little cute bird on the cover, to make it seem less scary?

Anna Skoulikari (38:22):
Or maybe because its on a branch. I'm not sure. The thing is-

Alex Booker (38:25):
Whoa.

Anna Skoulikari (38:25):
... I will tell you this, Alex. Yeah, mind blown. The way that O'Reilly chooses the animals is a mystery. I have asked and I have received the response that it is a mystery and we do not know.

Alex Booker (38:38):
Interesting.

Anna Skoulikari (38:39):
But my theory is it's because of the branch.

Alex Booker (38:43):
Yeah. And I feel like, if you get an O'Reilly book on Python, it's going to be a snake on it, for example. It's probably some logic. Oh, no, wow, I just looked it up and the Python book has a mouse or a rat on it. That makes literally no sense. Oh, no, there is another one with a snake, but I digress. You were telling me more about the origins of the book.

Anna Skoulikari (39:01):
So when I was learning Git, in order to master it, or at least understand the basics, I realized that the learning resources out there were not designed for someone like me that come in from a non-technical background into tech. They referred to things that I didn't understand and they just were either too complicated or too advanced. And then this creative idea of using colors, and storytelling, and visuals came to me. And the first thing that I did was, actually, I made an online course. So I just thought that the barrier to entry to make an online course was lower than that of writing a book. So I thought, "Okay, let's make this online course and see whether the way that I teach Git resonates with people." So I made an online course, recorded some videos, and uploaded it to Udemy.

Alex Booker (39:46):
Udemy. You should've put it on Scrimba. Sorry.

Anna Skoulikari (39:49):
Well, we can discuss. But I started getting all these reviews and people were telling me, "Finally, someone that explains things in a simple way. I wish I'd found this sooner." And then I realized, "Okay, the way that I teach Git really does make sense to people and it's really serving a lot of people. So I'm ready to write this book." I'd actually wanted to write the book back when I was making the online course. It's just, as you know, or as you may have heard, writing a book is a huge endeavor.

Alex Booker (40:16):
Massive undertaking.

Anna Skoulikari (40:17):
So yeah, then I approached O'Reilly and I just told them, "Look, I'm going to write this book. Are you guys interested?" And they were. I was really lucky, and they were. Then I went away, and for a year, I did not sign a contract with them because I wanted to write the first draft of the book on my own, since I was going to use the Rainbow and visuals and go with a bit of a wacky, original idea of how I wanted to teach Git. So I really wanted to feel like I could realize my creative vision without any constraints or limitations.

(40:51):
So I did that first, wrote the entire first draft, user tested it, made sure that it made sense, and then I got back in touch with them and said, "All right, let's do this if you guys are still interested," and they were. So I signed my contract, started working with my editor, and well, then we made the book way better, did a whole lot more user testing, did some technical reviews, and yeah, now it's out. And it's called Learning Git: A Hands-on and Visual Guide to the Basics of Git. So it very much, in the title, says what it is. It's a hands-on learning experience and it's visual, and I'm really happy with it.

Alex Booker (41:25):
Yeah. When did it come out?

Anna Skoulikari (41:27):
It came out in June of 2023.

Alex Booker (41:29):
So not quite a year, but you've definitely got some traction.

Anna Skoulikari (41:32):
Yeah, I'm trying to think what I want to do on its one-year anniversary, my little book baby, but we'll see. But yeah, so I'm really happy with it.

Alex Booker (41:40):
Oh, congratulations. And the funny thing about writing or educating is that, what you did today, talking through these examples very eloquently, that's only possible because you've done all the thinking and spent a lot of time doing the thinking already. So it's great to know more about the origin, but your experience and your methodology towards teaching, I think, has shined through the entire time. Of course, we'll be happy to link the book high and proud in the show notes. Is there any sort of discount code or something for-

Anna Skoulikari (42:06):
Yes. I'm so glad you ... I was about to try to squeeze that in there. So basically, I have this code that gives people 30 days free access to the O'Reilly Online Learning platform, where they can read the book for free for 30 days. They can consume anything they want on the platform for 30 days. I think it's valid for the rest of 2024. And honestly, my book is not that massive. You can definitely read it within 30 days.

(42:35):
And other than that, I'd just say, if you want to learn anything else more about me and stuff, I have a website. First of all, my name, Anna Skoulikari, is unique. I'm the only Anna Skoulikari in the world. So if you just look up my name, you will find me. Whichever platforms are popular in that day and age and that I've decided to actually be on at the moment, it's LinkedIn. It's the one that I'm most active on, but I might be active on others in the future. I have a YouTube, I have a Twitter, but not very active on them. And then I have a website, annaskoulikari.com.

Alex Booker (43:09):
Anna, thank you so much. It's been a pleasure.

Anna Skoulikari (43:12):
Thank you so much, Alex, for having me.

Jan Arsenovic (43:14):
Next week on the show, the founder of Exaltitude and the former 19th engineer at WhatsApp, prior to the acquisition by Facebook, Jean Lee.

Jean Lee (43:22):
When a product is experiencing a lot of constant growth, you see constant changes and challenges, there's influx of users while you're trying to also keep up with the app running smoothly and growing the team. So it's a lot of different moving parts all happening at the same time. We had to work really hard to make sure everything was working well while we're onboarding people, onboarding users, and growing the engineering team.

Jan Arsenovic (43:51):
That was the Scrimba Podcast. Thanks for listening. And if you made it this far, please subscribe. You can find the show wherever you listen to podcasts. The show is hosted by Alex Booker. I've been Jan, the producer. Keep coding and we'll see you next time.