Skip to content

Instantly share code, notes, and snippets.

@rsgranne
Last active March 30, 2018 15:54
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rsgranne/8fd0cbb248368e374a3e3593677acff2 to your computer and use it in GitHub Desktop.
Save rsgranne/8fd0cbb248368e374a3e3593677acff2 to your computer and use it in GitHub Desktop.
Git instructions for students in Webster University’s Cascading Style Sheets course
  • IMPORTANT
    • Type EXACTLY what I type! (The James Taylor Rule)
    • If you are confused, let me know ASAP
  • Intro
    • VCS
      • Version Control System (VCS) manages changes to your files
      • Tracks every change to a project’s code & who made the changes
    • History of Revision Control
      • Copy project & give it a new name: v1, v2, v3
        • Mis-label? Overwrite files? What’s changed? When? By whom?
      • Local VCS
        • Store all files in a db
        • Checked out a file you want to work on
        • No way to share code
      • Centralized VCS
        • Store all files in a db on a server
        • Developers check out files & save them back in to the project
        • Several developers can collaborate on a project
        • How do multiple users work on same files at same time? Who’s changes get accepted?
        • If changes conflict, someone manually merges the differences
      • Distributed VCS
        • Every developer gets her own copy of the project
        • Each developer works on whatever he wants & merges when he thinks it’s time
        • Easier to share code, merge conflicts, & experiment with code
        • Git is a DVCS
    • Development of Git
      • In 2002, Linus Torvalds, creator & leader of Linux kernel developers, started making developers use BitKeeper, a closed-source DVCS owned by his buddy Larry McVoy
      • In 2005, McVoy changed licensing terms so open source developers could no longer get free licenses
      • Developers revolted against Linus, threatening a Linux kernel fork
      • April 3, 2005: Linus begins developing Git
      • June 16, 2005: Git manages the Linux kernel
  • Installation
    • git is really a command line tool
    • Command Line
      • Only need to do this if you’re not using Sourcetree or another GUI tool, as most of those provide the command line version
      • macOS
        • Open Terminal (or iTerm) & enter the following:
          • xcode-select --install
          • OR git
        • Go to https://developer.apple.com/downloads/more, enter your Apple ID, & download & install
        • Verify it’s installed:
          • $ xcode-select -p /Library/Developer/CommandLineTools
      • Windows
    • GUI (Sourcetree by Atlassian)
    • A place for your repos
      • ~/Documents/Git/
      • ~/Documents/Web Dev Projects/
        • You’ll just need to remember which projects use Git & which don’t
  • GitHub
    • Web-based Git repository launched in 2008
    • Provides access control & collaboration features for every project: e.g., bug tracking, feature requests, task management, & wikis
    • April 2016: 14 million users & 35 million repositories
    • Largest host of source code in the world
    • Pricing
    • Create a free GitHub account at http://github.com
    • Sign in to GitHub Desktop with your GitHub account (Preferences > Accounts or Options > Accounts)
  • Create your 1st Repo at GitHub
    • Log in to GitHub
    • Personal Access Token
      • Note: a PAT is nice but not necessary
    • Click on + > New Repository
    • On Create a New Repository page
      • Repository Name: webster-test-2018-03-20
      • Description: I’m learning Git & GitHub
      • ✓ Public
      • ✓ Initialize This Repository with a README
      • Add .gitignore: Sass
        • For a collection of useful .gitignore templates, see https://github.com/github/gitignore
        • Note the following:
          • C++
          • Concrete5
          • Go
          • Java
          • Node
          • Sass
          • Swift
          • Unreal Engine
          • Visual Studio
          • WordPress
          • Global (operating systems & editors)
            • Dropbox
            • Linux
            • Sublime Text
            • Vim
            • Visual Studio Code
            • Windows
            • macOS
      • Add a License: MIT License
        • Open Source Initiative https://opensource.org
          • Licenses
            • “About” > Open Source Definition
              • The 4 Freedoms of Software (Richard Stallman, the FSF, & GNU)
                • Use for any purpose
                • Distribute
                • Modify
                • Distribute modified versions under the terms of the license, without royalties
            • “Popular Licenses”
              • Apache
              • BSD 2-Clause
              • GPL
              • MIT
            • “All Approved Licenses”
        • ⓘ > Choose an open source license (https://choosealicense.com)
          • “The MIT License is a permissive license that is short and to the point. It lets people do anything they want with your code as long as they provide attribution back to you and don’t hold you liable.”
      • Press Create Repository
      • Now on your project page at https://github.com/rsgranne/webster-test-2018-03-20
        • Note 3 files
          • .gitignore
          • LICENSE
          • README.md
    • Clone your new project to your computer
      • Go to the webster-test-2018-03-20 Projects page
      • Click on the Clone or Download button & make sure it says Use HTTPS
      • Click the Copy To Clipboard button to the right of the URL to copy it
        • On the command line, you would enter: git clone URL
        • Sourcetree
          • File > New
          • New > Clone From URL
            • Source URL: https://github.com/rsgranne/webster-test-2018-03-20
            • Destination Path: ~/Documents/Web Dev Projects/webster-test-2018-03-20
            • Name: webster-test-2018-03-20
            • Press Clone
              • Look at ~/Documents/Web Dev Projects/webster-test-2018-03-20 on your computer to verify
    • Sourcetree
      • Branches > master
      • Fetch
      • Pull
    • Brackets
      • Install extension: BracketstoIX by Alexandre Bento Freire
        • IX TT: Text transformations
        • IX > Lorem ipsum
          • Nr Paragraphs: 1
          • HTML Tag Wrap: p (you have to reformat, which is a pain)
      • Open the webster-test-2018-03-20 project
      • Create:
        • index.html
        • css/
        • css/main.scss
      • In index.html
        • Edit > HTML Templates… > HTML5
        • <title>: `Lorem Ipsum`
        • Add this to <body> & save (Note: if pressed for time, students can copy & paste http://chnsa.ws/19j):
<h1>Page Title</h1>
<p>
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
</p>
<p>
  Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>
<p>
  Oops
</p>
  • Sourcetree
    • Branches > master
      • Don’t see any changes? Fetch, Pull
    • Uncommitted Changes
    • Unstaged Files > index.html
      • We don’t want <p>Oops</p>!
      • Go back to Brackets & delete <p>Oops</p> & Save
      • Go back to Sourcetree
      • Don’t see changes? Click on another file & back on index.html
        • Still don’t see changes? Save the file in Brackets
    • ✓ Unstaged Files
      • All files move to Staged Files
    • Commit
      • What’s a commit?
        • A commit is a tracked change (add, edit, or delete a file)
        • Commits form a history of what you’ve done & why (the Summary & Description)
        • You can always roll back commits if you want the wrong direction
      • You can look at each file to see what has changed
      • You can unstage files
      • Write commit message: Created first web files & folders
        • Always keep it short, simple, & descriptive
      • Press Commit
    • Branches > master
      • 1 ahead (of master)
      • Push now has 1 on icon
      • Press Push
      • Press OK
        • Have to authenticate because you have 2FA on? (which students do not, so they should not need to do this)
          • Me > Settings > Developer Settings > Personal Access Tokens
          • Generate New Token
            • Description: Sourcetree
              • repo
              • admin:repo_hook
              • gist
              • notifications
              • delete_repo
            • Press Generate New Token
          • Cope the token to your password manager!
      • Now go check the repo on GitHub
    • Make a mistake? Right-click on commit & select Reverse Commit
  • Branching
    • Things to know about branches
      • There’s always a master branch
        • If it is in master, it’s always deployable
        • If you’re working on a new feature, fix, or experiment, a new branch should be created off of master
      • You (& anyone else) can fork a branch
        • Specifically, you will be creating a topic branch
          • A topic branch is a separate branch for working on a single “topic” (a bug fix, a new feature, or an experimental idea)
          • Create as many topics as you need so master doesn’t get cluttered
          • Easy to update separately from work on master; at any time, update master while you continue working on your topic branch
          • Easier for others to review if they can focus on only one small set of changes
          • Comments from others focus only on that one topic
        • Branch names should be descriptive: convert-to-scss or add-donation-form
      • Changes you make on your branch don't affect the master branch
      • Experiment & commit changes on your branch
      • Make a pull request asking for your branch to be merged
      • Someone you're collaborating with, who’s in charge of the master branch, reviews it & either approves, rejects, or asks for modifications
    • Process
      • Make a new branch
      • Make changes
      • Open a pull request (or push it)
        • A pull request is you saying “let’s discuss these commits”
        • People discuss the pull request on GitHub using Markdown
        • You can keep pushing to the branch while discussion goes on
      • Deploy changes
      • Merge your code into the master
        • GitHub allows users & developers to report issues
        • When you merge your Pull Request, if you enter Closes #32 then issue number 32 in the repo is automatically closed
    • Practice branching
      • Make a new branch in Sourcetree
        • Make sure you are on the latest version of master, with a hollow bullet
          • If not sure, Fetch & Pull
        • Click the Branch button
          • New Branch: lovecraft-stories
          • Commit: Working copy parent
          • ✓ Checkout new branch
          • Click Create Branch
        • Note that lovecraft-stories now appears under Branches, next to master
          • It’s bold because it’s the active branch
          • Note that Branches now shows: lovecraft-stories origin/master origin/HEAD master
            • Why on the same line? Because you haven't done anything with lovecraft-stories yet!
      • Make changes in Brackets & Commit
        • Brackets
          • Add new folder: lovecraft
          • Add new files in lovecraft/: call-of-cthulhu.html & dunwich-horror.html
        • Sourcetree
          • Stage files
            • Don’t see your changes? Repository > Refresh
          • Commit
            • Commit message: Added Lovecraft section with Cthulhu & Dunwich
            • Press Commit
          • Branches > lovecraft-stories now shows lovecraft-stories branch is now 1 commit ahead of master
        • Brackets
          • Now for CSS
          • Add <link> to main.css in <head>
          • In main.scss
        • Sourcetree
          • Stage files
          • Oops!
            • main.scss has a line-height of 1.3
            • Edit styles/main.scss
            • Change to line-height: 1.5;
          • Commit
            • Commit messages: Added SCSS/CSS
            • Press Commit
          • Branches > lovecraft-stories now shows lovecraft-stories branch is now 2 commits ahead of master
          • Push
            • ✓ lovecraft-stories
            • ✓ Push All Tags?
          • Merge
            • Branches > master
              • You have to switch to the branch you want to merge into
              • Since we want to merge lovecraft-stories into master, we switch to the master branch
            • Click on Merge
            • Now you pick a commit to merge into master, so click on lovecraft-stories
            • Options
              • ✓ Commit merge immediately (if no conflicts)
              • ✓ Include messages from commits being merged in merge commit
              • ✓ Create a commit even if merge resolved via fast-forward
            • Press OK
            • Notice your branch is now merged back into master
            • Push
              • ✓ master
              • Press OK
    • Pull Requests
      • What’s a pull request?
      • 2 types of development models that use pull requests
        • Fork & Pull
          • Process overview
            • Contributor (person who has a pull request merged but does not have collaborator — see Shared Repository below — access) forks an existing repo & pushes changes to their personal fork
            • Changes can then be pulled into the source repository by the project maintainer
            • When contributor opens a pull request proposing changes from her fork's branch to a branch in the source (upstream) repository, she can allow anyone with push access to the upstream repository to make changes to her pull request
          • Advantages
            • Reduces amount of friction for new contributors
            • Allows people to work independently without upfront coordination
            • Popular with open source projects
        • Shared Repository
          • Process overview
          • Advantages
            • Initiate code review & general discussion about a set of changes before the changes are merged into the main development branch
            • Popular with small teams & organizations collaborating on private projects
      • Let’s practice Fork & Pull
        • Fork my repo at GitHub (webster-test-2018-03-20)
        • Clone it to your computer using Sourcetree
          • Create a topic branch (call it your-name; e.g., scott-granneman)
          • Make your changes (create your-name.html in lovecraft/; e.g., lovecraft/scott-granneman.html)
        • Create the Pull Request at GitHub
          • Go to GitHub home page for your forked project
          • Click Pull Request button next to Branch button
          • On Compare Changes page, click “Compare across forks” link
            • Base fork: repo you want to merge into
            • Base branch: branch of the repo you want to merge changes into
            • Head fork: select your fork
            • Compare branch: branch in which you made your changes
            • NOTE:
              • Base branch: where changes should be applied into
              • Head branch: contains your changes you want to be applied
            • Click green Create Pull Request button
          • Provide info for Pull Request
            • Title: Added page about Scott Granneman
            • Description: Added new story about me in lovecraft section
            • ✓ Allow edits from maintainers
              • Un-✓ if you don’t want to allow anyone with push access to the upstream repo to make changes to your Pull Request
          • Click Create Pull Request
        • I review your PR
          • I (owner of original, forked-from repo) go to home page of my project, webster-test-2018-03-20
          • Click Pull requests
            • Look at all the shiny new PRs!
          • Click on specific PR to review it
          • Click on Files Changed
          • Hover over the line of code that needs a comment & click the blue comment icon
          • Enter comment & click Start a Review
          • Click Review Changes
          • Type comment in Review Summary box
          • Select type of review
            • Comment: leave feedback without approving changes or requesting changes
            • Approve: submit feedback & approve merging the proposed changes in PR
            • Request Changes: Submit feedback that must be addressed before PR can be merged
          • Click Submit Review
  • Done!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment