to a file or set of files over time so that you can recall specific versions later. Any type of file on a computer can be placed under version control. Think Dropbox but with a whole lot more control.
back to a previous state • Revert the entire project back to a previous state • Review changes made over time • See who last modified something that might be causing a problem • See who introduced an issue and when Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
• Centralized Version Control Systems (CVCSs) Examples: CVS, Subversion Single point of failure in the centralized server • Distributed Version Control Systems (DVCSs) Examples: Git, Mercurial Fully mirrored repository Nearly every operation is local since you have a copy of the entire repository
Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. Working Directory: A single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. Staging Area: A simple file, generally contained in your Git directory, that stores information about what will go into your next commit.
directory. 2. You stage the files, adding snapshots of them to your staging area. 3. You perform a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around: $ git config --global user.name "John Doe" $ git config --global user.email [email protected] If you want to check your settings, you can use the git config --list command to list all the settings Git can find at that point:
service, but it adds many of its own features. While Git is a command line tool, GitHub provides a Web- based graphical interface. It also provides access control and several collaboration features, such as a wikis and basic task management tools for every project.
“forking” – copying a repository from one user’s account to another. This enables you to take a project that you don’t have write access to and modify it under your own account. If you make changes you’d like to share, you can send a notification called a “pull request” to the original owner. That user can then, with a click of a button, merge the changes found in your repo with the original repo.
request and merge – are what make GitHub so powerful. Before GitHub, if you wanted to contribute to an open source project you had to: • Manually download the project’s source code • Make your changes locally • Create a list of changes called a “patch” • E-mail the patch to the project’s maintainer The maintainer would then have to evaluate this patch, possibly sent by a total stranger, and decide whether to merge the changes.
starts to play a role in GitHub... When you submit a pull request, the project’s maintainer can see your profile, which includes all of your contributions on GitHub. If your patch is accepted, you get credit on the original site, and it shows up in your profile. It’s like a resume that helps the maintainer determine your reputation. The more people and projects on GitHub, the better idea picture a project maintainer can get of potential contributors. Patches can also be publicly discussed.
directory Creates a repository skeleton git clone [url] Cloning an existing repository Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything.
git add [file name] To begin tracking a new file. If it's a folder, all files are added recursively you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved git diff What have you changed but not yet staged? And what have you staged that you are about to commit? git diff shows you the exact lines added and removed — the patch, as it were.
unstaged — any files you have created or modified that you haven’t run git add on since you edited them — won’t go into this commit. You can type your commit message inline with the commit command by specifying it after a -m flag, like this: git commit -m "Story 182: Fix benchmarks for speed" Skipping the staging area (skip the git add part): git commit -a -m 'added new benchmarks'
you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around. git log View the commit history. Lots of switches available. git log -p: Shows the diff introduced Using gitk as a visual git log tool
the main line of development and continue to do work without messing with that main line The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Visual tutorial:
ianlukekane
meihei3
kawaguti
kazuya_araki_tokyo
colopl
databricksjapan
yutakikai
masahirokawahara
thomasvitale
kkato1
sansantech
cybozuinsideout
soudai
carmenintech
brad_frost
jrom
aleyda
pauljervisheath
yeseniaperezcruz
lara
ddemaree
chrislema
destraynor
scottboms
erikaheidi
