git clone

Download (clone) a copy of a remote git repository

git log

Show the commit log

git log –tags

Show the commit log and include tags in the listing

git log -n1 –pretty=format:%h-%ct

Show an abbreviated hash code and a unix timestamp of last commit

git log –oneline –graph –decorate –all

A nice view of branches, tags, and other refs.

git status

This will output some information about the state of the local copy of the
cloned repository. It reports the branch name, the number of commits that
have not been pushed, a list of files staged for commit, and a list of
untracked files.

git checkout local-branch-name

  Checkout a local branch

git checkout -b local-branch-name

  Make a new local branch and checkout the code

git checkout -b local-branch-name remote-branch-name

  Make new local branch and checkout the branch

git checkout -t -b local-branch-name remote-branch-name

  Make and checkout code for a new local branch to track a remote branch

git pull

Use this if you have no local commits that have not been pushed

git pull –rebase

Use this if you have local commits that have not been pushed

git branch

  List all local branches

git branch -a

  List all branches (local and remote)

git branch local-branch-name remote-branch-name

  Make a new local branch that tracks a remote branch

git branch –contains commit-hash-code

  Determine which branch contains the given hash code

git stash save

  Use this if you have locally changed files (not yet committed) before
  you use "git pull"

git stash list

  Show a list of stashed change sets

git stash show

  Show a summary of what files are affected by the stashed changes, a
  count of lines changed, and an indication of the number of additions
  and deletions.

git stash show -p

  Shows a patch file output of the latest stashed changes

git stash pop

If you stashed local changes before the pull this reapplies your changes

git add [file1 [file2] …]

Mark a file to be committed on next use of commit. The "git status" command
will show the added files as staged, and the staged files will not be shown
in the output from "git diff".

git add –interactive [filespec]

Interactively add (stage) files for the next commit

git add -p [file1 [file2] …]

Selectively add changes from the named files

git rm

Removes a file (or files) from the list of staged files. For unstaged files
the file(s) will be removed from the filesystem and deleted from the remote
repository.

git commit

It usually only commits staged changes if no file names are specified on
the command line. Use git add or git rm to stage changes ready for commit.

git commit -a

Files that have been modified or deleted will be staged for commit. 
Newly added files to source tree will not be staged for commit.

git commit –amend

Make changes to a commit that has not been pushed

git push [-a]

Push recent local commits to the remote git repository

git format-patch [-n]

where n is the number of recent commits to make patch files for

git am

  Apply patch(es) created by "git format-patch"

git am -3

  Update "git config" info to state command options to set autocrlf,
  user, and email.

git am –abort

Abort the patching operation and restore the original branch.

git merge –abort

Abort the current merge operation and try to restore the pre-merge state.

git clean [-df]

Get rid of files

git clean -xdf

Don't use ignore files when cleaning the source tree.
Useful when it says a merge is required to avoid clobbering some files
so it won't change branches.

git reset [–hard]
git reset [–mixed]
git reset “file”

Unstage a file so it won't be committed

git config [–global]

Automatic text file line ending conversion can be set in ~/.gitconfig
using "autocrlf = input" under the [core] section.
The user name and email to be recorded in commits can be set in the
[user] section.

Additional information:
The file .git/config has the URL for the source of the remote repository

After amending a comment for an unpushed commit that was not the
HEAD commit, use the following to fix up the log entry:

  git rebase -i HEAD~n
where n refers to the nth commit before the current HEAD commit
TODO:
- git checkout -- <some file(s) or directory>
- git commit -a
  Will record changes in directory tree (ie. files removed via rm instead of git rm).
- Add info on cherry picking commits
- Add information about deleting a branch
  git branch (-d | -D) branch-name
- Add info on marking files as binary
- Add info on ignoring certain files so they won't get checked in
- Add how to clean up after a conflict when applying an am patch
- Add information about 'gitk' and 'git gui'
- Is a rebase in progress? Check for the file .git/rebase-apply
- git --reflog -p | grep "that stuff it deleted"
  o what should be used with the grep to find changes in danger of being lost?
- git branch --track varregion origin/varregion
- Add information about git citool ?
- Add information about using --signoff with 'git am'
- Add information about using 'git format-patch #hashcode"
- Add information about setting some config options
  user.name=Real Name
  user.email=email@my.domain
  push.default=current
  core.autocrlf=input (use auto on Windows)
- git diff [--staged]

Digging through git history
- Getting a summary of the changes (ie. a patch) for a given commit
  git show <commit-hash>
- Getting a list of files changed in a given commit
  git show --stat <commit-hash>
- Finding a commit that affected files in a given path
  gitk -- plug-ins/script-fu/scripts
- Seeing when lines where changed, when, and by whom:
  git blame

Getting a clean copy of a git repo using a previously cloned copy
From Melanie:
Do you know that you can be in any directory
and make it a work tree temporarily?
  mkdir /tmp/core
  cd /tmp/core
  export GIT_DIR=/path/to/your/clone/.git
  git reset --hard
At this point, your /tmp/core is a clean work tree
you can then apply patches and commit and push.
Once you're done, simply rm -rf /tmp/core.
Having more than one clone is a much greater risk of screwups
than managing multiple work trees.
git isn't designed for more than one clone per box, not really.
They can be different versions relative to origin which isnt't good.
docs/git_survivors_guide.txt · Last modified: 2024/09/08 08:25 by admin
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Valid XHTML 1.1 Valid CSS! Best viewed with any browser Ohloh profile for Kevin Cozens Driven by DokuWiki Recent changes RSS feed