This sheet is maintained at GitHub
Here is another
cheat sheet.
And here comes the
full documentation.
How to add chmod permissions to file in GIT?
imerge: Incremental Merge
.gitignore and IntelliJ /
gitignore.io
There are four data locations:
1. | Local Workspace | Local folder tree containig the physical files under construction. |
2. | Local repository | Local branches and their modifications. |
3. | Local copy of remote repositories | All data of all configured remotes (remote tracking branches), each of them according to their last fetch date. |
4. | The real remote repositories, possibly more than one. | All data of all configured remotes, each of them according to their last fetch date. |
The one and only HEAD may be detached.
Then it points to the last revision checked out.
Further commits do not move this HEAD.
HEAD may be attached to a local branch.
Then it automatically follows all following commits of that branch.
Attaching HEAD to a remote tracking branch or a revision is not possible.
Committing changes in detached state is possible,
but the changes tend to get lost because of the missing named reference.
Show a usage page with most important options and commands.
Show all configuration values. If a configuration is shown several times, the latter takes precedence.
Show all configuration values and where they are configured.
Show the configuration options for only one config location.
local takes precedence over global, global takes precedence over system.
system: C:/Program Files/Git/etc/gitconfig
global: C:/Users/mmueller/.gitconfig
local: .git/config (default; local repo)
Configurations are never stored in remote repositories.
Suppress globally any conversion of end-of-line characters on checkout or commit.
Use the file .gitignore in your user folder globally.
Do not merge but rebase the locally committed changes, when executing a pull and fast forward is not possible.
Modify the fetch command: When fetching, also delete locally all copies of remote branches, that do not exist on server side anymore.
Use main as default branch name instead of master.
Fix the problem that the meta information is shown in black font. Here it is set to bold blue on black background.
Define a condensed format called mamue. You use it by: --pretty=mamue
Define a more detailed condensed format called mamue2. You use it by: --pretty=mamue2
Define the new command l. Now git l shows informative and compact history.
Define the new command ll. Now git ll shows informative and compact history including all remote repos and branches and tags.
Define the new command lll. Now git lll shows informative and very compact history of all remote repos including only tagged revisions and HEADs of branches.
Create a new repository in the current folder.
Clone the already existing repository to the current folder.
Set the contents of the working tree to the contents of branch master. Staged and unstaged local changes remain unchanged.
Set the contents of the working tree to the contents of revision a1b2c3d.
Throw away all local changes in tracked files (staged or not)
but do not delete any untracked files.
-f means force.
To also throw away all untracked files, do this before:
git add .
Parent of revision rev. If rev is a merge result and there are two parents, then both notations reference the first parent. That is the parent, that performed the merge operation, not the other, that was merged into the first one.
Grand-parent of revision rev. If a revision has two parents, then the first is referenced, i.e. the parent that performed the merge on that level.
Grand-grand-parent of revision rev. If a revision has two parents, then the first is referenced, i.e. the parent that performed the merge on that level.
Parent of revision rev.
If rev is a merge result and there are two parents,
then both notations reference the first parent.
That is the parent, that performed the merge operation,
not the other, that was merged into the first one.
Important: If you are working on Windows, you need to duplicacte the ^.
A single ^ in Windows is a control character that tells the comman interpreter
that the command is continued on the following line.
Second parent of revision rev.
Only valid if revision rev is a merge result, i.e. there are two parents.
Important: If you are working on Windows, you need to duplicacte the ^.
A single ^ in Windows is a control character that tells the comman interpreter
that the command is continued on the following line.
Refnames. These are examples of other valid notations of revisions.
Add all files that match the pathspec to the index.
Please keep in mind that there is a big difference, if you specify a path or not.
Move HEAD and the current branch name to point to revision 12affe / mytag / mybranch, but do not change any files in the workspace. The difference between your unmodified workspace and the GIT status is shown as untracked files or still not staged changes. If you add and commit everything, then you are back at the starting point. So you have the chance to rewrite the GIT history by rearranging the commits.
Remove all files that match the pathspec from the index. If you omit the pathspec, then all tracked files become untracked ones, the worktree will not be modified.
Set the index and the working tree back to HEAD or to revision 123affe. Untracked files may remain untracked. If needed, you have to delete them manually.
Unstage all staged changes.
Remove all not-staged modifications on tracked files. Do not touch untracked stuff.
Create a new commit that reverts all changes of the commit 1542affe. Build the commit message from the reverted commit, prepending it by the word "Revert". 1542affe must not be a merge commit.
Same as above, but 1542affe is a merge commit and -m 1 selects parent 1 (-m 2 would select parent 2) as target. To find out which is parent 1 and which is parent 2, you can use the command git log -1 1542affe. The output mentions both parents in line 2 after the key word "Merge". Parent 1 is mentioned first, parent 2 is mentioned second.
Revert all the changes contained in branch b2 but not in branch b1. Create a new commit for every reverted commit. Do this reverting in reverse order. No merge commits are allowed on the path to be reverted. If you must revert a merge commit you have to specify the parent number by option -m 1 or -m 2.
Revert the commit b1, then the commit b2. This means that ^b1 b2 is NOT the same as b1..b2 as it is in other cases!
Show what would be cleaned without the dry-run option -n.
Remove all untracked files in all subfolders (-d) and also the ignored files (-x). The force option (-f) is always required.
Display the status of all added, modified or removed files relative to the current working folder.
Display the status of all added, modified or removed files that match the pathspec in the current folder or below.
Show one page of the newest changes, the newest first.
Show the 25 newest changes, the newest changes last.
Show each change on a single line only.
Draw lines at the left to show the branches and merges.
Show also all branch and remote tags. Do not abbreviate them.
Show more commit information.
Show also the files that were modified / added / removed by each commit.
Show all commits that changed file.
Show each commit with a patch, that describes the concrete changes of this commit.
Show each commit with a list of file paths that are changed. Also show the count of changed lines. =250 is the maxwidth and may be omitted.
Show each commit with an additional line, that summarizes the count of modified files, added lines and deleted lines.
Show revision affe567 and all ancestor revisions, but except the revision bcd1234 and its ancestors and except the revision of tag tag42 and all of its ancestors. On Linux a single ^ is sufficent, on Windows you need ^^.
Show revision cafe and all ancestor revisions, but except the revision affe and its ancestors.
Show all revisions in the current branch, but except the revision affe and its ancestors. If no revision follows .. immediately, then HEAD is implicitely added. HEAD~3 has no effect here because this rev is included in HEAD.
Show all revisions, whose commit messages contain DR-360 in the current branch.
Show all revisions of the current branch as one line each containing a branch name or a tag.
Show all known branches and tags and their relations.
Show only the three given revisions but not their anchestors.
Show the history of all four branches together.
Show the youngest three revisions without using the pager (-P). Helpful if the pager is less.
Show unstaged changes.
Show the changes that you have staged, but not committed so far.
List the full paths of the changed files between revisions 0ffe
and affe
.
Prepend each line by the count of lines added and removed to that file.
A modified line is counted as one added and one removed line.
List the full paths of the changed files between revisions 0ffe
and affe
.
Append a histogram of the amount of changes at the end of each line.
1000
and 500
are just large numbers for the maximum line length
and maximum file path length, that hopefully fit all situations.
--compact-summary
just indicates after the file paths if a file is new etc.
Create a local tag on HEAD named 0.0.0
Delete the local tag named 0.0.0
Push the tag 0.0.0 to the remote repo.
Delete the tag 0.0.0 from the remote repo.
With git pull only tags are pulled that do not exist locally yet.
Local tags will neither be updated nor dropped by git pull,
so tags may remain different between the repositories even after git pull.
You have to drop all local tags before you do a git pull,
if you want to be sure that you have exactly the same tags as on remote.
Show a list of existing remotes.
Show a list of existing remotes together with their fetch and push URLs.
Add a remote with the name remote based on the URL URL.
This was already a valid URL to a local repo:
c:/Tmp/zeroMQtest/zeroMQtest/.git
After creating the project C:\dev\proj\github\myproj with IntelliJ and committing all files to the local branch main and creating the private and empty project myproj via the GitHub website, the command above connects this local git repo with the GitHub project. The next command should be git push origin main to push all local changes to GitHub.
Remove the remote with the name remote.
Show which remote branches do not exist on origin anymore and will be locally deleted, if you omit the option -n or --dry-run.
Delete locally all copies of remote branches, that do not exist anymore in the repo origin on server side.
Fetch all changes and even new branches from the repo origin. Do not move any tags. Therefore there is no kind of any merge. Only fetch, pull and push work with remote repos. All other commands work on the local repo only, even if they show "remote" tags.
Fetch all changes from all remote repos, not only from origin.
Same as fetch, but delete locally all copies of remote branches, that do not exist anymore in the repo origin on server side.
Fetch the newest revisions of the branch branch1 in the repo origin to your local copy of repo origin. Then fast forward this branch to the newest revision, if this can be done via fast forward. Report the operation as "rejected" if a fast forward is not possible, because of already committed local changes. For this operation your current branch must not be branch1.
Same as git fetch followed by git merge FETCH_HEAD. Incorporate changes from remote repo into the current branch. If the merge is successful, then there is an automatic commit.
Don't perform any autocommit, if the merge succeeds.
Update the remote branch according to the local one with the same name.
Update all remote branches according to the local ones.
Push my new branch mybranch to the remote repository origin, but do not set it as upstream branch.
Push my new branch mybranch to the remote repository origin,
and also set it as the upstream branch of my local branch.
This is the mostly used approach to publish new branches to remote repositories.
Remove the remote branch feature/CRED-11585 from the remote repository origin.
Report in detail what the push without the --dryrun would do.
List all local branches.
List all local branches, their last commit comment and hash and optionally how much it differs from the remote tracking branch.
Same as -v, but also show the remote tracking branch name.
List all remote branches.
List all remote branches whose name contains the substring "CRED-111".
List all local and remote branches.
List all branches that are merged into the current branch.
List all branches that have not yet been merged into the current branch.
Create the local branch feature/CRED-11585. To create it also in the remote repository, you need to use a git push command with the option --set-upstream.
Set origin/main as upstream branch of local branch main.
Remove the local branch feature/CRED-11585.
Remove the local branch feature/CRED-11585, even if it is not merged to master.
Remove the local copy of the remote branch origin/feature/CRED-11585 from the local repo.
If you want to remove the branch from the remote server, you have to use an according push command.
Set the branch mybranch to the revision 123affe, even if the branch mybranch already exists. If the revision is omitted, use HEAD instead.
Merge the changes of branch task/CRED-123 into the current branch.
Merge the changes of branch task/CRED-123 into the current branch only if this can be done via a fast forward operation without creating an additional commit.
Stash staged files away. Unstaged files remain untouched.
Stash all the workspace modifications away (staged and unstaged). Workspace becomes clean HEAD.
Provide a special stash description instead of the automatically generated one.
List the zero based stack of stashed change sets. With parameter -p you see modified lines.
Show the list of the staged files in last stash set.
Show the list of third youngest (2) stash set including also its unstaged (-u) files, if any.
Show the modifications (-p) in the third youngest (2) stash set.
Merge the third youngest (2) stash set (potentially including also unstaged files) into the workspace.
Merge the youngest stash set into the workspace and remove the set from the stash stack.
Remove the third youngest (2) stash set from the stash stack.
Rename the second stash (i.e. stash@{1}) to NewName via dropping and recreating it based on its former hash value.
Set the current branch to the HEAD revision of master, then re-apply all the changes of the current branch, since it was branched from master.
Pick all the changes contained in branch b2 but not in branch b1 and merge them to the branch of the current HEAD.