Git Basics

If you’re serious about pursuing a career as a software developer or designer, at some point, you will need to learn a version control system. A VCS is an important, but sometimes overlooked, tool that is essential for keeping all but the most trivial projects on track. In this course we'll talk about what version control is and how it works before covering the basics of one of the most popular version control systems available today - Git. By the time you’re finished with the course, you’ll be ready to start using Git on your next project

What you'll learn

• What Version Control Does
• How Version Control Works
• What Makes Git a Good Choice
• Using Git to Manage Basic Projects
• Working With GitHub and other Git Hosting Solutions

Why Version Control Matters

One of the most essential tools a developer can master is version control, and one of the most widely-used version control systems available today is Git. But what makes Git popular? And why should you learn to use version control anyway? In this stage we’ll explore all the benefits of using version control (including: helping you deal with changing requirements, data loss, sharing and collaborating with others), as well as the qualities of Git that make it such a popular choice in the modern development world.

• Introduction to Git Basics1:37
• Life Without Version Control5:35
• The Cowboy Coder's Code Corral5 questions
• How Version Control Works4:21
• Why Git?4:28
• Version Control Review10 questions

• Extra Credit

  Other Version Control Systems

  We talked a bit about what makes Git a good VCS, but we didn’t talk about any other VCSes specifically. If you’re curious about what else is out there, do an internet search - find out what other VCSes exist, and see how they compare to Git. Do you think we made a good choice with Git, or would you rather learn something else? Don’t assume that just because we like Git that it’s the right choice for you - once you have the basics down, feel free to experiment.

  I Thought Cowboys Were Heroes?

  We introduced the concept of a “Cowboy Coder” as someone who doesn’t follow best practices - in this case, someone who doesn’t use a VCS in their projects. There are a lot of other ways to be a Cowboy Coder, though, and if you’re at a point in your learning that you’re thinking seriously about version control, some of the other best practices out there might be important to you as well. Look around online for some stories about Cowboy Coders and the problems that they may have caused for people in their projects or companies. What can we learn from those experiences? When do you think it might be okay to act like a Cowboy Coder? Do you think we're wrong as a community to treat this as a bad approach to working on software? Start (or participate in) a discussion in the forums with what you learn.

  Even More Reasons to Use Version Control

  We talked a lot about the advantages of using a VCS, but we simply didn’t have time to go over every situation where having a VCS is beneficial. Think about the benefits that we’ve already talked about and reflect on your own experience working on projects - can you think of any other potential benefits that we didn’t cover in this lesson?

Getting Started With Git

So you understand what version control is, why you should use it, and why Git is a good VCS to learn. Great! Let’s get started. In this stage we’ll start playing with Git repositories and learn the basics of storing our changes.

• Git Ready1:02
• Working With Git Repositories4:33
• Repository Basics3 objectives
• Committing Changes6:40
• Commitment Therapy3 objectives
• The Staging Area5:39
• Staging Our Changes6 objectives
• Looking Back on What We've Done6:24
• An Old-Fashioned Git-Together11 objectives

• Extra Credit

  Even More Control

  In this stage we learned thatgit addcould add all the changes in a file to the staging area, which is really useful most of the time. Can you picture a scenario where you might only want to stage_part_of a file, though? If so, how do you think you might accomplish that? Try searching online or checking out the man page for git add (man git-add) and see if you can figure it out - it's a nice trick to have handy when you need it.

  Is the Staging Area Worth the Effort?

  The staging area adds an extra step to the process of committing your changes - do you think it provides enough benefit to be worth it? Do some research and see if you agree with the opinions people provide about the usefulness or unnecessary nature of the staging area. What version control systems_don't_have a staging area concept? How do they handle the commit process? Do you think that's better than Git's approach?

  Git Configuration

  We made a quick configuration change to update my email address and name, so that Git would know who to associate my commits with. That's not all that we can configure in Git, though. What other stuff do you think you might want to change? A lot of people share their .gitconfig file online (which is the file that thegit configcommand edits) - see if you can find some. You may not know everything you need to know in order to understand a lot of the configuration options, but try to figure out what they do - are there any that look interesting? Do you think this kind of configurability is a good thing or a bad thing? Share any tips or tricks you find in theforum.

Branches

Now that we know the basics of using Git, let’s look at a very important concept in Version Control: Branching. Branching allows you to conveniently work on multiple versions of your code at once, and Git makes branching really easy.

• Branching Out2:00
• Beginning to Branch5:55
• Out on a Branch5 objectives
• Managing Our Branches1:44
• Branch Manager2 objectives

• Extra Credit

  The Versatility of the "git branch" Command

  We've covered a lot of uses for thegit branchcommand, but there were a few things we didn't look at in this stage. Here are a few suggestions for you to research:

  1. We used the git branch -D argument to delete a branch, but it turns out you can also delete branches with git branch -d
     • what's the difference between these two? Here s a hint - it has something to do with the next stage on Merging.
  2. How would you rename a branch? There are actually two different ways you can do this using the git branch command - what are they? What's the difference between them? Between this and the first question, are you noticing a pattern in how flags work for git commands?
  3. Consider a scenario where you get an email from a coworker, and they have a question for you about commit 50d3cb (remember that git commit identifiers look unfriendly because they're virtually guaranteed to be unique). You made the commit, but you don't remember what branch it's on, and your coworker neglected to mention that. You could ask them, but there's a quicker way to find out using the git branch command - see if you can find out how that works.

Merging

You might be working on multiple different branches of your code at once, but in most cases you’ll only have one final version of your product that will incorporate the changes from all of those branches. Now that we’ve branched out our code, how do we get all of those changes back together? Most version control systems provide a concept called merging that lets us combine our changes together.

• Introduction to Merging2:47
• Basic Merging3:48
• Simple Merges4 objectives
• Merge Conflicts4:23
• Conflict Resolution2 objectives

• Extra Credit

  Merge Commits: Waste of Space?

  Running a regular merge means that you always end up with that special "merge" commit. Is that a good thing? Some people think that it makes for a "dirty" project history, and would rather just have all of the commits in the order that they're applied. This can be done with a technique called "rebasing" - do some research to find out what rebasing is and how it works. After you think you've got a handle on it - do you think that it's a good idea to always rebase?

  Selfish Merging

  Sometimes when you merge, you don't want to be clever about handling merge conflicts - for example, if you're working on a new redesign of a website, for example, you probably don't care about any changes that were made to the current design recently. In that case, whenever you ran agit merge, you might want to try to automatically just preserve_your_set of changes whenever there's a conflict. Does git provide a way for you to do that? If so, what situations can you think of where it would be a good idea? Can you think of any situations where it could be harmful?

  Other Merging Tactics

  I mentioned in the video that manually editing conflicted files was only one way to resolve merge conflicts - can you find out what some of the other ways are? Do you think you'd prefer those other ways over the manual approach we covered in this lesson? Why or why not?

Working With Remote Repositories

Version control systems are useful for working on personal projects, but where they really shine is when you use them to collaborate with others. The most common path for working with others is to store copies of your repositories remotely, and Git provides us with a set of tools we can use to interact with those remote repositories.

• Working With Remotes3:01
• Remote Concepts5 questions
• Cloning4:55
• Pushing and Pulling8:20
• Remote Work4 objectives
• GitHub10:02
• Hosting Help5 questions

• Extra Credit

  Share Your Work

  Are you working on any cool projects you'd like to show off? Get them up onGitHubForum! When they're there, you can show them off in the appropriate section of the.

  Become an Open Source Contributor

  Have you been practicing your software skills, whether as a developer or a designer? One great way to hone your skillset and earn a reputation at the same time is to help out with open source projects - as you might guess from our little walkthrough,GitHubmakes this process really easy. Look around on GitHub for any exciting open-source projects and find out if there's anything you can do to help - if there is, try to help out! Submit a pull request. Just be sure to follow any rules the project maintainer has set out, and don't get discouraged if the response is less than positive - not everyone on the internet is nice. Just keep at it until you find a spot where you can contribute, and remember that it might take you a little while to learn the ins-and-outs of the open source community.

  Not sure where to start? Services likeCodeTriageOpenHatch,LookingForPullRequestsandcan help you find places to contribute.

Workflows

Now that we know all the basic tools for managing projects with Git, it's time to put them all together. Let's take a look at how all the tools and ideas we've learned so far work together to make version control an important part of the day-to-day process of working on a project, and talk about some of the common ideas about "best practices" for using Git.

• A Day in the Life of a Git Project4:44
• Workflow Puzzles5 questions
• Git-Flow6:32
• Using Git-Flow4 objectives

• Extra Credit

  Find a Workflow that Works for You

  In this section, we covered a couple different ideas about how to organize your repositories and think about your work. These certainly aren't the only ideas on the matter, though, and it's important that you find something that works for you. Experiment with Feature Branches and git-flow. What do you like/dislike about each of them? Search the web - do others share your thoughts? Have they proposed solutions? The most important part about a workflow is that it maps to how you (and the people you work with) think about getting things done, so be sure to take some time and figure out how_you_would like to work.

  Use What You've Learned

  Go use Git! The next time you sit down to learn something at Treehouse, start a project to follow along with what you're learning, and use your newfound Git skills to maintain the project along the way. You can even share a copy up onGitHubForum(remember, it's free for public projects) and tell us how it all went on the. It may take a little while for you to get totally comfortable using Git, but with practice everything you just learned here at Treehouse will become second nature.

  Try Out Other Interfaces for Git

  In this course we've exclusively made use of Git's command-line interface, because this is readily available and it exposes you directly to most of the core concepts that make Git a good VCS. That said, there are obviously other tools you can use to manage Git repositories. Experiment with them, and try to figure out what works best for you - do you prefer having a graphical user interface to help you visualize what's going on in your repositories, or do you like the simplicity and flexibility of working in the command-line client? Are there any tools or plugins you'd like to use to extend the core Git functionality in a way that better fits your workflow?

  Keep Learning

  Go learn new things! We only covered the very basics of working with Git, and there are many other tools and tips out there for how to use Git to make your work even more awesome. To get you started, here's aquick video I did on one of my favorites: git stash. http://teamtreehouse.com/library/treehouse-quick-tips/git-stashing