Starting with Git

There are many articles about git, but most of them are far too complex for my meager needs. There are too many different ways to do things, so much like some of my other articles, I'm collecting here what I have done so I'll be able to do the same thing again next time.

I like to have a central repository server, for various reasons:

granting access to others is fairly straightforward, without having to use a hosted solution

centralised backup, centralised hooks

I don't have to worry about cloning/pushing/pulling from systems that might (sometimes) be behind NATs or otherwise inaccessible

Creating a new repository

This step is optional, you might be cloning from a different repo.

mkdir projectA
cd projectA
git init
echo '## ProjectA ##' > README
git add README
git commit -m'README: Started a new project'

Enabling distribution

On the server

mkdir /gits/projectA && cd /gits/projectA
git init --bare

On a client with an existing repo

cd gits/projectA
git remote add origin ssh://server.example.com/gits/projectA
git push origin master

Append to .git/config

[branch "master"]
      remote = origin
      merge = refs/heads/master

Create/use a new repository from an existing remote location

Initially, you need to fetch the repository from the central server:

git clone ssh://server.example.com/gits/projectA

Then your edit cycle looks like this:

Update:
```
git pull
```
Make edits and commit:
```
git commit
```
Push your commits to the central server:
```
git push
```

That's it! That's as simple a workflow as you can get. Another possibility is that you want:

git pull --rebase

This ensures a linear revision history which is rather easier to follow and possibly makes things simpler for team environments.

Branches

If you want to use branches, there's a little more

show branches:
```
git branch -a
```
checkout branches:
```
git checkout new_branch
```

create and push a new branch:

git checkout -b new_branch
git push -u origin new_branch

checkout an existing branch:

git checkout -b a_branch origin/a_branch

merge a branch into your current branch:
```
git pull origin a_branch
```

Commit messages

Since commit messages are used to generate emails, they should follow a format of change summary,blank line, more detail:

<Short summary>

<Detailed description>

Code Reading

If you're like me, you spend more time reading code than writing it. Similarly, you might well spend more time looking at the repository than actually changing it.

File changes

To see what changed since a particular commit:

git diff <commit_id>

To limit that to a particular file or directory:

git diff <commit_id> -- <path>

The commit reference can be relative: -2

Repository History

I find this convenient as a default to view the repository history. I get compact output which tells me which files were added/modifed/deleted in each commit:

git log --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative --name-status

I define an alias for this in my .gitconfig:

[alias]
  l2 = log --pretty=format:'....

Branch/merge history can be envisioned with --graph

Basic Github.com activity

Create an account on github, provide your ssh public key.
In their web interface, fork the repository you want to fix.
Clone your new fork of the repository to your local system:
```
git clone git@github.com:<username>/<repository>.git
```
Edit, commit, push.
In their web interface, go to your fork of the repository, click 'Pull Request' and make a useful comment describing what you fixed, to make it easy for the puller/gatekeeper to know what you did.

Add the original repository as a remote to your local repo, so that you can easily keep up to date with their development:

git remote add upstream https://github.com/<upstream_user>/<repository>.git
git fetch upstream
git merge upstream/master

Then, once you get comfortable the next habit to form to ease collaboration in public projects is to use topic branches.

AllGoodBits.org