Git Cookbook: Difference between revisions

From Littledamien Wiki
Jump to navigation Jump to search
Line 71: Line 71:
* See also <code>[http://git-scm.com/book/en/Git-Branching-Rebasing git rebase]</code><br />Which does the same thing as <code>git merge</code> but in a slightly different way that is helpful to maintain a linear set of changes when merging two branches together.
* See also <code>[http://git-scm.com/book/en/Git-Branching-Rebasing git rebase]</code><br />Which does the same thing as <code>git merge</code> but in a slightly different way that is helpful to maintain a linear set of changes when merging two branches together.


==Commmiting changes==
== Commmiting changes ==
 
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
$ git co myBranch
$ git co myBranch
Line 82: Line 83:


See the [http://wiki.mediabistro.net/index.php?title=Git#Merging_branch_to_preview Mediabistro wiki] for instructions on how to put the changes on 'preview'.
See the [http://wiki.mediabistro.net/index.php?title=Git#Merging_branch_to_preview Mediabistro wiki] for instructions on how to put the changes on 'preview'.
=== Maintain different `.gitignore` files for development/production ===
'''Goal:''' Push a set of files to production that doesn't include non-public things like sass files, etc.
Maintain a "development" branch that has a different version of `.gitignore`, or even a different set of files.<ref>[http://stackoverflow.com/questions/10475273/git-have-different-gitignore-file-for-each-remote Git Have Different .gitignore File for Each Remote] (Stackoverflow)</ref>
<p class="alert-warning">I haven't attempted to work out the details of how this could work, but it seems promising.</p>


== Reports and diffs ==
== Reports and diffs ==

Revision as of 19:10, 3 March 2015

Overview

Git cheatsheet.

Staging files

Stage a file or files

$ git add [path]

Stage all files

What this won't do is stage deletes.

$ git add ./

To stage everything including deleted files:

$ git add -A

Unstaging and reverting

Unstage a file or files

This will unstage the file, but edits that have been made to the file will remain unchanged.

$ git reset [path]

Note: git reset as described above will throw this error prior to the initial commit:

fatal: Failed to resolve 'HEAD' as a valid ref.

If files have been staged prior to the initial commit, then

$ git rm --cached [path]

Reverting file edits

$ git checkout HEAD [path]

Syncing a repo with subsequent changes to the master

Scenario: Create a branch, make edits. In the meantime other work is being done by other members of the team. The time comics to push your changes out. The goal is to merge their changes into yours locally then push it all out.

  • See what files have been touched:
$ git status -s
  • View (unstaged) edits for a specific file:
$ git diff -- [path]
  • Switch from the local branch to 'master'.
$ git co master
  • Merge the updated local 'master' with the local branch, resolving any conflicts:
$ git branch
* master
  mybranch
$ git co mybranch
$ git merge master
  • See also git rebase
    Which does the same thing as git merge but in a slightly different way that is helpful to maintain a linear set of changes when merging two branches together.

Commmiting changes

$ git co myBranch
$ git status -s
  # add any files that need to be added to the commit
$ git commit -m 'commit message'
  # the "commit message" is required
$ git push origin myBranch

See the Mediabistro wiki for instructions on how to put the changes on 'preview'.

Maintain different .gitignore files for development/production

Goal: Push a set of files to production that doesn't include non-public things like sass files, etc.

Maintain a "development" branch that has a different version of .gitignore, or even a different set of files.[1]

I haven't attempted to work out the details of how this could work, but it seems promising.

Reports and diffs

View all branches and commit messages:

$ git log --oneline

View commit messages for a single branch:

$ git log --oneline [branchname]

View the files touched between two commits

Where you include just enough of SHA1 and SHA2 to identify the commits (usually about 4 characters).

$ git diff --name-only SHA1 SHA2

View all files modified by the commits in a single branch

$ git diff --name-status master..<branch>

View all commits for a single file

$ git log --oneline <path>

View changes in a single file between two branches

$ git diff <branch1>...<branch2> -- <path/to/file>

Create a patch file for work done in a git branch

To get all the changes after a specific commit:

$ git diff -p <commit_string> > <path/to/patchfile.patch>

Or between two specific commits (the newer one goes first):

$ git diff -p <newer_commit_string> <older_commit_string> > <path/to/patchfile.patch>

(To narrow it down to a specific file, see the 'git diff` example above.)

$ git diff -p <branch1>...<branch2> > <path/to/patchfile.patch>

Applying a patch created with "git diff"

$ patch -p1 < <path/to/patchfile.patch>

If the directory structure is different, say if you are editing myapp2/path/to/file_to_edit.py using changes made to myapp1/path/to/file_to_edit.py then enter the new path when prompted by the patch program.

Managing files

Rename a file

$ git mv <src_name> <dst_name>

Stashing files

Stash changes during a commit or checkout

$ git stash

Get a list of stashed files

$ git stash list

Apply the latest stash

$ git stash apply

Apply the stashes farther down on the stack

$ git stash apply --<index>