In a corporate environment, set the internet proxy: git config --global http.proxy http://proxy.northwind.com:80
With username/password: http://user:[email protected]:80/
If the username is in the format "[email protected]", encode the "@": http://user%40corporate.com:[email protected]:80/

Github for Windows includes a credential helper, so you don't have to keep typing in username/password on the command line for https: just write once git config --global credential.helper wincred

Files and (local) commits

Files are staged (tracked by git) before they are committed.

git init to create a new repository,
or git clone https://github.com/xxxx to create a local copy of an on-line one.

git status status of a directory, git diff --staged for diffs

git add readme.md start tracking a file (or a folder recursively)
If you've cloned, everything is automatically tracked
You can use wildcards: git add *.cs
You can undo the tracking: git reset HEAD *.cs

ignore files with a .gitignore.

git commit -m "my commit" commits staged changes to local repository
You can skip staging with -a : git commit -am "my commit"
If you omit the -m, you go into vim (see above to change the editor)git log shows the commit history.git commit --amend amends the last commit (so have less commits in history- esp for fixing merges)

Check in

A push is like a branch merge, but you can only do fast-forward merges. The more common workflow is to do a pull request (not actually a command, but github has a great UI to do it)

Branches

The default remote server and branch are called origin/master.

A cloned repository has 2 pointers: the local branch "master" and the remote branch "origin/master"

The pointer to the current branch is called HEAD

One strategy is to have a long running develop branch, and periodically "release" by merging into master.
Short-lived topic branches can exist for specific issues.

Unlike Subversion/TFS, you don't branch to a new folder with a different set of files. It's the same folder as the trunk ("master").

git branch branchname creates a branch (but does not switch to it).

git checkout branchname switches to a branch (points HEAD to branch).git checkout -b branchnamecreates and switches to a branch.

git merge branchname to merge branch into current branch.
A "fast forward" is a simple additive merge. Otherwise you have a new "merge commit" which is a special commit containing the sum from both branches (a "3-way merge" as there are 2 branch parents and a new commit).

Merge conflicts can be edited, then run git add filename to mark then merged.

A rebase is a type of aggressive merge, in which one branch is "replayed" over the other. This means the merge is a "fast forward" and the history is cleaner. Don't rebase commits that have already been pushed to a remote.

Workflow

Gitflow (master branch is static, production; everyone branches off "develop" branch and merges into "release" branch(es) which in turn merge into master). Yes, this is complex.

Github flow (master is always deployable; branch + pull requests; after merge, deploy). For continuous deployment, and much simpler than gitflow. Variations include making release branches when deploying.

Centralized

This is the closest to centralized subversion/TFS source control, is simple and works

Create central repo.

Clone it locally. git clone https://....

Work locally. git add readme.md, git commit -m "my commit"

Push to central repo. git push origin master

Fixes:

if there is a merge problem, update from the central repo: git pull --rebase origin master
Resolve issues, then git push origin master

If you forgot to include files, git add etc, then git commit --amend to amend the commit

To squash several commits into one (simplify history), do an interactive rebase git rebase -i
pick the first, then s[squash] the other commits (or fixup to discard commit messages).

To sync the latest changes from origin (or upstream),

git fetch upstream Gets the changes

git rebase upstream/master Reapply all the changes onto the master

git rebase --continue over all conflicts

Feature branches

For each piece of work, create a branch. git checkout -b mybugfix master

You can push to master in a branch. git push -u origin mybugfix
After the branch is created, it is tracked, so just git push

Make a pull request

Any further work in the branch is automatically added to the pull request

Finally, git checkout master, git pull origin mybugfix, then git push

Tricks

You can create a windows batch file with git commands, but each command should be "call git", not just "git..."