“markup language” that tells how a webpage should be forma;ed. • A web browser is capable of reques@ng a page from a web server and interpre@ng the results. • Tim Berners-‐Lee is the inventor of the Web. In 1989, Tim was working in a compu@ng services sec@on of CERN when he came up with the concept; at the @me he had no idea that it would be implemented on such an enormous scale. Par@cle physics research oQen involves collabora@on among ins@tutes from all over the world. Tim had the idea of enabling researchers from remote sites in the world to organize and pool together informa@on. But far from simply making available a large number of research documents as files that could be downloaded to individual computers, he suggested that you could actually link the text in the files themselves • A chapter on the history of HTML, if interested.
protocol in the client-‐server compu@ng model. A web browser, for example, may be the client and an applica@on running on a computer hos@ng a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other func@ons on behalf of the client, returns a response message to the client. The response contains comple@on status informa@on about the request and may also contain requested content in its message body.
changes to a file or set of files over @me so that you can recall specific versions later. • Any type of file on a computer can be placed under version control. • A Version Control System (VCS) allows you to: revert files back to a previous state, revert the en@re project back to a previous state, review changes made over @me, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addi@on, you get all this for very li;le overhead.
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 opera@on is local since you have a copy of the en@re repository
Where 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 informa@on 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.
when you install Git is to set your user name and e-‐mail address. This is important because every Git commit uses this informa@on, 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 sekngs, you can use the git config -‐-‐ list command to list all the sekngs Git can find at that point:
hos@ng 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 collabora@on features, such as a wikis and basic task management tools for every project. • The flagship func@onality of GitHub is “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 no@fica@on called a “pull request” to the original owner. That user can then, with a click of a bu;on, merge the changes found in your repo with the original repo.
pull 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” and then 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. • This is where the network effect 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 contribu@ons 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 reputa@on. The more people and projects on GitHub, the be;er idea picture a project maintainer can get of poten@al contributors. Patches can also be publicly discussed.
ianlukekane
visional_engineering_and_design
aki_iinuma
codmoninc
shirouz
riyaamemiya
takumiengineering
masasuzu
sonoda_mj
asonas
fujiwara3
oracle4engineer
moznion
cassininazir
mayunak
reverentgeek
andyhume
marktimemedia
honzajavorek
holman
smashingmag
rkendrick25
productmarketing
tanoku
csswizardry
