Cacher is the code snippet organizer for pro developers

**After completing a task** (bug or feature), merge with master and delete that branch:
`git checkout master`	switches to master branch
`git merge hotfix`	merges hotfix branch _into_ master branch
`git branch -d hotfix`	deletes hotfix branch (eg if already merged with master)

NB!  Branches cannot be switched if working directory or staging area has *uncommitted changes that conflict* with the branch being checked

<font color=>Merge conflicts                                       merge conflicts
 Fix / merge conflicting parts manually or use a visual merge tool: git mergetool  

<font color=>Branches                                   switching and merging branches

Master branch should always contain only production-quality (live) code.
That means, for (any) new work:

• only commit changes in/to master if they are finished (ready to deploy)
• for any feature, make a new branch, and when ready (to deploy), merge the branch with master and delete it (if the feature is dependent on another module, use its branch as parent (eg development)
• feature branches should be descriptive (eg refactor-authentication, user-content-cache-key, make-retina-avatars)

<font color=>Commits can bewritten to include Github issues, eg
<font color=><h3> was being closed by an </h2>. Updated to valid HTML. Fixes #9196.

<font color=>Images and version control:  if they are part of a project, they should be in a VCS. Eg with git-annex.

<font color=>Manage large files with git-annex:  is used for managing files with git, without checking the file contents into git.

<font color=>Last commit can be taken back with git reset.

Combining multiple git repositories link link link
Git aliases link

If want to have several unrelated projects in one remote repo, use different branches:
If you already have separate projects locally, create orphan branch (see below) for the project and use git push origin remote-branch-name:local-project-name to push it to remote.
Otherwise, while, for new projects, you can create separate branches (unrelated to others) right in the local parent repo with git checkout --orphan <local-project-name>, you can't access them at the same time. So, unless you prefer that (is more compact), it's better to create separate folder for every project and push to remote from there (first command).
Later cloning into a separate folder: git clone url -b <project-branch> <local-project-folder>
git reset vs reset vs checkout

.gitattributes and dealing with EOLs (includes a basic .gitattributes file)

Open commit in browser:   github.com/mhpreiman/projectName/commit/hashNumber   (hash can be abbreviated)

Commit examples:

Update homepage for launch
Fix typo in screen.scss
Fix mispelled name on about page

<font color=>My git commands: 

`git log` --reverse --pretty=format:"%h %ad   %s" --date=format:"%H:%M  %d.%m.%y"

outputs

4b8cf52 16:10   06.12.16   Initial commit.

[see % options](http://stackoverflow.com/a/34778736)

Pull request:  a way to ask another developer to merge one of your branches into their repository

Forking:  copying another user's public repo (which you can only read but not write) to your own account to be able to make changes
After pushing changes to your forked repo, it's possible to make a pull request from the original repo in order to let the author add (or reject) your changes into their repo.

Submodules:  projects within a project (some other repo (eg a library) as a directory in your repo)

<font=darkcyan>What is origin in git?

Bare repository:  a git repository without a working copy. Use a non-bare repository to work locally and a bare repository as a central server/hub to share your changes with other people.
(eg in git init --bare or git clone --bare)

Index:  a staging area where new commits are prepared (where you place files you want committed to the git repo)

HEAD:  current branch or last committed state on current branch

Working tree:  the state of files in checkout (consist of files that you are currently working on)