Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
You can do a lot with Git. Let's go over the terminology you'll want to know and basic actions you'll need to take, when implementing Git as your version control system.
-
0:00
Now that you know how important version control is and
-
0:02
how fundamental Git is to development, let's focus on the first level tasks and
-
0:06
terminology you'll need to know.
-
0:08
To begin with, Git projects are known as repositories or repos.
-
0:14
Simply put,
-
0:14
repositories contain all of the project files as well as their revision history.
-
0:19
You can think of them as a folder that holds the whole project over time.
-
0:24
Repos can be yours alone, or shared with others.
-
0:27
Repos house on GitHub can either be private, as in invitation only, or
-
0:31
public for all GitHub users to see.
-
0:34
Unless you have a good reason to keep your repos private, like proprietary concerns,
-
0:38
you should just begin with public repos, as there's no charge on GitHub.
-
0:42
Private access comes with a fee.
-
0:44
To begin working on a repository,
-
0:46
you will clone a copy on your system or check it out as we'll show you in Xcode.
-
0:51
When you make changes to the project, you'll usually want to save them and
-
0:55
that's called making a commit.
-
0:57
A commit is one or more changes to one or more files.
-
1:00
Commits are accompanied by a brief commit message from the user,
-
1:03
as well as an optional description, which can be longer.
-
1:06
Every time a commit is made, a unique ID hash or SHA is created so
-
1:11
we know which changes were committed when and by whom.
-
1:15
Now mind you, you probably won't want to commit every little thing you try out.
-
1:19
But when it's something that might be worth preserving for the future,
-
1:22
that should be committed.
-
1:24
Most often, you'll have a remote copy of the repository housed on GitHub and
-
1:28
a local copy on your machine.
-
1:30
When you push, you're sending your local committed changes to the remote repo.
-
1:35
When you pull, you're getting changes from the remote repo and
-
1:39
simultaneously merging them into your local copy.
-
1:43
It's worth highlighting that distinction.
-
1:45
When I push my changes to a remote repository, it won't automatically merge
-
1:49
into everyone else's active branch unless they decide to pull the changes.
-
1:54
However, when pulling, the merge happens at the same time.
-
1:57
I'll talk more about merges in a minute but
-
1:59
they're pretty much what you would expect.
-
2:03
A branch is a parallel version of a repo.
-
2:06
It's actually housed within the repo itself, but
-
2:09
when you change it, it doesn't affect other branches.
-
2:11
The main branch is most often referred to as the master branch.
-
2:15
And the latest commit is known as the tip of the branch.
-
2:19
You can have as many branches as you want and
-
2:21
it's often a good idea to create new branches for new features.
-
2:24
Though be sure to name them descriptively, keep them tidy, and
-
2:27
merge back in when appropriate.
-
2:29
Having too many branches can quickly become a huge mess.
-
2:33
A merge is when you take the changes from one branch and insert them into another.
-
2:37
A merge can happen automatically, like when you pull, or
-
2:40
by explicitly merging one branch into another.
-
2:43
You may also have heard the term pull request,
-
2:46
which is essentially a request to merge your code in.
-
2:50
By the way, Git doesn't simply overwrite one whole file with another,
-
2:54
rather it sees only what has changed and decides which changes to keep.
-
2:58
When Git can't figure that out on its own you get a merge conflict and
-
3:02
you'll need to resolve that manually, by deciding which code to keep.
-
3:06
Sometimes it will just be one or the other.
-
3:08
Sometimes a mix of the two.
-
3:10
A diff is simply the difference between two commits.
-
3:14
When you view a diff, you can see what has been removed, added or
-
3:17
changed since the previous or other commit.
-
3:21
A gitignore is a file that tells Git to intentionally exclude certain files or
-
3:25
folders from tracking.
-
3:27
You don't have to use gitignore, but it can be helpful if you don't
-
3:30
want to track certain user settings, large assets, things like that.
-
3:34
I've included a link below that goes into lots more details on gitignore.
-
3:38
And just as a reminder, Git is the open source program for tracking changes.
-
3:43
GitHub is the social and user interface which uses Git as its primary machinery.
-
3:49
Join me in the next video where we'll put all that I mentioned into action when we
-
3:53
create a GitHub account and start working with repos for a real live Xcode project.
You need to sign up for Treehouse in order to download course files.
Sign up