Git has become our industry’s version control gold standard for good reason: it’s a powerful tool that facilitates collaboration. Yet, as with any powerful tool, the flexibility it affords comes with the price of complexity which, coupled with the abstract nature of the problems it aims to solve, often seems daunting to beginners.
This session will equip you with the knowledge necessary to start contributing to software projects confidently by first exploring the whats and whys before getting into the hows. Some of the topics we’ll cover include:
- What common problems does Git solve, and how does it solve them? You’ll come away understanding why to use Git.
- How do I get started using Git? You’ll learn about setting up your profile information, which editor to use, and other basic preferences.
- How do Git’s basic tools work? We’ll explore the most commonly-used Git commands, such as: clone, add, commit, fetch, pull, push, checkout, merge, and branch.
- What common mistakes should I avoid when contributing to a Git repository? We’ll go over how to explore common pitfalls, and some good habits that will help make your contributions to a software project even more effective.
- What now…? You’ll not only walk away with a solid foundation, but also a handful of intermediate or advanced concepts you should explore next, along with a list of resources to learn more.
If you’re new to Git or have minimal experience with it, this session is for you.
Transcript
Alanna Burke: Intro to Git, I'm Alanna Burke. I work at a small firm called Chromatic. You can find us at chromatichq.com. We're a fully distributed Drupal firm. There's about 15 of us. You can find me on Twitter and drupal.org @aburke626. You can find me on the Drupal Slack and GitHub @alannaburke. Let's start by talking about what version control actually is. It's a system to record changes to your files over time. It tells you who made the changes, when they made them. Hopefully, it's going to tell you what the changes were. You can see what happened to your changes at any point in time.
It can be a centralized type of version control like Subversion, or it can be distributed like Git or Mercurial, those are the two most popular ones. There are a whole bunch of other ones out there. Why use Git instead of any of these other ones? Distributed version control allows you to download a full copy of the entire project. You go online, you clone the repository, we're getting to that, and you have that entire project locally on your machine. Whereas with something like Subversion, you are just using a little piece of that project at a time. It is hosted somewhere else, it makes it a lot more complicated.
With Git, everyone on your team can work on the same project, the same time, and you can do a lot of different branching. It's really easy. We'll talk about that. You can merge in your changes. Git is really, really fast. Here's just a few links for getting started with Git if you don't have Git on your machine, just some of the download links. Also, a really cool thing is try.github.io. You can just play with it in your browser and play with all the different commands without having to worry about setting anything up locally or messing with any repositories. That's a really, really cool way to just get used to the commands and how they work, because we are going to be using the command line today.
It's a very powerful tool. Interacting with computers, it's very fast. We're going to go over a couple of basic non-Git-specific commands before we get into Git, just in case, because you're going to need these for interacting with Git. The first one, cd, changes your directory. If you need to go into a different file, a different folder. ls will list all of the files in that directory and la will list all of the details of the files. Clear will clear your screen, all of your scrollback if you've got too much going on. If you want to create a file but not get into it, you can say touch and then the file name. If you want to create a folder but not get into it, you can say mkdir, so make directory, and then the directory name.
These are just a few things that will make your life a whole lot easier. If you start using the command line regularly, you're going to be using this almost every day. It can be helpful to have a GUI client if you need to visualize a workflow or if you have complex merge conflicts. I do keep one around for those occasions, but Git is really best on the command line. It's going to be faster, easier, you're just working within it. Hello, come on in. Your workflow is just a lot easier if you're working with a command line. These are some of those popular clients. There's the GitHub client, Tower is a very popular one. SourceTree is my personal favorite, and it's free
Speaker: Could we get up to do something.
Alanna: Sure.
Speaker: The previous site, git-scm, was that a .org or a .com?
Alanna: It's .com. That git-scm, that's where you find all of the Git documentation. There will be some more links to that around. That is the official documentation for Git. Once you have Git on your machine, you want to get it configured globally so that every time that you commit something it's got all your information. These are the commands that you'd want to run to give it your name and your email address. The first one is git config --global user.name, and then your name. Then user.email, and your email address. Again, much easier than trying to set this up in a client, which might not set it up globally, it's just going to set it up in one little place.
I'll post these slides online so you don't have to try and write it down. Git is also going to be set up to use your default editor such as Vim. If you want to use a different editor, you're going to do something like the following. If you're using Windows, this gets a lot more complicated if they give it the exact file path, so I'd recommend just checking out the documentation there. It's similar, you're just going to say core.editor, and then you move your editor.
Now we get into actually using Git. To clone an existing Git repository, really simple, git clone. A lot of these examples are going to use GitHub because that's one of the most popular. Bitbucket is probably the next most popular. If you go into GitHub, if you look at a repository, in the upper right, it's going to say something like clone or download. You can get this link that's going to be your .git link. You'd say git clone in that link. Yes, go ahead.
Speaker: I'm sorry. When you finish what you're saying and then I'll ask you a question.
Alanna: Okay. That's going to copy this entire repository, the entire project onto your machine locally. Go ahead.
Speaker: Is there a way to set up a project in Git directly from the server? Alanna: You mean from your machine?
Speaker: Yes, like a website, on a server. If you want to put it in a Git, do you have to download it from the server site or can you do it from the command line?
Alanna: I'm just going to repeat that for the recording. The question was, is there a way to set up Git from your server?
Speaker: A clone. I have a Drupal site on my hosting server but I want to set up a Git repository.
Alanna: You want to get that into Git?
Speaker: Yes.
Alanna: We're going to get to that.
Speaker: Okay.
Alanna: In fact, that's going to be the very next thing, is git init creates a new Git repository. You do this when you want to start developing and you don't yet have a remote repository. Most of the time, you're going to do this when you've started developing and you don't have anything yet. If you already have code and it's not yet in a repository, you would do this as well.
I'm usually going to say locally because that's the best practice. If you already have it on a server and it's not yet in version control, then you would do it on your server. In that case, that would be local to you in a way because that's what you would be working on. Local being the machine that your code is on, and remote being where you are pushing it and storing it. Does that make sense?
Speaker: Yes.
Alanna: Feel free to ask questions. This is a small group, so we can just treat this like a class. I've taught this exact thing as a class and it works well that way. Here's just an example of what happens. Here, I made a directory called test. I changed into that directory, and I said git init. It says initialized empty Git repository in sites/test. What Git does is it makes a hidden folder called .git, and that stores all the information about the Git repository in that folder.
The next thing you need to know if you're setting up a repository from scratch with git init is your remote. To see if you have any remotes set up, your remote being where you're pushing it, which in most of these examples I'm going to use GitHub, you would say git remote. Then v in a lot of commands stands for verbose meaning list out all of the things that you're doing. That's going to tell you if you have any remotes. To add a remote, so say you got a folder here, and you don't have anything in it but you've got something on GitHub and you want to push to it. You would say git remote add origin, your origin being the place that you're going to push, and then the name of your Git repository. Here's an example of this.
Here, I said, git remote add origin, and here's my test Git repository. Then I check to see what this is. It's giving me two links here, it says fetch and push. We're not going to get into that. If you want to do some really complex stuff, you can set up different remotes for where you're fetching and where you're pushing. I have literally never done that. It's pretty uncommon so you don't have to worry about that. Your remote is where your code is stored. That's usually going to be something like GitHub. Origin, you can change the name of that, it's just what GitHub is calling the place where your repository is.
Not usually a lot of cases to change the name of that. I can't think off the top of my head that I've ever had a reason to change that. It's just how GitHub knows what it's pushing to. You could if you were using something like, say Pantheon maybe and you want to achieve push to Pantheon and say another test server, you might have a couple of different remotes. You would say you would name instead of origin, you might name one Pantheon, and you would name one my other remote or something. When you push, instead of saying origin, you would say like Pantheon and my other remote. That's out of Git101, but I just want to explain what origin is.
Branching. Branching is one of the most important parts of source control with Git. Creating a branch allows you to work on the code in your repository in a silo, separate from any other code changes. git branch says, make a copy of the code that I'm working on and let me make changes in it. I'm not going to make any changes to this existing code, I'm going to make a copy of it, and make all my changes in there. You can do whatever you want, you can screw it all up, you can break it, you can get rid of it. Do whatever you want and you haven't broken anything in the main project.
It's pretty much the most important thing, and one of the reasons Git is so powerful. Super easy to do, say git branch and name of branch. Checking out a branch allows you to switch to a different branch, or what you'll end up doing a lot is combining the branch and checkout commands to make a new branch and switch to it. You can check out an existing branch by using git checkout and then your branch name, or you can make a new branch and switch to it, pass in git checkout -b, and then your branch name.
Here's an example of that. I checked out what's called my master branch, switch to it, Git tells me, "Hey, you're up to date." I said, "Okay, I want to make a new branch called new-branch and check it out." I said git checkout b new-branch, and it says, "Hey, you switched to a new branch called new-branch."
The main branch of your repo is called master. The general Git workflow, you have your master branch, this is the code, it's on your website, your live code. Then you're probably going to have a develop branch. That's probably what you are using on your QA site or your testing site. Then you have what's called feature branches. Say I'm working on an issue or something for a client, I'm going to make what's called feature branches. I check out something called ticket 123 new report view, and that's a feature branch. Those get merged into develop for testing. Then when those are good, that develop will get merged into master and then with live.
You might also have release branches if you work in an Agile or Sprint where you would say, "Okay, all of this work is going to get put into this release so we're going to work like this and we're going to have all of these tickets in this release branch," which again, most people are going to merge into develop testing, and then merge develop in the master. You will also have hotfixes where something needs to get merged immediately. I would usually hotfix whatever the issue is, and that more likely is going to get merge straight in the master. There's a couple of links here. When I post this, you can test these out for things about Git workflows and Git branching models.
Everybody does this a little differently, but this is a pretty typical setup. Let's talk about git add. This stages prepares your files or directories to be committed. You just say git add and the name of the file or the whole directory. If you say git add and then there's a period, this will stage all of your modified and added files, but not anything that's been deleted.
If you want to also stage your deleted files, you have to say all, so git add all also stage your deleted files. Then I'm going to combine this by showing you git status, which is something you're going to use all the time to see what's going on in your repo.
Git status just shows you the whole status of your current working directory, everything that's going on. Here, I've said, git add sites, which is a directory, and I said git status. It says, "Okay, you're on branch new-branch. Here's the changes to be committed," because I've added them. It'll also give you some instructions here, you can say, git reset unstage these. Here's what's been modified and here are the changes that are not staged for commit. This is something you're going to use all the time. It also tells you, "Hey, you can add file to update what's going to be committed, and you can use git checkout -- to discard all the changes in your working directory."
Git is actually pretty good at giving you help all the time. Git commit commits the stage changes to your branch and gets them ready to push. If you add -m, which you should always, it will add a message to your commit. If I say, git commit -m, added header to report view. One thing I can't stress enough is to commit early and often. Small, self-contained commits are easier to understand and they're also easier to revert if something goes wrong. If you spend days and days and days working on something and then make some massive commit, if you've got to test that and something is wrong, it's going to be a lot harder to find it, it's going to be a lot harder to pick out what was wrong and fix it.
Especially, if say, maybe it doesn't get found in testing, maybe it gets pushed, and maybe a couple of weeks later someone is on the site and they say, "Hey, something wasn't working right," now you've got a regression. Now you've got to go back and figure out when did something go wrong, and where was it wrong. If all of your code is a little commits, where you have little chunks of code, very nicely wrapped up and described, it's going to be a lot easier to find where was the code that broke something.
Speaker: Is there any limitations to the number of commits that you can do?
Alanna: Absolutely not. There's no limitation on the number of commits you could do. You can commit every single character change if that made you happy, I wouldn't suggest it. You can commit as many times as you like. I try to keep my commits logical. In this example, I say adding header to report view and this one says adding report view. In the next slide or two, I'll talk about what makes a good commit message. I like to keep mine so that I can describe it in a few words. If I need more than a few words to describe it, then it probably should have been another commit, that's just my personal way of doing it.
Here, I say git commit m adding report view, and then it tells me new-branch. This is the commit hash, which when you get into some more advanced get stuff, you might use that. That's the unique identifier for this commit. It says adding report view. It tells you how many files were changed. I think is how many line insertions and how many deletions. Here we go. Commit messages. Anatomy of a great commit message. This is something that a co-worker of mine did a blog post on. It should always have one line of summary, capitalized and succinct, 50 characters or less. If it needs a longer description, it can be followed by that, but there should be an empty line in between. All lines should be wrapped at about 72 characters.
If you have an issue to reference like a GitHub or a Bitbucket issue, you should reference it there so that people who are looking at these can find them. I rarely find the need to put a longer description. Like I said, I like to keep my commits so small that they don't ever need them. If you're doing something long and complex, or something that maybe you need to describe to a stakeholder depending on your workflow goes, you would want to describe it in a longer description here.
Here's an example of a really wonderful long commit message. We've got fix for editor dashboard showing incorrect date. Fixed date calculation logic, added function docblock to comply with coding standards, refactored for each loop, improving clarity. Closes gh-80. I, personally, am the kind of person who would have put a commit for each of these, but that's just me. This is a perfectly legitimate, wonderful commit message. They've got an empty line between these, they put lovely little bullets, and they referenced a GitHub issue. If you want more information on this, we have a blog post with some more examples.
You should always have informative commit messages. You don't ever want people wondering, though, "What was this?" Don't just write updated or fixed or fixed broken code or updated again. No one ever likes to go back and look at those. There should always be something concrete. I've read somethings at commit messages that say things like a commit message should always finish the sentence. This commit fixes, it should be the second half of that sentence. Actually we got through these slides really fast. I didn't intend to talk that fast. If anyone has any questions or wants to do anything interactive or go through any of this, I'm totally happy to do that. I didn't realize, I do it a lot slower. Go ahead.
Speaker: One really quick question.
Alanna: Sure.
Speaker: Is there a utility out there besides the ones you listed, the GUI loads you listed, that would create maybe an interface, looks like a spreadsheet showing the commit ID and then a description so you can go through them?
Alanna: The question was, is there a GUI out there that would create a spreadsheet view that shows the commit ID-
Speaker: The message.
Alanna: -and the message.
Speaker: Like a table.
Alanna: I'm not sure off the top of my head. I'm not sure that I've ever needed that particular information. Sarah?
Sarah: Tower actually does that.
Alanna: Tower does that?
Sarah: Yes. They have the name of the person you push, the commit ID and then the message [crosstalk].
Alanna: Awesome.
Sarah: In Stash, when you push something to Stash and have a pull request, the pull request has your commit messages here with each of the commits with when they were committed and all the information about that stuff.
Speaker: Thank you.
Alanna: I love a command line, but the GUI can definitely be useful for quickly scrolling through history, or trying to find things like that. I mentioned merge conflicts a couple of times if you're not familiar with that. How that happens is when you have changed something locally, and it has also changed on the remote. Either if you pull the remote into your local or if you push your local into the remote without pulling it first and you have changed the same code, you'll get what's called a merge conflict.
You have to resolve that manually, generally, which means taking a look at that file and saying, "Okay, this person changed these lines, and I changed these lines," and just editing it to fix how it should be. Which is usually pretty straightforward unless you were actually editing the same function in which case you're going to have to collaborate and fix that. You just can't understand why do people changed the same lines even though you probably both just added a function and it said, "Okay, you added a function at line 70, and you added a function at line 70." It's only a computer.
Generally, you fix that. You say add, you say commit, and Git will resolve that. Sometimes it gets a little complicated to look at on the command line. It can be a lot easier to take a look at it in GUI where it'll mark it off in the next color so you can say, "Okay, here's where it is. This is the line where it's messed up and this is the line where it stops being messed up." Now I can go, "Okay." Then the editor can take a look at it. That's merge conflicts. They're generally not a huge deal. A great way to avoid them is when you are pulling--
This is not the end of my slides. Hang on a second. I thought they ended really early. One moment. I was going to say it, there's definitely some stuff about git pulling in here somewhere. There should be because you should pull often. Just bear with me for a moment.
Sarah: That's also where the small commits can help you-
Alanna: Yes.
Sarah: -because you're much less likely to trump on somebody else's code if you just [unintelligible 00:26:29].
Alanna: I'm just going to blank that up for a sec while I go look for my presentation and figure out why it's not up-to-date. Sorry about that. Sorry, technical issues. Computer, you're young. There's a bunch to talk to you about git pushing and pulling because those are important. Hold, please.
[pause 00:27:27]
Alanna: Here we go. I hope it didn't mess up the recording too much. Told me not to mess with that. Sorry. Resuming. I thought this ended really early, but I just believed in my computer when it told me I was at the end of my slideshow. We'll just resume. After you've committed, if you want to reset, changes that you've staged and unstaged them, you can just say git reset. This won't get rid of the actual changes that you've made to the files, it will just take them out of getting ready to be committed. If you actually want to discard them and go back to the previous state that you were in, you have to add --hard. That will actually get rid of the changes to your files.
When you are all committed, and you are ready to go, you have to push the code to remote repo using git push. Usually, you want to be pretty specific with this, so you would say git push. The u tells the repo to track the upstream or remote branch. If you saw in some of the previous messages, it was saying things like, "You're up-to- date, there are no changes." That's because I always use the u command and say, "Hey, this branch should always be tracking the upstream branch, always be looking at this remote branch." There is an origin to tell it, "Hey, make sure you're looking at the origin branch." Then the name of my branch.
Here we go. Here's an example of git push. I say git push, u origin, new branch, which is the name of my branch and it tells me objects, blah, blah, blah compression, writing, total, and then it tells me where to push them. Then it tells me that my branch is set up to track the remote branch from the origin. Git pull, that pulls your remote branch into your local branch. To reduce merge conflicts, which is why I remembered that I have more slides, pull often so we always have a copy of the latest code. Because Git allows so many developers to work on the same code at the same time, your code might always be changing.
For example, I'm working on a project with Sarah and she's always pushing to our future branch. I always have to make sure that I am pulling that branch down because otherwise, we're going to be working on the same thing and we're going to have merge conflicts. The more often you pull, the less often you have to deal with merge conflicts. Fetch. Fetch your changes from your remote repository. This will tell your local repository about new branches or any other changes. It doesn't actually do anything, it doesn't pull anything, it doesn't change any files. It just tells you about them.
Here's an example of git fetch. It's not entirely true that it doesn't do anything. It gets other branches but it doesn't change your files or overwrite anything. It tells you, "Here we found all this new stuff and there was this new branch in the remote repository so we went and got that for you." Git merge is something to know about but you're not going to use this much in everyday development. It merges when granted to another, as you may have guessed. When you use git pull, it actually uses merge. When you want to merge a branch, for example. under master, it's very likely that you're going to be doing this online in the GitHub interface via a pull request.
It's much less likely that you're actually going to be doing it on the command line but you should still know that it exists. We talk about a few common mistakes, pitfalls, times you can revert, things that you can fix. We already talked about how to reduce and fix merge conflicts. Git amend helps you to amend or edit your previous commit. If you change something, you can say git commit --amend. If you want to add it to your previous commit, add the file first, say git add, and then you should add a new message. If you don't want change the message, just say amend. You do want to update the commit message. You can add a new message.
This will just add it to your previous commit or overwrite your previous commit message without just making a new message. This only works if you haven't pushed yet. If you've already pushed this, it's just going to make a new commit. This can be really handy. If you did something and then realized you had a typo or something like that, just say git commit amend. If you don't need to change your message, perfect, or if you had a typo in the commit message, you would say git commit amend and then amend the message. I use this all day, every day.
One that I forgot a lot and have to look up. I don't know why because it's so easy is how to rename a branch because I got typos in my branch names. Git branch -n and then the new branch name. You just do this from the branch that you're on to change that branch's name. The old branch name no longer exists and you have a new branch name.
[phone rings]
Alanna: I didn't mute my phone. Terrible person. Now that's the official end of my slide. Those are just a couple of things that come up for me pretty often that I try to fix. I didn't want to get into anything too in-depth although I know I mentioned a few things because Git can get complex but I don't find it intimidatingly so. It was interesting when I was doing research for this, I was surprised to find how many people-- If you type Git is in Google, you'll find some people who are like, "Git is a nightmare." I think that if you think Git is a nightmare and so complex, I think it is your process that is wrong and not Git. I think anything can be a nightmare if you have a bad enough process.
Having a good workflow and a good grasp on the basics like with anything is probably the most important thing. People were talking about how horrible merge conflicts are. I have been working with Git for almost a decade and I don't think I've ever had a merge conflict that I would even call a nightmare. If I did, it was my own fault. I just thought was really interesting to see how many people actually just hated Git. Some of those people just seem to think we should do everything via FTP. I just had to close my browser and cry.
Sarah: Oh my God.
Alanna: It was just interesting to me. If there's any questions or anything anyone wants to go over or needs help with, I am happy to do that. I forget what time this presentation actually officially ends. I didn't get a badge. They were out if them.
Speaker: What's interesting about Git is you have to force yourself into it.I, on the other hand, lazy. Although I have attempted several times to get into it, I fall back to just, "Oh, I'm just going to make the change on my desk," and I'll do the same. Whereas if I had Git, my workflow would probably be at 5 or 10 times faster.
Alanna: You really have to use it all day, every day to start learning which usually means there's someone on your team who at some point is going to say, "We are using Git now and that's it." When I wanted learning GIT, I think I was actually the person on my team who said, "We are using GIT now," just so that I would have to learn it which was awesome. Now I'm on a team where everyone uses Git and that's fantastic. I can't imagine not using it. I think we had one client that I encountered a couple of years ago that wasn't using any version controls. It was horrifying and we got them onto it. That was good. [chuckles] Sure.
Speaker: Can you actually talk about branching again and maybe walk through an example of how to branch something? I work at a place where I'm working [unintelligible 00:37:04]. I guess I want to take all those files, putting my own instance of it but the commands don't make it easy for me to just do it quickly so I had them just copy-pasting which is two instances of it and working on them. Deleting the first one and then moving all. It's really bad. How does it differ from submodules? Sorry, [unintelligible 00:37:26] from Git submodules [unintelligible 00:37:28].
Alanna: The question was can I go through an example of branching. I can certainly do that. Let me just pull up a-- Let's see. Actually, I'll just go into the repo for this presentation. I'm on the master branch for this repo which I actually need to have push. I'll just put an example here. There's everything that's in this repo. Here's a status. I've made some changes to this and I want to add them all. I'm just going to do this so that I can get to bridging [laughs]. I want to add everything. Will just show you how that looks. Everything is ready to be committed.
Speaker: Oh my gosh, what is DS store, and why is it in every repository?
Sarah: It's a mark.
Alanna: It's some weird mark. If this were client site, I would have a Git ignore that told that file to go away but this is just a review JS presentation so I don't care. [laughs]
Speaker: Got you. I've just seen it and I've never known an explanation for it. Speaker: It's an added thing.
Speaker: Most people wouldn't understand it.
Speaker: It informs the [unintelligible 00:39:06].
Speaker: What's going on in the [unintelligible 00:39:08].
Alanna: That's commit m. I turned my Wi-Fi off because it kept asking me to connect and I didn't actually want to use so I'm not gonna push it. I'm on the master branch because I'm working on master because again, this is just a presentation. I would not really never do that if it were a website. Here's how you would normally use git check out, branch. This creates and checks out the branch at the same time. Then let's say that I was working from GitHub issues, my name [unintelligible 00:39:57] is usually say GH and then the number of it and then a description of it. Fix header-text or something like that. It would be cool if I could type.
That's a pretty typical example of how you would check it out. Now I have everything here, just like I have before. You can see it's exactly the same files, but it's just a completely new copy. I can do anything I want and it's not going to affect the changes that were made here that are already committed and done and clean. I also have a whole bunch of plugins in my terminal that tell me things. This tells me what branch I'm on. This yellow, it tells me my branch isn't clean there, things that aren't committed. This tells me that everything here is clean and that everything here is committed. That kind of stuff.
If you look on Chromatic site, I think that there's also a blog post on that, handy stuff. If you're working on Git a lot, that stuff can be really helpful. Sometimes you might miss a file, especially if you did something like git add without the all and you didn't realize that you had missed something. Then I'll realize it's yellow and I'm like, "Oh, what did I miss? This should've been green." That kind of thing can be really helpful.
Speaker: Can you add your list of plugins to your presentation? Will you put it online, please?
Alanna: Yes. Let me grab a pen and remind myself. Sarah, can you make a note for me to do that? [laughs] Thank you. Sorry for making you my secretary. [chuckles] Does that help explain?
Speaker: I think so. We're in this new branch. What we do is make changes and then say git status, get out old files because that's going to make sure it's all green. Do you check out to the master branch or do you just push it or commit it? How do you merge it to the master?
Alanna: Let me see if I can live demo this. Let's live on the edge here. I've done my presentation, let's live on the edge. Let me change something.
Sarah: Git is going to keep track of, "Oh you have a change on this line of this file and it's different because I did a comparison."
Speaker: Sure.
Sarah: Then it's going to give you a list of, "These are the seven files that you touched." You can decide then that these four are the ones that I want to commit, these three, I'm still working on. You add those. When you then git commit, it says, "Okay, now this is the new way of doing things." You still only have that local. You're still [unintelligible 00:43:09]. Then when you merge it is when it goes back into whatever everybody is going to get from it so then nobody will miss something.
Speaker: Right. At what point do you merge?
Alanna: I'll do a whole live demo here. I just modified my file. You can see that's modified. I'm going to add it. Working on this branch, I'm going to commit it. Sorry, I can't see my screen. Then I'm going to have to connect to the internet. Let's see. Wat do we got here? Drupaldelphia.
[pause 00:44:05]
Speaker: I'm seeing something up there.
Alanna: [unintelligible 00:44:24]. Did I spell it wrong? I did. Live demo. There we go. All right. This is what you would normally do if you're working in GitHub is you would get here and you're going to push this branch. We say git push and then track the upstream, origin, and then my branch name. It's going to go duh, duh, duh, duh, duh. We did it. Oh, this is Chrome, that's why. Sorry. What is their repo called? Oh, sorry. [silence] Oh, this one. Then when you go to the repo in GitHub, it's like, "Hey, look, you just pushed this."
Normally what you would do is a pull request type of process. I'm like, "Hey, let's make a pull request." These are actually the last couple of commits I did. It updated it and then, hey, live demo. Here's where you would tell anything. If your team is reviewing it, you'd say, "Hey, look, this is all the stuff. These are all changes I made. Please review." You put any of the information that they need to see like screenshots and reference all the issues there to fix and things like that.
This is what I do every day, day-to-day. You can assign people and view them, that's all the cool kid helpstuff. Then say create a pull request. This is why I said you're not going to do a lot of merging because you're going to do it in here. Then when it gets approved by whoever on your team or even if it's just you. Even when I'm doing my own stuff, a lot of time I'll do this just to keep it in a nice workflow. Then you would merge it. Then you can get rid of that branch, but you're still going to have it locally. I still have that branch locally, I've just deleted it on the remote.
Speaker: We're in a GUI right there, right? In GitHub?
Alanna: Technically, yes. Now, this should be live demo. [laughs] It worked. Does that help explain a little bit?
Speaker: Yes, definitely. You can resolve the changes even from the command line too, you don't have to go to GUI.
Alanna: Oh, yes. You can absolutely resolve them from the command line.
Speaker: I saw that you pushed to your branch essentially. Can you push to master once you've made it, or do you have to switch branches [unintelligible 00:48:03]? I saw that you said you were in the branch that you created and you said push origin.
Alanna: Yes. I'm in a different branch from master. You can merge into master without using GitHub. You don't have to do that if you wanted to just use a git merge. You can do that on the command line if you would like. I just happen to really like the pull request. I like having that history. I live a lot of my life in GitHub. I either live on the command line or in GitHub, so I like having that history around too. Plus it's searchable, so it's in there.
All of my clients are in GitHub, so that's helpful. I don't really think of that as much as a GUI that you don't want to use. You want to use the command line instead of the GitHub GUI or search through your Tower because it's faster and easier to use. I don't really think of GitHub that way if that makes sense. I'm really happy that that worked. You never really know. Anything else? I really don't have a badge and I don't know what time the session is over.
Speaker: 11:15.
Speaker: 11:15.
Alanna: Sometimes they're in hours, sometimes they're 50 minutes.
Sarah: Do you have any experience with cherry-picking?
Alanna: Some. I would say that is totally a more advanced topic that I'm not prepared to give a good explanation of. I think I would give a more confusing explanation to be totally honest.
Sarah: That's when merge conflicts, go really haywire and things get merged when you shouldn’t have probably.
Alanna: For those who don't know, I can explain what cherry-picking is. The cherry- pick is to take various set of commits and get them together and stage them for a new set of changes. It can be really complicated and is never any fun. Like I said, if I were to try to explain it any more than that, I think I would make a really complicated and confusing explanation. Sure.
Speaker: Can I ask about submodules?
Alanna: Of Git?
Speaker: Git, yes.
Alanna: Of what in particular?
Speaker: I've no idea what it is but I'be heard it has to do with Planchette.
Alanna: I don't really know anything in particular about and I've never installed anything extra to Git so I don't know that there's anything in particular that you need. I have all sorts of fancy things on my command line that make it look fancy but I don't know of anything in particular that you need to make it work.
Speaker: Thank you.
Alanna: As long as you can run Git, you can do anything you need to do. If anyone is telling you any different, they're just trying to make your life harder. Sure.
Speaker: How do you delete merged branches?
Alanna: There's a prune command I think. There's another. I'm a terrible person to ask because I never do it. I used to have some weird fear of meeting them which is terrible. Don't do that, delete your local branches. Off the top of my head, I have to tell you that I don't know. On our team, you can ask Mark. He has some command that checks against all his remote branches and then deletes the ones that have been merged. About every six months, I ask him what that command is. It might be pinned in that Slack somewhere. If you find out what it is, I'll put it in my presentation.
Once your branches are merged, you don't need them anymore so you can totally delete them. I will admit that I do not know the ins and outs of how Git works on the hardware level, but it doesn't take up vast amounts of space on your machine. It's just nice to clean it up so that if you're looking for a branch, you don't have 8,000 branches. I'm always tabbing through them if I'm looking for a branch so it can get confusing. [silence]
Speaker: When will you have your slides up?
Alanna: Since the internet is working, I want to start taking a couple of notes from things that people asked me to add. As soon as I get those, I'll have them up-to-date.
Speaker: Great.
Alanna: I have instructions somewhere about how to do that so as soon as I find those instructions.
Speaker: [chuckles] Thank you.
Alanna: They gave me presenter notes but that's it. It doesn't have anything like how long your session is. Just fine [unintelligible 00:53:51].
[00:53:59] [END OF AUDIO]
