Git Flashcards
git init
initializes a file as the local git repository (creates a git file on your local pc that is hidden)…or turns a current directory into a git repository
git add [file]
adds the file to the staging area (between your local pc and YOUR online repo)
git status
check status of working tree
git commit
commits changes from your staging area to YOUR repo
git push
pushes changes from local repo to a remote repo
git pull
pulls latest changes from remote repo into another repo (like someone else’s master branch or even your own master branch)
git clone
clones ANY repo into your personal directory on your pc
git config –global user.name ‘Mundy Reimer’ git config –global user.email ‘blah@blah.com’
configures our repo
git status
checks what’s in staging area (the 1st part is what we have in the staging area that has changes and needs to be committed. The 2nd part is what files are untracked)
git rm –cached [filename]
removes file from staging area (and are thus now untracked files)
git add *.[filetype]
adds ANY files of that specific type to the staging area
git add .
adds ALL files in the current directory to the staging area (any changes made locally will then still need to be updated to the staging area)
git commit -m ‘some random comment about your change’
commits and comments about it in one step
git branch [branch name]
creates a new branch
git checkout [branch you want to go to]
goes to branch you want to go to
what kind of file is .gitignore ?
a text file that whatever files or directories you type into it, git doesn’t commit those when committing the directory with the .gitignore file
git remote
lists the git remote repositories
git remote add origin [file].git
adds a remote repo called origin
git push -u origin master
pushes the file to the origin master branch
touch README.md
creates a readme markdown file that explains this repo and its contents
What is the commit “hash”?
the specific number that references a particular change in the history of commits of a file or directory
What is “master”?
By default, the original branch that you were working on
What is a “branch”?
Just a linearly series or history of commits (saved changes). If you branch off, then you will start getting parallel versions of a series of files
What is “merge”?
combining a branch back into another one
You can view the whole project’s history of commits, pushes, pulls, in what way?
Go to github > main repo page > insights > dependency graph OR network
What is a “pull request”?
Pulling the outer branch (and its changes) back into the master branch (or requesting to pull it back in if you aren’t the owner of the original branch). You can also request (someone else) to pull your “forked branch” and merge it into their original repo
What is a “fork”?
When you want to copy someone else’s repo from their account into yours (and the exact historical graph with all its branches as well)
What are “issues”?
Comments about a project. Only the owner of the original repo can close or resolve an issue. All issues have an ID # (see url). To address an issue, you can make a comment when you commit and just reference it by using #thenTheSpecificIssueNumberHere. You can also close the issue by using the words “fixed” in the commit comments
git commit -a
adds a file to the staging area AND commits it in one fell swoop
git remote add [name of origin repo you want to create] [url of origin repo on your account]
creates a repo that is an origin type repo in some url you wanted. You do this if you wanted to commit from your local a file or set of files that you originally cloned from someone else’s account (and thus their origin repo, and hence you don’t have your own origin repo on your account)
git diff /somepath/somefile
-or-
git diff –cached /somepath/file
By default git diff will show you any uncommitted changes since the last commit.
Diffing is a function that takes two input data sets and outputs the changes between them.
git diff is a multi-use Git command that when executed runs a diff function on Git data sources. These data sources can be commits, branches, files and more.
The git diffcommand is often used along with git status and git log to analyze the current state of a Git repo.
This example is scoped to ./path/to/file when invoked, it will compare the specific changes in the working directory, against the index, showing the changes that are not staged yet.
When git diff is invoked with the –cached option the diff will compare the staged changes with the local repository. The –cached option is synonymous with –staged.
git diff –color-words
git diff also has a special mode for highlighting changes with much better granularity: ‐‐color-words.
This mode tokenizes added and removed lines by whitespace and then diffs those.
What are the 5 git commands that ‘undo’ commits or changes?
git checkout
git clean
git revert
git reset
git rm
git checkout hashcode_of_commit
-or-
git checkout -b name_of_new_branch_u_wanna_create
Using the git checkout command we can checkout the previous commit, a1e8fb5 (some hashcode of the previous state you’d like to be in), putting the repository in a state before the crazy commit happened. Checking out a specific commit will put the repo in a “detached HEAD” state. This means you are no longer working on any branch. In a detached state, any new commits you make will be orphaned when you change branches back to an established branch. Orphaned commits are up for deletion by Git’s garbage collector. The garbage collector runs on a configured interval and permanently destroys orphaned commits. To prevent orphaned commits from being garbage collected, we need to ensure we are on a branch.
From the detached HEAD state, we can execute git checkout -b new_branch_without_crazy_commit. This will create a new branch named new_branch_without_crazy_commitand switch to that state. The repo is now on a new history timeline in which the 872fa7e commit no longer exists. At this point, we can continue work on this new branch in which the 872fa7e commit no longer exists and consider it ‘undone’. Unfortunately, if you need the previous branch, maybe it was your master branch, this undo strategy is not appropriate.
git revert the_head_hashcode
Let’s assume we are back to our original commit history example. The history that includes the 872fa7e commit. This time let’s try a revert ‘undo’. If we execute git revert HEAD, Git will create a new commit with the inverse of the last commit. This adds a new commit to the current branch history and now makes it look like:
_____
git log –oneline
e2f9a78 Revert “Try something crazy”
872fa7e Try something crazy
a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt
9773e52 Initial import
_____
At this point, we have again technically ‘undone’ the 872fa7ecommit. Although 872fa7e still exists in the history, the new e2f9a78 commit is an inverse of the changes in 872fa7e. Unlike our previous checkout strategy, we can continue using the same branch. This solution is a satisfactory undo. This is the ideal ‘undo’ method for working with public shared repositories. If you have requirements of keeping a curated and minimal Git history this strategy may not be satisfactory.
git reset –hard somehashcode
For this undo strategy we will continue with our working example. git reset is an extensive command with multiple uses and functions. If we invoke git reset –hard a1e8fb5 the commit history is reset to that specified commit. Examining the commit history with git log will now look like:
_____
git log –oneline
a1e8fb5 Make some important changes to hello.txt 435b61d Create hello.txt
9773e52 Initial import
_____
The log output shows the e2f9a78 and 872fa7e commits no longer exist in the commit history. At this point, we can continue working and creating new commits as if the ‘crazy’ commits never happened. This method of undoing changes has the cleanest effect on history. Doing a reset is great for local changes however it adds complications when working with a shared remote repository. If we have a shared remote repository that has the 872fa7e commit pushed to it, and we try to git push a branch where we have reset the history, Git will catch this and throw an error. Git will assume that the branch being pushed is not up to date because of it’s missing commits. In these scenarios, git revert should be the preferred undo method.
The git add command is used to add changes to the staging index. Git reset is primarily used to undo the staging index changes.
git commit –amend
In some cases though, you might not need to remove or reset the last commit. Maybe it was just made prematurely. In this case you can amend the most recent commit. Once you have made more changes in the working directory and staged them for commit by using git add, you can execute git commit –amend. This will have Git open the configured system editor and let you modify the last commit message. The new changes will be added to the amended commit.
git revert
When working on a team with remote repositories, extra consideration needs to be made when undoing changes. Git reset should generally be considered a ‘local’ undo method. A reset should be used when undoing changes to a private branch. This safely isolates the removal of commits from other branches that may be in use by other developers. Problems arise when a reset is executed on a shared branch and that branch is then pushed remotely with git push. Git will block the push in this scenario complaining that the branch being pushed is out of date from the remote branch as it is missing commits.
The preferred method of undoing shared history is git revert. A revert is safer than a reset because it will not remove any commits from a shared history. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit.
Summarize the purpose of each:
git checkout
git revert
git reset
git log
git clean
git add
Once changes have been committed they are generally permanent.
Some key points to remember are:
- Use git checkout to move around and review the commit history
- git revert is the best tool for undoing shared public changes
- git reset is best used for undoing local private changes
- git log for finding lost commits
- git clean for undoing uncommitted changes
- git add for modifying the staging index
git clean
Git clean is to some extent an ‘undo’ command. Git clean can be considered complementary to other commands like git reset and git checkout. Whereas these other commands operate on files previously added to the Git tracking index, the git clean command operates on untracked files. Untracked files are files that have been created within your repo’s working directory but have not yet been added to the repository’s tracking index using the git add command.
git revert
-or-
git revert HEAD
(to revert back to latest change)
The git revert command can be considered an ‘undo’ type command, however, it is not a traditional undo operation. Instead of removing the commit from the project history, it figures out how to invert the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents Git from losing history, which is important for the integrity of your revision history and for reliable collaboration.
Reverting should be used when you want to apply the inverse of a commit from your project history. This can be useful, for example, if you’re tracking down a bug and find that it was introduced by a single commit. Instead of manually going in, fixing it, and committing a new snapshot, you can use git revert to automatically do all of this for you.
Reverting has two important advantages over resetting. First, it doesn’t change the project history, which makes it a “safe” operation for commits that have already been published to a shared repository. For details about why altering shared history is dangerous, please see the git reset page.
Second, git revert is able to target an individual commit at an arbitrary point in the history, whereas git reset can only work backward from the current commit. For example, if you wanted to undo an old commit with git reset, you would have to remove all of the commits that occurred after the target commit, remove it, then re-commit all of the subsequent commits.
git reset
has optional args:
–soft
–mixed
–hard
The git reset command is a complex and versatile tool for undoing changes. It has three primary forms of invocation. These forms correspond to command line arguments –soft, –mixed, –hard. The three arguments each correspond to Git’s three internal state management mechanism’s, The Commit Tree (HEAD), The Staging Index, and The Working Directory.
_______
–hard
This is the most direct, DANGEROUS, and frequently used option. When passed –hard The Commit History ref pointers are updated to the specified commit. Then, the Staging Index and Working Directory are reset to match that of the specified commit. Any previously pending changes to the Staging Index and the Working Directory gets reset to match the state of the Commit Tree. This means any pending work that was hanging out in the Staging Index and Working Directory will be lost.
_______
–mixed
This is the default operating mode. The ref pointers are updated. The Staging Index is reset to the state of the specified commit. Any changes that have been undone from the Staging Index are moved to the Working Directory. To reiterate, –mixed is the default mode and the same effect as executing git reset.
_______
–soft
When the –soft argument is passed, the ref pointers are updated and the reset stops there. The Staging Index and the Working Directory are left untouched.
What’s the difference between
git checkout b
-vs-
git reset b
…using the below picture:
At a surface level, git reset is similar in behavior to git checkout. Where git checkout solely operates on the HEAD ref pointer, git reset will move the HEAD ref pointer and the current branch ref pointer.
With git checkout, the master ref is still pointing to d. The HEAD ref has been moved, and now points at commit b. The repo is now in a ‘detached HEAD’ state.
Comparatively, git reset, moves both the HEAD and branch refs to the specified commit.
In addition to updating the commit ref pointers, git reset will modify the state of the three trees. The ref pointer modification always happens and is an update to the third tree, the Commit tree.
git rm
A common question when getting started with Git is “How do I tell Git not to track a file (or files) any more?” The git rmcommand is used to remove files from a Git repository. It can be thought of as the inverse of the git add command.
_____
How to undo git rm:
Executing git rm is not a permanent update. The command will update the staging index and the working directory. These changes will not be persisted until a new commit is created and the changes are added to the commit history. This means that the changes here can be “undone” using common Git commands.
git reset HEAD
A reset will revert the current staging index and working directory back to the HEAD commit. This will undo a git rm.
git checkout .
A checkout will have the same effect and restore the latest version of a file from HEAD.
Which command would you use to save your most recent changes without staging them for the next commit?
git stash
Which command would you use to temporarily go back to the first commit?
git checkout first_hash_number
Which command would you use to then return to the most recent commit?
git checkout master
Which command would you use to create a new commit undoing the second commit?
git revert second_hash_number
Which command would you use to reapply the changes you temporarily saved without staging?
git stash apply
Finally, which command would you use to permanently go back to the first commit, abandoning all subsequent commits?
git reset –hard first_hash_number
Suppose you are in a clean repository with some files in it. One of those files is called file.txt.
Suppose you run this command:
rm file.txt
What is true about the result?
The file will be removed from the disk, but that change will not be staged.
Suppose you are in a clean repository with some files in it. One of those files is called file.txt.
Suppose you run this command:
git rm file.txt
What is true about the result?
The file will be removed from the disk, and that change will be staged.
What does HEAD mean in a git repository?
HEAD is a nickname for the current commit (not the most recent!!!)
What does git clean do and why does git clean often requires the -f flag?
The command is used to remove untracked files. The flag is required to make sure this is actually your intention.
git remote
git remote -v
git remote add <name> <url></url></name>
git remote rm <name></name>
git remote rename <old-name> <new-name><br></br> </new-name></old-name>
List the remote connections you have to other repositories.
-v argument now includes the URL of each connection
‘add’ allows you to create a new connection to a remote repository. After adding a remote, you’ll be able to use <name> as a convenient shortcut for <url> in other Git commands.</url></name>
git fetch
git fetch <remote><br></br><br></br>git fetch <remote> <branch><br></br><br></br>git fetch --all</branch></remote></remote>
It will download the remote content but not update your local repo’s working state, leaving your current work intact.
The git fetch command downloads commits, files, and refs from a remote repository into your local repo. Fetching is what you do when you want to see what everybody else has been working on.
It doesn’t force you to actually merge the changes into your repository. Git isolates fetched content as a from existing local content, it has absolutely no effect on your local development work.
Fetched content has to be explicitly checked out using the git checkout command. This makes fetching a safe way to review commits before integrating them with your local repository.
git push <remote> <branch></branch></remote>
The git push command is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote repo.
It’s the counterpart to git fetch, but whereas fetching imports commits to local branches, pushing exports commits to remote branches.
git checkout -b name_of_branch
Use git checkout with the -b option, which makes a new branch and checks it out at the same time
the branch effectively represents a copy of the repo at the time the branch was made
Use without the -b option to just checkout that previously created branch and work on it (without creating a new branch):
git checkout name-of-branch
git branch
This lists all the branches currently defined on the local machine, with an asterisk * indicating the currently checked-out branch.
What command also allows us to see differences or changes before we merge a branch back into the master branch?
git diff branch-1 branch-2
you can also just compare the current branch with the master branch by:
git diff master
How do we merge our current branch with the master branch?
git checkout master
(without the -b option since master already exists)
Then follow it up with:
git merge name-of-current-file
If we make a big mistake in our local copy of the code and want to revert back to the most recently committed code, what do we do?
We want to checkout the HEAD, but with the force -f option:
git checkout -f
***Note: This will wipe out any recent non-committed changes on your local copy, by re-writing it over with the previously committed HEAD’s copy.
How do we delete a branch?
git branch -D test-branch
