Manual
Let’s get familiar with the git manual.
Exercise - git commands
Run the following command to discover the available git commands of the manual:
git help -a
You should receive a pretty long list of git commands. Navigate through the list with the up and down arrow keys. Close the list by pressing q on your keyboard.
Solution
All available commands are printed on the standard output:
See 'git help <command>' to read about a specific subcommand
Main Porcelain Commands
add Add file contents to the index
am Apply a series of patches from a mailbox
archive Create an archive of files from a named tree
bisect Use binary search to find the commit that introduced a bug
branch List, create, or delete branches
bundle Move objects and refs by archive
checkout Switch branches or restore working tree files
cherry-pick Apply the changes introduced by some existing commits
citool Graphical alternative to git-commit
clean Remove untracked files from the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
describe Give an object a human readable name based on an available ref
diff Show changes between commits, commit and working tree, etc
fetch Download objects and refs from another repository
format-patch Prepare patches for e-mail submission
gc Cleanup unnecessary files and optimize the local repository
gitk The Git repository browser
grep Print lines matching a pattern
gui A portable graphical interface to Git
init Create an empty Git repository or reinitialize an existing one
log Show commit logs
maintenance Run tasks to optimize Git repository data
merge Join two or more development histories together
mv Move or rename a file, a directory, or a symlink
notes Add or inspect object notes
pull Fetch from and integrate with another repository or a local branch
push Update remote refs along with associated objects
range-diff Compare two commit ranges (e.g. two versions of a branch)
rebase Reapply commits on top of another base tip
reset Reset current HEAD to the specified state
restore Restore working tree files
revert Revert some existing commits
rm Remove files from the working tree and from the index
scalar A tool for managing large Git repositories
shortlog Summarize 'git log' output
show Show various types of objects
sparse-checkout Reduce your working tree to a subset of tracked files
stash Stash the changes in a dirty working directory away
status Show the working tree status
submodule Initialize, update or inspect submodules
switch Switch branches
tag Create, list, delete or verify a tag object signed with GPG
worktree Manage multiple working trees
Ancillary Commands / Manipulators
config Get and set repository or global options
fast-export Git data exporter
fast-import Backend for fast Git data importers
filter-branch Rewrite branches
mergetool Run merge conflict resolution tools to resolve merge conflicts
pack-refs Pack heads and tags for efficient repository access
prune Prune all unreachable objects from the object database
reflog Manage reflog information
refs Low-level access to refs
remote Manage set of tracked repositories
repack Pack unpacked objects in a repository
replace Create, list, delete refs to replace objects
Ancillary Commands / Interrogators
annotate Annotate file lines with commit information
:You can get more help for a specific subcommand by running:
git help <command>
Let’s try this and see the help for the add subcommand:
git help add
As always navigate through the list with your arrow keys and close it by pressing q.
Solution
Your output should look similar to this:
GIT-ADD(1) Git Manual GIT-ADD(1)
NAME
git-add - Add file contents to the index
SYNOPSIS
git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--[no-]all | -A | --[no-]ignore-removal | [--update | -u]] [--sparse]
[--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
[--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
[--] [<pathspec>...]
DESCRIPTION
This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit. It typically adds the current content of existing paths as a whole, but with some options it can also be used to add content
with only part of the changes made to the working tree files applied, or remove paths that do not exist in the working tree anymore.
The "index" holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Thus after making any changes to the working tree, and before running the commit command, you must use the add command to
add any new or modified files to the index.
This command can be performed multiple times before a commit. It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run git add again to add the new
content to the index.
The git status command can be used to obtain a summary of which files have changes that are staged for the next commit.
The git add command will not add ignored files by default. If any ignored files were explicitly specified on the command line, git add will fail with a list of ignored files. Ignored files reached by directory recursion or filename globbing performed by Git
(quote your globs before the shell) will be silently ignored. The git add command can be used to add ignored files with the -f (force) option.
Please see git-commit(1) for alternative ways to add content to a commit.
OPTIONS
<pathspec>...
Files to add content from. Fileglobs (e.g. *.c) can be given to add all matching files. Also a leading directory name (e.g. dir to add dir/file1 and dir/file2) can be given to update the index to match the current state of the directory as a whole (e.g.
specifying dir will record not just a file dir/file1 modified in the working tree, a file dir/file2 added to the working tree, but also a file dir/file3 removed from the working tree). Note that older versions of Git used to ignore removed files; use
--no-all option if you want to add modified or new files but ignore removed ones.
For more details about the <pathspec> syntax, see the pathspec entry in gitglossary(7).
-n, --dry-run
Don’t actually add the file(s), just show if they exist and/or will be ignored.
-v, --verbose
Be verbose.
-f, --force
Allow adding otherwise ignored files.
--sparse
Allow updating index entries outside of the sparse-checkout cone. Normally, git add refuses to update index entries whose paths do not fit within the sparse-checkout cone, since those files might be removed from the working tree without warning. See git-
sparse-checkout(1) for more details.
-i, --interactive
Add modified contents in the working tree interactively to the index. Optional path arguments may be supplied to limit operation to a subset of the working tree. See “Interactive mode” for details.
-p, --patch
Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.
This effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details.
-e, --edit
Open the diff vs. the index in an editor and let the user edit it. After the editor was closed, adjust the hunk headers and apply the patch to the index.
The intent of this option is to pick and choose lines of the patch to apply, or even to modify the contents of lines to be staged. This can be quicker and more flexible than using the interactive hunk selector. However, it is easy to confuse oneself and
create a patch that does not apply to the index. See EDITING PATCHES below.
:Exercise - git guides
Next let us discover a list of useful git guides. Run the following command in your environment:
git help -g
Git guides provide step-by-step instructions, best practices and troubleshooting tips for managing code repositories.
Solution
The list of the git guides is also printed on the standard output:
The Git concept guides are:
core-tutorial A Git core tutorial for developers
credentials Providing usernames and passwords to Git
cvs-migration Git for CVS users
diffcore Tweaking diff output
everyday A useful minimum set of commands for Everyday Git
faq Frequently asked questions about using Git
glossary A Git Glossary
namespaces Git namespaces
remote-helpers Helper programs to interact with remote repositories
submodules Mounting one repository inside another
tutorial A tutorial introduction to Git
tutorial-2 A tutorial introduction to Git: part two
workflows An overview of recommended workflows with Git
'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
See 'git help git' for an overview of the system.For example to get the faq (Frequently asked questions) about using git you can execute:
git help faq
Solution
GITFAQ(7) Git Manual GITFAQ(7)
NAME
gitfaq - Frequently asked questions about using Git
SYNOPSIS
gitfaq
DESCRIPTION
The examples in this FAQ assume a standard POSIX shell, like bash or dash, and a user, A U Thor, who has the account author on the hosting provider git.example.org.
CONFIGURATION
What should I put in user.name?
You should put your personal name, generally a form using a given name and family name. For example, the current maintainer of Git uses "Junio C Hamano". This will be the name portion that is stored in every commit you make.
This configuration doesn’t have any effect on authenticating to remote services; for that, see credential.username in git-config(1).
What does http.postBuffer really do?
This option changes the size of the buffer that Git uses when pushing data to a remote over HTTP or HTTPS. If the data is larger than this size, libcurl, which handles the HTTP support for Git, will use chunked transfer encoding since it isn’t known ahead
of time what the size of the pushed data will be.
Leaving this value at the default size is fine unless you know that either the remote server or a proxy in the middle doesn’t support HTTP/1.1 (which introduced the chunked transfer encoding) or is known to be broken with chunked data. This is often
(erroneously) suggested as a solution for generic push problems, but since almost every server and proxy supports at least HTTP/1.1, raising this value usually doesn’t solve most push problems. A server or proxy that didn’t correctly support HTTP/1.1 and
chunked transfer encoding wouldn’t be that useful on the Internet today, since it would break lots of traffic.
Note that increasing this value will increase the memory used on every relevant push that Git does over HTTP or HTTPS, since the entire buffer is allocated regardless of whether or not it is all used. Thus, it’s best to leave it at the default unless you
are sure you need a different value.
How do I configure a different editor?
If you haven’t specified an editor specifically for Git, it will by default use the editor you’ve configured using the VISUAL or EDITOR environment variables, or if neither is specified, the system default (which is usually vi). Since some people find vi
difficult to use or prefer a different editor, it may be desirable to change the editor used.
If you want to configure a general editor for most programs which need one, you can edit your shell configuration (e.g., ~/.bashrc or ~/.zshenv) to contain a line setting the EDITOR or VISUAL environment variable to an appropriate value. For example, if you
prefer the editor nano, then you could write the following:
export VISUAL=nano
If you want to configure an editor specifically for Git, you can either set the core.editor configuration value or the GIT_EDITOR environment variable. You can see git-var(1) for details on the order in which these options are consulted.
Note that in all cases, the editor value will be passed to the shell, so any arguments containing spaces should be appropriately quoted. Additionally, if your editor normally detaches from the terminal when invoked, you should specify it with an argument
that makes it not do that, or else Git will not see any changes. An example of a configuration addressing both of these issues on Windows would be the configuration "C:\Program Files\Vim\gvim.exe" --nofork, which quotes the filename with spaces and
specifies the --nofork option to avoid backgrounding the process.
CREDENTIALS
How do I specify my credentials when pushing over HTTP?
The easiest way to do this is to use a credential helper via the credential.helper configuration. Most systems provide a standard choice to integrate with the system credential manager. For example, Git for Windows provides the wincred credential manager,
macOS has the osxkeychain credential manager, and Unix systems with a standard desktop environment can use the libsecret credential manager. All of these store credentials in an encrypted store to keep your passwords or tokens secure.
In addition, you can use the store credential manager which stores in a file in your home directory, or the cache credential manager, which does not permanently store your credentials, but does prevent you from being prompted for them for a certain period
of time.
You can also just enter your password when prompted. While it is possible to place the password (which must be percent-encoded) in the URL, this is not particularly secure and can lead to accidental exposure of credentials, so it is not recommended.
How do I read a password or token from an environment variable?
The credential.helper configuration option can also take an arbitrary shell command that produces the credential protocol on standard output. This is useful when passing credentials into a container, for example.
Such a shell command can be specified by starting the option value with an exclamation point. If your password or token were stored in the GIT_TOKEN, you could run the following command to set your credential helper:
$ git config credential.helper \
'!f() { echo username=author; echo "password=$GIT_TOKEN"; };f'
How do I change the password or token I’ve saved in my credential manager?
Usually, if the password or token is invalid, Git will erase it and prompt for a new one. However, there are times when this doesn’t always happen. To change the password or token, you can erase the existing credentials and then Git will prompt for new
ones. To erase credentials, use a syntax like the following (substituting your username and the hostname):
:Now that you are familiar with the manual you can continue with the git basics chapter.