Introduction To Git
- 2. About Me • Senior at Amador Valley High School • Developer/Designer at Amador Valley DECA • Intern at Phala Data @gsumpsterGeorge Sumpster
- 3. Overview • Version Control Systems • Git Concepts • Using Git • Initial Setup • Initializing a repository • Tracking files • Committing files • Pushing and Pulling • Branching Out & Merging
- 4. Version Control Systems A brief introduction and comparison
- 5. Centralized • Centralized Repository • One Copy on One Server • CVS, SVN Centralized vs. Distributed
- 6. Distributed • Distributed Repository • Every Client has a Copy • Git, Mercurial Centralized vs. Distributed
- 7. Git Concepts A quick overview of version control concepts
- 12. Branches
- 13. Branches
Editor's Notes
- #4: Quick overview of what we’re going to be talking about today, explain the rest two topics will be a lecture of concepts & then we will finally actually setup Git and create a repository!
- #5: So, what is a VCS? Anything that tracks versions, mention file based VCS (final1.psd, finalFORREAL.psd) Why do we use it? Working together, even on the same file. What’s different between versions? The ability to go back in time
- #6: So, there are two types of VCS, centralized and distributed. We’re going to quickly cover both, here, just to give you a quick understanding of both. Centralized VCS systems, are, as the name suggests, centralized. The entire repository is stored on one central server, and the users pull and push to this server. The clients only have what they pull down, they don’t have access to the history of the repository ect. This is the ‘old’ way of doing things, probably quite rare to find a company that does this today. CVS & SVN are both examples of a centralized VCS, both have been around for a really long time and aren’t commonly used today. That said, Facebook does use SVN with some combination of Git.
- #7: So, we just looked at a centralized version control systems, let’s move on to what we typically use today. Distributed VCSs. So, where the client in the centralized model only has a partial copy of the repository, the client in the distributed model has a full copy of the repository, the exact copy that the server has. This includes all of the previous code and means that the client has access to all the abilities that the server in the centralized model had access to.
- #8: OK, so we’re now just going to quickly go through some Git concepts, and just introduce you to what these things mean and how they work together and in what order you ‘use’ these concepts.
- #9: So, within this section, I’m going to combine tracking files, staging said files and then committing. So, tracking a file means that you’ve marked it as a file that should be included in the version control. Now, there are some files that you don’t want included, compiled files typically shouldn’t be included in the repository, nor should dependencies. There’s a file called .gitignore where you can specify what type of files shouldn’t be included. Anyway, so after you’ve tracked a file, you’ve staged it to be added to the next commit. As part of your process of preparing to commit, you should quickly check what files are staged for commit, and add files that should be on there. OK, now we have all our files ready to go, now we commit. As you will see when we acutally do this later, you’ll include a message in your commit that quickly details what you changed in the commit, so for instance, if you had an issue open called issue 52, and you fixed it in this commit, your commit message could be ‘fixed issue 52’.
- #10: So, let’s say you’ve done some work on your project and made a few commits and now you’re ready to push your project to, Github for example