Class 2: HTML, Source Control, and Git

Notes for 5/16/2013

Transcript

1. HTML, Source Control, and Git Class Two: May 16, 2013
2. The  First  Website
3. HTML:  Hyper  Text  Markup   Language • HTML  is  a  “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.
4. Sad  Al  Gore  is  Sad
5. THX  TIM,  I  LUV  MAH  INTERNET!
6. HTTP,  a  la  Wikipedia • HTTP  func@ons  as  a  request-­‐response  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.
7. Version  Control • Version  control  is  a  system  that  records  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.
8. Methods  of  Source  Control •Copy/Paste:  Move  to  another  Directory •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  opera@on  is  local  since  you  have  a  copy  of  the   en@re  repository
9. Centralized  Version  Control   Systems
10. Distributed  Version  Control   Systems
11. Version  Control  Systems  and  Time • A  VCS,  with  a  set  of  files  and  the  changes  made  to   each  file  over  @me
12. Git  and  Time  (Snapshots,  not   Differences) • Git,  data  as  a  set  of  snapshots • A1  is  not  stored  again  in  Version  3  since  it  hasn't   changed.
13. Linus  Torvalds,  Presumably  HaRng  on   the  Haters
14. Git:  What’s  the  Benefit? •No  single  point  of  failure •You  can  work  when  offline  (no  need  to  contact  remote   server  for  info) •It's  very  difficult  to  lose  data
15. Git:  The  Three  States •Commi%ed:  Stored  in  your  local  database •Modified:  Changed  but  not  commi;ed  to  your   database •Staged:  Marked  a  modified  file  in  its  current  version  to   go  into  your  next  commit  snapshot
16. Git:  Three  Main  SecRons  of  a   Project •Git  Directory:  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.
17. Git:  Basic  Workflow 1. You  modify  files  in  your  working  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.
18. Git:  Basic  Workflow
19. Git:  Your  IdenRty • The  first  thing  you  should  do  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  johndoe@example.com • 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:
20. Github:  Octocat
21. Github:  What  is  it? • GitHub  is  a  Git  repository  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.
22. Github:  What  is  it? • These  three  features  –  fork,  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.