The Visual Cheat Sheet
Git is not known as among the simplest of software. It was literally created for and by Linux kernel developers who have a megabrain recall to speed-type long commands.
But I don’t feel I’m that smart, and felt overwhelmed.
Like you, I had no choice but to study hard to fully grasp Git’s complexity. Undeterred, for the last two years, I scoured the internet to view every blog, video, and book about this subject. So you don’t have to.
Military commanders use large yet detailed maps to see their entire battlefield, showing the location of bunkers and the sequence of troop movements.
In my personal battle against Git’s complexity, I created a detailed map of the sequences to all data flows in and out of Git’s storage locations and their statuses.
Some call it a visual cheat sheet.
But I call it “fearless” because I introduce Git in more depth and in a different sequence than other tutorials that have come before me.
Basic commands flows
I thank ZeroTurnaround for a diagram which illustrates the sequence of basic commands:
PROTIP: I encourage you to pull out a paper and hand-draw the diagram as we go along. You’ll remember it better.
The Git Pull command pulls down a complete copy of a repository’s change history and checks out the latest revision of files in the local Working Directory.
Fetch updates changes from the Remote, but does not update the Working Directory.
Locally made changes are added to Staging and commit updates change history tracking.
Different parameters of the reset command replaces changes in the Working Directory or in Staging with what is in Git’s repository.
Push pushes files back to the remote repository on GitHub.
But we need to dive deeper so we can comfortably reverse (in a safe way) every action we do. We also want to use Git flow feature branches to work safely as a team.
I have a one-day course I present at conferences, on-site, and on-line the specific commands and additonal PROTIPs covered here.
My next live conference presentation is at StarWest Disneyland Oct. 4, 2016. Sign up at http://goo.gl/5dRcGS. See you there!
I created a video with commentary so you can quickly grasp the nuances of key commands involved with Git flow.
You may prefer accessing the videos via the playlist at:
A playlist link lists the latest versions because individual videos can be added or removed.
Direct links to individual YouTube videos can become stale when newer versions are downloaded.
The video is from an animated PowerPoint file, narrated separately with text below.
My map (Visual Cheat Sheet)
PROTIP: You are encouraged to pull out a paper and hand-draw the diagram as we go along. You’ll remember this better.
Please let me know if you can see a tweak to this sequence for better introduction of concepts.
Let’s begin with repositories in a cloud service, GitHub.com.
A repo that belongs to another organization is called an “upstream” location. If we edit that repo, GitHub automatically forks it under our own account. If we want to make changes, we would need to file a Pull Request from the repo under our account.
One of the main advantages of GitHub is it makes use of branches. The default branch is named “master” out of the box. *** But many organizations protect it for production use, and create a “development” or “dev” branch for developers to work with.
We can click the Download button to bring a zip file to my local Downloads folder, then unzip to a folder I created.
But that folder alone does not keep back versions. For that we need a .git folder among the files, which is done by a Git client installed on my local machine.
The Git init command processed by the Git client creates the Git folder which holds the history of changes.
The Git clone command creates that .git folder inside a new folder from files downloaded from GitHub. ** The clone command also includes a Git checkout command that extracts the lastest set of files into the Working Directory holding the .git folder.
If we run the SSH or Putty command to create keys, the Git client can communicate securely with the cloud service.
We run config commands to configure the .gitconfig file referenced by all Git repositories on our machine to provide our default name and email address to repos.
If we do a remote -v command on a repo we cloned, we typically see that origin as the location. We can remote add the upstream repo if we want to update our local repo with changes in the upstream repo.
Git only tracks files involved in a git commit command. Git stores what has changed in the .git folder and calculates a reference to each particular change.
The git tag command allows a custom name of your choosing to be assigned to a commit. Teams use this to specify and sign release numbers and specifications which Jenkins recognizes to invoke integration builds.
There are several commands that reveal what is inside the .git folder managing history.
The Git shortlog summarizes the history of commits made by author.
The Git log command lists a detailed history of commits made. Most consider its default format takes up too many lines, so many configure in the .gitconfig file an alias such as lol to format what gets displayed.
BTW, “HEAD” refers to the most current commit, listed at the top of a chain of its descendants from prior commits. In other words, Git log shows the current HEAD and its ancestry by traversing back through the repo’s ancestry recursively looking up each commit’s parent.
The git reflog command lists the history of all changes made in the sequence they occurred, like an undo history of the repo. It’s stored separately from the commits themselves and isn’t included in pushes, fetches or clones because it’s purely for local use. If it seems like a commit has been lost, chances are the reflog will show it and allow you to restore it.
The Git show command lists fine-grained internal objects in the repository, such as blobs and trees associated with tags and commits.
The Git blame command gives a timeline of changes to specific files. ***
The Git branch command lists what branches are in the local repository because only a specific branch may be cloned locally.
Under Gitflow, we begin work by creating a feature branch using a Git checkout command with the -b parameter which specifies the creation of a new branch.
This will put you in what Git calls a “detached HEAD” state.
Bash commands touch and echo create and change files. Text editors and IDEs also create and change files.
In order for files to be committed for tracking by Git,
they first must be specified in a git add
command which puts changes in a sort of “shopping cart” called
staging, also called Index because it holds an index of files which the next git commit command would track.
The git status command shows which files have been staged or remain untracked.
If you have to find text among a lot of files the Git grep command has many options to identify files containing text that match a specification.
We want to use a Git diff command or use a diff-tool to identify differences between the working set and what’s in Staging.
For a formatted document of differences, some use diff-tree, which shares the same parameters as the git show command.
When Git detects a staged file has been edited by a text editor, Git automatically takes that file out of staging and assigns it the status of modified.
If we need to suddenly switch back to what’s in the commit HEAD, we don’t need to always abandon and forever loose uncompleted work.
We can use the Git stash save to copy all files from the working directory into an area hidden from Staging or the Git repository.
Modifications stashed can be listed with git stash list, inspected with git stash show, and restored (potentially on top of a different commit) with git stash pop, which does the equivalent of git stash apply to retrieve the last stash, but also does a git stash drop to remove it from the stash.
*** ??? Git checkout and Git pull refuses to update files with uncommitted modifications (tracked or not).
To remove files from staging, Git command reset HEAD – can be used followed by a file specification, which can be a dot to specify all files.
To remove all files in the working directory which are NOT under version control, use the Git clean command, which works recursively down the various sub-folders.
To wipe out all uncommitted changes in staging and replace the working tree with the commit HEAD specified, use Git command reset –hard HEAD^.
Files deleted after being committed would appear with a status of “deleted”.
After a commit, the status command would show no files.
If the description of the most recent local commit needs to be changed, it can be done using a commit –amend parameter.
Elements considered “garbage” are removed automatically after a default 90 days, or immediately by the Git gc –prune command.
To identify elements which will be garbage collected, we use the Git fsck command, ** which is one of the Git “plumbing” commands not usually used.
To change the content of the most recent commit, a revert command can be used to create another commit which does the opposite of what is being reverted.
Changing previous commits would require a git “push –force” command, which is not allowed in most organizations because it requires others who have cloned the repo to make manual changes.
But while you’re still working on a local branch, you can use git rebase to interactively reword commit messages or squash several commits into one. This is desirable especially for commits that only fix typos in the local repo which other do not really want to know about.
When working as a team, changes may have occcurred while you’re working with an older version.
Many tutorials talk about using the pull command to obtain updates from the origin or upstream location.
But we prefer using the fetch command which, unlike pull, does not automatically do a merge.
??? Once we know the differences, we can then resolve them and run git merge manually or use a git merge-tool.
We then know it’s OK to do a git push of local commits to the team repository in the cloud.
As with any Git repo, a .gitignore file specifies local files which Git should not send up to the team GitHub repo.
*** An additional Git push is necessary to send tags to GitHub. Such tags need to be created with a -a (dash a) parameter which designates a commit to be created with the tag.
Recap of statuses
Now that you’ve seen mine, let’s recap with the flowchart from the
book at Git-SCM.com
- To stage files for commit, add it.
- When you edit a file, it needs to be added to stage again.
- After a commit, files in working folder are untracked.
Commands by type
(Out of scope here are comands for Email, Administration, and Plumbing)
Common Git Commands in alphabetical order
Click each command for its documentation on git-scm.com:
- blame - Show what revision and author last modified each line of a file
- bisect - Show what revision and author last modified each line of a file
- branch - List, create, or delete branches
- checkout - Switch branches or restore working tree files
- cherry-pick - Apply the changes introduced by some existing commits
- clean - Remove untracked files from the working tree
- clone - Clone a repository into a new directory
- commit - Record changes to the repository
- config - Get and set repository or global options
- describe- Describe a commit using the most recent tag reachable from it
- diff - Show changes between commits, commit and working tree, etc
- grep - Print lines matching a pattern
- init - Create an empty Git repository or reinitialize an existing one
- ls-files - Show information about files in the index and the working tree
- log - Show commit logs
- merge - Join two or more development histories together
- mergetool - Run merge conflict resolution tools to resolve merge conflicts
- pull - Fetch from and integrate with another repository or a local branch
- push - Update remote refs along with associated objects
- rebase - Reapply commits on top of another base tip
- reflog - Manage reflog information
- reset - Reset current HEAD to the specified state
- revert - Revert some existing commits
- shortlog - Summarize git log output
- stash - Stash the changes in a dirty working directory away
- status - Show the working tree status
- tag - Create, list, delete or verify a tag object signed with GPG
This is one of a series on Git and GitHub:
- Why Git? (file-based backups vs Git clone)
- Git-client based workflows
- Git whoops (correct mistakes)
- Git rebase
- Git commits with a Tag and Signature
- Git HEAD (Commitish references)
- Git custom commands
- Git utilities
- TFS vs GitHub
- GitHub REST API
- GitHub GraphQL API
- GitHub PowerShell API Programming
- GitHub GraphQL PowerShell Module