Lesson 3: Editors & Version Control

Check in from last week

Is anyone having problems with package management?

Install the packages named git, vim, and emacs

What we’ll discuss

  • What’s a text editor?
  • Features of an editor
  • Version control: Git!

How do you edit files?


_images/word_screenshot.gif

No. Never, Ever edit code in Word/LibreOffice

  • Autocorrect is your worst enemy
  • Syntax highlighting is nice
  • You are editing plain text, not ‘documents’, i.e. .doc, .rtf, etc

Then what should you use?

  • Text editors
    • Command-line
    • available in your package manager
  • For coding, an IDE can be helpful

Integrated Development Environments


_images/eclipse_screenshot.gif
  • Entire toolchain in one place
  • Usually graphical

Sysadmin tools

  • Frequently work with remote machines over a ssh connection
    • xforwarding can sort of give you a GUI
    • Not all remote machines have a desktop environment
  • Faster to edit file in place than transfer it down then back up
    • Frequent small changes when testing or debugging
  • Broken machines often have only terminal via crash cart

Editor Requirements:
 
  • Small program, runs in terminal
  • Preferably installed by default on most systems

Features of an editor

  • Needs to be installed on your system
  • Create files
  • Move around within the file
  • Add or delete text
  • Easily automate tedious tasks

Text Editors

Note

Quick intro/history: ed editor Pros: low-bandwidth, installed pretty much everywhere, very fast and powerful for complicated and repetitive tasks Cons: Steep learning curve, different “modes” can be confusing at first Sublime and other desktop editors: nice for serious programming, but learn the basics of simple text editors even if you want to be a developer, you won’t always be able to edit your code on your own desktop

  • ed -> Vi -> Vim
  • Stallman -> lisp -> emacs
_images/xkcd_378.png

Avoid Pico/Nano, Notepad++, SublimeText

Emacs

_images/emacs_logo.jpeg

Note

Originally released 1976 name from Editor MACros for TECO editor, originally Tape Editor and COrrector at MIT in the ‘60s

But, along the way, I wrote a text editor, Emacs. The interesting idea about Emacs was that it had a programming language, and the user’s editing commands would be written in that interpreted programming language, so that you could load new commands into your editor while you were editing. You could edit the programs you were using and then go on editing with them.

Vim

_images/vim_logo.jpeg

Note

originally written for Amiga systems (Commodore PCs), 1988 vim released 1991 vimscript, Lua (as of Vim 7.3), Perl, Python, Racket, Ruby, Tcl (tool command language). vi written by Bill Joy in 1976, visual mode for line editor called ex line editors are from age of teleprinters, no cursors

How to choose

  • What can the people around you help with?

  • Try both; choose one and get good at it

  • Have a good answer when people ask why you made that choice
    • “Because it’s familiar” is tolerated
    • “Because I was initially taught it” is common but accepted (honesty)
    • “Because $usecase” provokes argument but more respected
    • “Because I tried both and picked this one” is rare but good
  • Your use case as a sysadmin or developer

Modes

_images/vim_modes.png

How to tell?

-- INSERT --                                          144,1    36%
-- VISUAL --                                          144,77   36%

Commands

Note

Moving around in a file Search / replace Text manipulation, ie: cw, dw, c$, yy / p, x, .

_images/vim_cheatsheet.gif

Moving Around

h move one character to the left.
j move down one line.
k move up one line.
l move one character to the right.
0 move to the beginning of the line.
$ move to the end of the line.
w move forward one word.
b move backward one word.
G move to the end of the file.
gg move to the beginning of the file.
. move to the last edit.

Configuration / customization

Note

there are many many options and pre-existing packages to make editing nice for sysadmins and developers

  • .vimrc
  • :set

Some sets of Vim plugins and configurations are available

Use them for research on what’s available to improve dev productivity

Learning Resources

_images/learning_curves.jpg

Regular expressions

You should know basic substitution:

:%s/foo/bar/g

On IRC, Hamper does rudimentary regex in the form s/foo/bar/ applying only to the most recent comment.

This is not shell globbing

Resources for learning:
 

Editor questions?

  • Open an editor, find a cheat sheet, try to add some text
  • Modify the text: “disemvowel” it
$ vim testvim.txt            $ emacs testemacs.txt
<i>                          Hello world!
Hello world!                 <esc>
<esc>                        <
:%s/[aeiou]//g               <alt + x>
:wq                          replace-regexp
                             [aeiou]
                             <enter>
                             <ctrl + x> <ctrl + s>
                             <ctrl + x> <ctrl + c>

Lesson 3: Intro to Git

Version Control is Hard


_images/xkcd_1053.png

Image from XKCD

Why Bother?

_images/phd_final.gif

Image from PhD Comics

Better Options: Version Control

Note

Collaboration with multiple developers is important to mention

  • Commit = Snapshot of part of your project’s state

  • Centralized (SVN, CVS) vs. Decentralized (Git, hg)

  • We’ll look at Git today
    • Easier to learn other VCS from Git
    • Widely used in the open source world

Git

_images/Linus_Torvalds.jpeg
git
noun. Brit.informal. 1. an unpleasant or contemptible person.

Using Git Locally

# This initializes a git repo. Use `man git-init` for more info.
$ git init

# This puts <filename> into the staging area. It isn't committed yet.  Use
# `git diff` to see what changes aren't yet in staging.
$ git add <filename>

# This actually makes the commit. Use `git status` to see what's in staging
# but not yet committed. Use `git show` or `git log` to see recent commits.
$ git commit -m "I did a thing!"
  • Undo things? the git book explains well
  • Did I remember to commit that? $ git status
  • What commits have I made lately? $ git log

More on commits

Your work goes from unstaged to staging area with git add.

$ git config --global user.name 'Your Name'
$ git config --global user.email you@somedomain.com
  • Everything in staging gets wrapped up into an object that contains
    • changes
    • timestamp
    • author info
    • parent commit hash
  • These live in .git/ in your project directory

  • Commits go to other locations with git push

What Not To Do

  • Don’t delete the .git files

Note

If you kill them, git loses its memory :(

  • Redundant copies of same work

  • “oops, undoing that” commits.
    • Use git commit --amend

Note

Amending is fine as long as you haven’t pushed yet. It’s generally a bad idea to amend or rebase work that you’ve already shared with others, unless you really know what you’re doing.

  • Don’t wait too long between commits
    • Squashing them together later is easy

Note

Commit every time you think you might want to return to the current state. You can revert back to any previous commit, but there is no way to magically add a commit in where you forgot to make one.

  • Don’t commit compiled/generated items

Note

Mostly relevant to writing code, .gitignore allows you to avoid dealing with compiled binaries, generated output, log files, etc

  • Don’t commit secrets...

Note

Yes, there are ways to sort of take them down off of GitHub, but somebody might have cloned your repo while it had the secrets in. Once someone has a piece of information, you can’t just take it away.

Daily workflow

_images/gitflow.png

  • Pull
  • Work
  • Add changes
  • Commit
  • Push

Larger projects have more complex workflows

Note

The picture is of the Git Flow branching model, and you’ll probably see it every single time anyone explains Git branching and merging to you. If you are working on a larger project or writing code, you’ll likely be using branches, this allows a project to keep many simultaneous code changes organized.

Lesson 3: GitHub

_images/octocat.jpg
  • Manage permissions on repos
  • Back up your work
  • Social/gamification
  • Amazing documentation: http://help.github.com

Note

GitHub serves a threefold purpose: It also has amazing documentation which you should all go read right now and consult whenever you’re the least bit confused. It’s like the Ubuntu forums in that it’s explained in a way the newbies can understand, but unlike them in that it’s all written by people who know what they’re doing.

Let’s Walk Through

_images/octocat.jpg
  • Creating an account
    • Gravatar
    • How to read a profile

Note

you just go to github.com and click the account creation links. To make a custom icon, go to gravatar.com and set up an account using the same email address as you used for github. The picture you upload on Gravatar will then show up for your github account.

The most important thing about reading profiles is that not all of a person’s repos will display on the front page of their profile – to see them, got to the ‘repositories’ tab instead of ‘contributions’.

  • Creating SSH keys
    • ssh-keygen -t rsa
  • Uploading your SSH key

  • Creating a new repository

  • Fork somebody else’s repo

  • Edit files online

  • Submit a pull request

Help, Everythings’s Broken!

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Solution:ssh-add ~/.ssh/id-rsa or whatever key you have added on github
To git@github.com:edunham/slides.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:edunham/slides.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Solution:To avoid a messy merge commit, git pull --rebase.

Hands-On

  • Fork the devopsbootcamp dotfiles repo
  • Clone a copy of the repo to your VM and make a branch
  • Make a commit with a helpful commit message and push to your fork
$ ssh-keygen -t rsa # make an SSH key and add it to your account
$ git clone <url from sidebar of your fork> # clone the repo
$ cd dotfiles # git commands only work in project directlry
$ git checkout -b <yourname> # -b creates branch
$ vim <filename>
    # 'i' to enter insert mode
    # <esc> to get back to command mode
    # :wq to save and quit
$ git add <filename>
$ git commit -m "please use a helpful commit message, not like this one"
$ git push