New Feature: Playlist Center! Pick a topic and let our playlists guide the way.

Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member

About distributed version control

From: Git Essential Training

Video: About distributed version control

In this movie I want to explain what Distributed Version Control means so we can understand why this is such an important feature of Git. In the previous movie where we looked at the history of version control systems, we talked about SCSS, RCS, CVS, and SVN, four of the most popular version control systems of the past. And all four of these use a central code repository model, that is that there is one central place where you store the master copy of your code, and when you're working with the code you check out a copy from the master repository. You work with it make your changes, and then you submit those changes back to the central repository.

About distributed version control

In this movie I want to explain what Distributed Version Control means so we can understand why this is such an important feature of Git. In the previous movie where we looked at the history of version control systems, we talked about SCSS, RCS, CVS, and SVN, four of the most popular version control systems of the past. And all four of these use a central code repository model, that is that there is one central place where you store the master copy of your code, and when you're working with the code you check out a copy from the master repository. You work with it make your changes, and then you submit those changes back to the central repository.

Other users can also work from that repository submitting their changes. And it's up to us as users to keep up-to-date with whatever is happening in that central code repository, to make sure that we pull down and update any changes that other people have made. Git doesn't work that way, Git is Distributed Version Control, different users --or teams of users--each maintain their own repositories instead of working from a central repository. And the changes are stored as change sets or patches, and we're focused on tracking changes not the versions of the document.

Now that's a subtle difference, you may think, well, CVS and SVN those track changes too, they don't. They track the changes that it takes to Git from version-to-version of each of the different files or the different states of a directory. Git doesn't work that way, Git really focuses on these change sets in encapsulating a change set as a discrete unit and then those change sets can be exchanged between repositories. We're not trying to keep up-to-date with the latest version of something instead the question is, do we have a change set applied or not? So there is no single master repository, there is just many working copies each with their own combination of change sets. Let me give an illustration to make this clear.

Imagine that we have changes to a single document as sets A, B, C, D, E, and F, we're just going to give them arbitrary letter names so that we can help see it. We could have a first repository that has all six of those change sets in it. We can have repository 2 that only has four of those changes in it. It's not that it's behind repository 1 or that it needs to be brought up-to-date, it's just simply that it doesn't have the same change sets. We can have repository 3 that has A, B, C, and E, and repository 4 that has A, B, E, and F.

No one of these is right and no one of these is wrong. None of them is the master repository and the others are somehow out-of-date or out of sync with it. They all are just different repositories that happened to have different change sets in them. We could just as easily add change set G to repository 3, and then we could share it with repository 4 without ever having to go to any kind of central server at all. Whereas with CVS and SVN, for example, you would need to submit those changes to the central server and then people would need to pull down those changes to update their versions of the file.

Now by convention, we often do designate a repository as being a master repository, but that's not built-in to Git, it's not part of the Git architecture, that's just convention, that we say, okay, this is the master one and everyone is going to submit their changes to the master one, we're going to trying all stay in sync from that one or we don't have to. We can actually have three or four different master ones that have different versions, different features in them, and we could all be contributing to those equally and just swapping changes between them. Now because it's distributed that has a couple of advantages, it means that there is no need to communicate with a central server, which makes things faster, and it means that no network access is required to submit our changes, we can work on an airplane, for example.

And there is no single failure point, with CVS and SVN if something goes wrong with that central repository that can be a real showstopper for everyone else who is working off of that central repository. With Git we don't have that problem, everyone can keep working, they've each got their own repository that they are working from, not just a copy that they're trying to keep in sync with a central repository. It also encourages participation in forking of projects, and this is really important in the open source community. Because developers can work independently, they can then make changes, bug fixes, feature improvements, and then submit those back to the project for either inclusion or rejection.

And if you decide you don't like the way that a open source project is going, you can fork it, take it to a completely different direction and say, you know what, I'm going to just make a clean break and make my repository now the one that I'm going to work from, all of my changes will be submitted to there, and I can still pull change sets from the master one into my project whenever I want. But I don't have to, I can go my own way. That becomes a really powerful and flexible feature that's well suited to collaboration between teams especially loose groups of distributed developers like you have in the open source world. Distributed version control is an important part of the Git architecture that you need to keep in mind.

Especially, if you have previous experience with another Version Control System like CVS or SVN. We'll talk a lot more about how Git tracks and merges these change sets as we go forward. For now just make sure that you understand that there is no central repository that we were from, all repositories are considered equal by Git, it's just a matter of whether a repository has change sets in it or doesn't.

Show transcript

This video is part of

Image for Git Essential Training
Git Essential Training

89 video lessons · 27655 viewers

Kevin Skoglund
Author

 
Expand all | Collapse all
  1. 2m 46s
    1. Introduction
      1m 7s
    2. How to use the exercise files
      1m 39s
  2. 20m 24s
    1. Understanding version control
      4m 48s
    2. The history of Git
      7m 58s
    3. About distributed version control
      5m 4s
    4. Who should use Git?
      2m 34s
  3. 26m 12s
    1. Installing Git on a Mac
      3m 44s
    2. Installing Git on Windows
      5m 37s
    3. Installing Git on Linux
      1m 30s
    4. Configuring Git
      7m 29s
    5. Exploring Git auto-completion
      5m 35s
    6. Using Git help
      2m 17s
  4. 15m 49s
    1. Initializing a repository
      1m 58s
    2. Understanding where Git files are stored
      2m 34s
    3. Performing your first commit
      2m 4s
    4. Writing commit messages
      5m 22s
    5. Viewing the commit log
      3m 51s
  5. 17m 44s
    1. Exploring the three-trees architecture
      3m 57s
    2. The Git workflow
      3m 15s
    3. Using hash values (SHA-1)
      4m 7s
    4. Working with the HEAD pointer
      6m 25s
  6. 25m 52s
    1. Adding files
      5m 59s
    2. Editing files
      3m 56s
    3. Viewing changes with diff
      3m 35s
    4. Viewing only staged changes
      2m 28s
    5. Deleting files
      5m 29s
    6. Moving and renaming files
      4m 25s
  7. 19m 18s
    1. Introducing the Explore California web site
      2m 2s
    2. Initializing Git
      3m 48s
    3. Editing the support phone number
      6m 20s
    4. Editing the backpack file name and links
      7m 8s
  8. 38m 45s
    1. Undoing working directory changes
      3m 49s
    2. Unstaging files
      2m 37s
    3. Amending commits
      4m 50s
    4. Retrieving old versions
      4m 7s
    5. Reverting a commit
      3m 12s
    6. Using reset to undo commits
      3m 44s
    7. Demonstrating a soft reset
      4m 8s
    8. Demonstrating a mixed reset
      4m 7s
    9. Demonstrating a hard reset
      5m 8s
    10. Removing untracked files
      3m 3s
  9. 27m 22s
    1. Using .gitignore files
      8m 23s
    2. Understanding what to ignore
      4m 47s
    3. Ignoring files globally
      4m 49s
    4. Ignoring tracked files
      5m 26s
    5. Tracking empty directories
      3m 57s
  10. 26m 51s
    1. Referencing commits
      4m 52s
    2. Exploring tree listings
      3m 46s
    3. Getting more from the commit log
      7m 38s
    4. Viewing commits
      4m 4s
    5. Comparing commits
      6m 31s
  11. 39m 35s
    1. Branching overview
      4m 56s
    2. Viewing and creating branches
      2m 57s
    3. Switching branches
      2m 58s
    4. Creating and switching branches
      4m 53s
    5. Switching branches with uncommitted changes
      3m 26s
    6. Comparing branches
      4m 28s
    7. Renaming branches
      2m 28s
    8. Deleting branches
      4m 18s
    9. Configuring the command prompt to show the branch
      9m 11s
  12. 28m 32s
    1. Merging code
      3m 11s
    2. Using fast-forward merge vs. true merge
      6m 49s
    3. Merging conflicts
      7m 26s
    4. Resolving merge conflicts
      7m 5s
    5. Exploring strategies to reduce merge conflicts
      4m 1s
  13. 14m 34s
    1. Saving changes in the stash
      4m 5s
    2. Viewing stashed changes
      2m 39s
    3. Retrieving stashed changes
      4m 24s
    4. Deleting stashed changes
      3m 26s
  14. 1h 5m
    1. Using local and remote repositories
      6m 38s
    2. Setting up a GitHub account
      5m 39s
    3. Adding a remote repository
      4m 0s
    4. Creating a remote branch
      4m 3s
    5. Cloning a remote repository
      4m 26s
    6. Tracking remote branches
      4m 5s
    7. Pushing changes to a remote repository
      5m 8s
    8. Fetching changes from a remote repository
      5m 47s
    9. Merging in fetched changes
      4m 50s
    10. Checking out remote branches
      3m 22s
    11. Pushing to an updated remote branch
      2m 6s
    12. Deleting a remote branch
      3m 8s
    13. Enabling collaboration
      3m 40s
    14. A collaboration workflow
      8m 43s
  15. 16m 23s
    1. Setting up aliases for common commands
      5m 14s
    2. Using SSH keys for remote login
      2m 56s
    3. Exploring integrated development environments
      1m 4s
    4. Exploring graphical user interfaces
      4m 32s
    5. Understanding Git hosting
      2m 37s
  16. 55s
    1. Goodbye
      55s

Start learning today

Get unlimited access to all courses for just $25/month.

Become a member
Sometimes @lynda teaches me how to use a program and sometimes Lynda.com changes my life forever. @JosefShutter
@lynda lynda.com is an absolute life saver when it comes to learning todays software. Definitely recommend it! #higherlearning @Michael_Caraway
@lynda The best thing online! Your database of courses is great! To the mark and very helpful. Thanks! @ru22more
Got to create something yesterday I never thought I could do. #thanks @lynda @Ngventurella
I really do love @lynda as a learning platform. Never stop learning and developing, it’s probably our greatest gift as a species! @soundslikedavid
@lynda just subscribed to lynda.com all I can say its brilliant join now trust me @ButchSamurai
@lynda is an awesome resource. The membership is priceless if you take advantage of it. @diabetic_techie
One of the best decision I made this year. Buy a 1yr subscription to @lynda @cybercaptive
guys lynda.com (@lynda) is the best. So far I’ve learned Java, principles of OO programming, and now learning about MS project @lucasmitchell
Signed back up to @lynda dot com. I’ve missed it!! Proper geeking out right now! #timetolearn #geek @JayGodbold

Are you sure you want to delete this note?

No

Thanks for signing up.

We’ll send you a confirmation email shortly.


Sign up and receive emails about lynda.com and our online training library:

Here’s our privacy policy with more details about how we handle your information.

Keep up with news, tips, and latest courses with emails from lynda.com.

Sign up and receive emails about lynda.com and our online training library:

Here’s our privacy policy with more details about how we handle your information.

   
submit Lightbox submit clicked
Terms and conditions of use

We've updated our terms and conditions (now called terms of service).Go
Review and accept our updated terms of service.