Actions: | Security

AllGoodBits.org

Navigation: Home | Services | Tools | Articles | Other

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:

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

Sharing with other members of the same unix group

On the server

Set core.sharedrepository=group in projectA.

Make a unix group and add users to it.

Ensure that the root directory of the repo is accessible to the group:

chmod o+x /gits
chgrp -R groupname /gits/projectA
chmod g+s /gits/projectA

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:

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

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

  1. Create an account on github, provide your ssh public key.

  2. In their web interface, fork the repository you want to fix.

  3. Clone your new fork of the repository to your local system:

    git clone git@github.com:<username>/<repository>.git
    
  4. Edit, commit, push.

  5. 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.

  6. 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.