Getting Started with Git

Slide 1

Slide 1 text

Getting Started with Git Welcome...

Slide 2

Slide 2 text

Jared Koumentis @ShepBook Who am I?

Slide 3

Slide 3 text

Founder Full Stack Technology More who am I?

Slide 4

Slide 4 text

➜ ~ awesome terminal code ➜ ~ type it in to do stuff This is how I show code you can type in your terminal. I use Oh-My-ZSH, which is where the little pink arrow comes from. The ~ (tilde) is where my current directory is shown. ~ is “home” in unix like systems.

Slide 5

Slide 5 text

1 2 3 4 5 Five things/topics

Slide 6

Slide 6 text

Your First Repository Getting to your ﬁrst repo. Quick overview of installing git and getting to your ﬁrst repo.

Slide 7

Slide 7 text

Committing Making your ﬁrst commit. When you should commit. Conventions for writing git messages. Amending commits.

Slide 8

Slide 8 text

Reviewing History Reviewing your past commits. Cover some different “git log” options.

Slide 9

Slide 9 text

Branching & Pull Requests Branching - When and Why. Pull requests and “GitHub Flow”.

Slide 10

Slide 10 text

Sharing Your Repository Sharing your repository with others. Setting up a git remote. Making your ﬁrst push. Collaborating.

Slide 11

Slide 11 text

Your First Repository Now, let’s dive straight in. Let’s start with what Git is and how to get it. Then we’ll make your ﬁrst repo.

Slide 12

Slide 12 text

What is git? DVCS... Distributed Version Control System. What does that mean?

Slide 13

Slide 13 text

Your Favorite Package Manager Homebrew Apt or... First, let’s install git. If you use a Mac or Linux machine, it’s pretty straightforward. “brew install git” or “sudo apt-get install git” should get you up and running.

Slide 14

Slide 14 text

git-scm.org/download If you don’t use a package manager (though you should), just grab git from the download page at git-scm.org. They have packages for Mac, Linux, and Windows.

Slide 15

Slide 15 text

Keeping Things Organized Keep everything in one place.

Slide 16

Slide 16 text

~/git ➜ ~ mkdir git ➜ ~ cd git Git directory in your home folder. You really don’t want a mess of repos all over your machine, or having to search for a repo when you need to work on a project.

Slide 17

Slide 17 text

Initialize the Repository ➜ git git init myproject or ➜ git cd myproject ➜ myproject git init Two ways. New project or existing project. The top one creates an empty directory with a .git folder in it. The bottom one creates a .git folder in the current directory.

Slide 18

Slide 18 text

What... That’s it? The .git folder is where all the magic happens. Remember how everything in a DVCS is available to every repository. It’s all stored in that .git folder.

Slide 19

Slide 19 text

Undoing the Initialization If you’d like to remove a project on your system from git version control, just delete the .git folder inside your project. You may have to show hidden folder to see it, but that’s all there is to it.

Slide 20

Slide 20 text

? Stop for questions.

Slide 21

Slide 21 text

Committing

Slide 22

Slide 22 text

What is a commit? I like to think of a commit as a snapshot. It saves your code at a particular point in time. You can then go back and view your code at any committed point in time. There are more technical details behind it, but you don’t need to know about those to use git. (Talk to me after if you’d like.)

Slide 23

Slide 23 text

Initial Commit ➜ myproject git status ➜ myproject git add . ➜ myproject git commit -m “Initial Commit” “git status” is a command you should use a lot. It let’s you see what state git is in. “git add .” adds all the new ﬁles. The “.” is kinda like a wildcard. You can also specify a particular ﬁle. “git commit -m ‘message’” is a short hand for making a commit and including the message inline. Without -m and a message, it will pop up a text editor and ask for the commit message.

Slide 24

Slide 24 text

Making More Commits ➜ myproject git status ➜ myproject git add . ➜ myproject git commit -m “Fix issue #1337 with awesome code” You essentially repeat the same loop for each commit.

Slide 25

Slide 25 text

What Makes a Good Commit Message? The convention is to use present tense. Ideally, since most people work with git in a terminal, it’s best to keep the title short. (72 characters, if you’re counting.) If you need a really long message, just do...

Slide 26

Slide 26 text

➜ myproject git commit Unless you’ve setup a separate editor to use with git, you’ll be met by vim. Don’t worry. It doesn’t bite. Press “I” to go into insert mode, type out your title in the ﬁrst line, then type a longer message on the lines below that. Don’t worry about all the commented stuff, git ignores it.

Slide 27

Slide 27 text

But... I Don’t Want to Use Vim. ➜ myproject git config --global core.editor mate You can use a conﬁg option to set some other text editor. Any plain text editor will do. Here, I’ve indicated mate, or textmate2. You can use whatever you’d like though.

Slide 28

Slide 28 text

? Stop for questions.

Slide 29

Slide 29 text

Reviewing History The whole point of keeping things in version control is so that you can review history. The key part of git you’ll use for that is the “git log”.

Slide 30

Slide 30 text

Git Log ➜ myproject git log commit 594ea872e95326dfe4c1f9412043af1d9860ac1c Author: Jared Koumentis Date: Mon Jan 7 01:56:54 2013 -0500 finish copy and standardize email button color When you do a git log on a project with any signiﬁcant amount of history, you’ll see a bunch of entries like this. Let’s break this down.

Slide 31

Slide 31 text

Git Log ➜ myproject git log commit 594ea872e95326dfe4c1f9412043af1d9860ac1c Author: Jared Koumentis Date: Mon Jan 7 01:56:54 2013 -0500 finish copy and standardize email button color This long string of characters is the commit hash. It’s a unique identiﬁer for this particular commit.

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Adding Some Color to Your Logs

Slide 36

Slide 36 text

➜ myproject git config --global color.ui true This little command colorizes more than just your logs, but it’s a good thing to have on if you’d like colors.

Slide 37

Slide 37 text

Turns This... commit 594ea872e95326dfe4c1f9412043af1d9860ac1c Author: Jared Koumentis Date: Mon Jan 7 01:56:54 2013 -0500 finish copy and standardize email button color It turns this...

Slide 38

Slide 38 text

Into This... commit 594ea872e95326dfe4c1f9412043af1d9860ac1c Author: Jared Koumentis Date: Mon Jan 7 01:56:54 2013 -0500 finish copy and standardize email button color

Slide 39

Slide 39 text

Not So Exciting... That’s not so exciting, so let’s see what else we can do.

Slide 40

Slide 40 text

➜ myproject git log --online Gives Us... 594ea87 finish copy and standardize email button color We have a --online option, if we’d like something a little less verbose.

Slide 41

Slide 41 text

But... I Need to Know MORE!

Slide 42

Slide 42 text

➜ myproject git log --patch Gives Us...

Slide 43

Slide 43 text

It’s pretty simple. Red is a removal. Green is an addition. However, it shows whole lines that changed... I wonder if we can make this even easier to read.

Slide 44

Slide 44 text

➜ myproject git log --patch --color-words Gives Us...

Slide 45

Slide 45 text

There... adding --color-words makes it so we can easily see which little chunk changed.

Slide 46

Slide 46 text

? Stop for questions.

Slide 47

Slide 47 text

Branching Branching - When and Why.

Slide 48

Slide 48 text

When Should I Branch? I’ve been asked this many times by people. If you’re coming from a centralized version control system, like SVN, branching isn’t something you’re used to doing. However, in git, it’s a common practice.

Slide 49

Slide 49 text

You Should Branch... ALL the Time For ALL the Things Any time you’re adding a feature, ﬁxing a bug, updating copy, ﬁxing a spelling error... Always branch. Why?

Slide 50

Slide 50 text

Pull Requests Pull Requests are kinda like asynchronous awesome code review. Supported by both GitHub and BitBucket, you make a branch, do your changes, and then publish your branch. I’m going to make you wait though. We’ll cover this right after branching.

Slide 51

Slide 51 text

➜ myproject git branch my_branch ➜ myproject git checkout my_branch Or... ➜ myproject git checkout -b my_branch To create a new branch, use the “git branch” command. You can then checkout that branch. If you’re wanting to create and checkout a new branch right away, doing a “checkout -b” will get that done immediately. Checkout can be used to move between branches.

Slide 52

Slide 52 text

Do Your Work Make Small Commits Since you’ve made a branch, you’re essentially working in your own sandbox, separate from the “Master” branch of your copy of the code. Feel free to experiment. Commit early and often. Preferable, commit with every little “unit” of work that you do with your code. That way, you’ve got a nice history explaining why you’ve made the changes you have.

Slide 53

Slide 53 text

? Stop for questions.

Slide 54

Slide 54 text

Sharing Your Repository Sharing your repository with others. Setting up a git remote. Making your ﬁrst push. Collaborating with Pull Requests.

Slide 55

Slide 55 text

GitHub BitBucket github.com bitbucket.org The two big players in git hosting. There are numerous smaller ones, however, these two are the ones most people use. Their main differences are in their pricing models. If you’re looking to do open source work, GitHub is probably the best option. If you’re looking to integrate into other Atlassian tools you use, BitBucket is probably better.

Slide 56

Slide 56 text

The Most Important Part?

Slide 57

Slide 57 text

The Most Important Part? They Both Support Pull Requests.

Slide 58

Slide 58 text

Setting Up A Git Remote Regardless of which service you use for hosting your git repositories, adding a git remote to your local git repo is easy.

Slide 59

Slide 59 text

➜ myproject git remote add

Slide 60

Slide 60 text

➜ myproject git remote add Anything You Want You can set the name to be anything you want. I’d suggest it be a short and easy to remember name, as you’ll be using it a lot.

Slide 61

Slide 61 text

➜ myproject git remote add Your Host Gives You This The URL will be something you get from your host.

Slide 62

Slide 62 text

➜ myproject git remote add origin Origin is the standard name used for your “point of truth” repo. Most git hosting sites will ask you to set them up as “origin”, though you can make it any name you’d like.

Slide 63

Slide 63 text

Forking Many people have heard of forking. Forking, when talking about open source projects, was often a bad thing, in the past. It meant that the group working on the project had decided to go in different directions. Forking sometimes corresponded with the death of the original project.

Slide 64

Slide 64 text

Forking No Longer A Bad Thing Many people have heard of forking. Forking, when talking about open source projects, was often a bad thing, in the past. It meant that the group working on the project had decided to go in different directions. Forking sometimes corresponded with the death of the original project.

Slide 65

Slide 65 text

What is a Fork? A fork is like a server side copy of a repo. It’s used when a person would like their own sandbox that they can push changes to.

Slide 66

Slide 66 text

Fork + Pull Request = Awesome You see, with a fork, you can make your changes on a branch, like we talked about before. Then, you can submit a pull request back to the original project. The key is that this make Forking a project a positive thing. Forking is good when you contribute back to the original project.

Slide 67

Slide 67 text

Get Your Code Online. Share. Whether you use GitHub or BitBucket, getting your code online and letting people fork and submit pull requests will help you develop a community. Also, as they say, many eyes make for shallow bugs.

Slide 68

Slide 68 text

➜ myproject git remote add origin ➜ myproject git push -u origin master --all This is all you need to publish your code. Each service out there will help lead you through these steps. Let’s break down what’s happening.

Slide 69

Slide 69 text

➜ myproject git remote add origin ➜ myproject git push -u origin master --all The -u option tells git to “track the upstream” branch. Basically, in the future, when you do a plain “git push” and you’re on the master branch, it knows you want to push to the master branch.

Slide 70

Slide 70 text

➜ myproject git remote add origin ➜ myproject git push -u origin master --all We’ve already seen the origin name, as that’s the short hand for our server. This “master” bit here is saying we want to push to the master branch.

Slide 71

Slide 71 text

➜ myproject git remote add origin ➜ myproject git push -u origin master --all Last but not least, this --all tells git to push everything we’ve got up there. This makes sure that your initial push includes all the stuff you might want to share with other people. If you don’t want ALL the things pushed, you can leave this out and it will only push your master branch.

Slide 72

Slide 72 text

➜ myproject git push origin Publishing a Branch If you’ve been working on a feature branch (like you should be doing), you can then push that branch up to your server with this.

Slide 73

Slide 73 text

But... Why Publish A Branch? Why would you want to do this? Once you publish a branch, you can submit a pull request from that branch to the master branch.

Slide 74

Slide 74 text

Forking + Branch + Pull Request Branch + Pull Request

Slide 75

Slide 75 text

Forking + Branch + Pull Request Branch + Pull Request Do this if you don’t have push access to the original repo.

Slide 76

Slide 76 text

Forking + Branch + Pull Request Branch + Pull Request Do this if you do have access to the original repo.