Notes on a Git Lifecycle
Russell Bateman
1 August 2011
last update:
|
|
Notes on a Git Lifecycle
Russell Bateman |
Here are examples of common activities you'll undertake using Git as you work. You might decide on a Git architecture and policy like this one: illustrated here.
For how to administrate Git, please see Git Administration, including panic attacks!
For peculiarities in using Git with Eclipse, see here.
Just a note...
You see git add . here and there (not a lot if at all in my stuff, just "out there"). First, be careful with that because '.' means to add everything in the current working directory and down below into the staging list (what you see when you type git status). You do not want to stage paths like build/classes, poop.txt and other temporary junk sitting around in your filesystem, etc.
Second, don't extend that to git commit ., which doesn't do anything too useful in my mind. git commit takes everything that's been staged and commit's it to the repository. Don't think of commit as having anything to do with the filesystem. It only commits what's been staged.
Just another note...
Some of your Git commands will accept --dry-run or -n. Using this option shows you what you're about to do and will help you avoid mistakes or avoid a mess you'll have to clean up. This is particularly true when it comes to "staging" commits with git add.
These are what we think are best-practice ways of using Git. This list is more or less in the same order you'd want to use the commands. Start by cloning the principal project, create your own branch thereof, update your branch with all the latest, then save your work (branch) up on the server.
There are important, omnipresent notions in using Git. Terminology appears less than fixed.
The branch you choose in Git will be the focus, or "HEAD", of anything you do per-process (per console). For example, commits always go on HEAD. If you set HEAD to one project branch, all subsequent Git commands will work relative to it. In general, it is not a good idea on a routine basis to be constantly moving HEAD. Focus on your private Git branch and only juggle HEAD when you are merging down from or up to another. At the end of your merging process, reset HEAD to your private branch before continuing to make source-code changes, add files to staging or commit them. The Git HEAD is set using the git checkout command. To see what the current branch you're focussing on is, use git branch with no argument and look for the asterisk.
You'll see "HEAD" used in Git documentation as well as the output from the very helpful git status
Staging is an implicit changelist of files that are eligible (and likely) to be committed to the branch of focus. This is accomplished using the Git commands git add and git commit To unstage a file you've added (but not yet committed), use one of these:
$ git reset $ git checkout --
(For more on this, see Undoing in Git - Reset, Checkout and Revert.)
One potential source of headache in Git is how merging works. This is explained in Basic Branching and Merging, but the template below may go a long way to elucidating your confusion when you issue the command:
$ git merge [from] <branch> [into HEAD]
You work in a branch in Git. Every operation is relative to some branch (usually one, but some operations can be between two branches). One scheme for organizing your work between branches is illustrated here.
Also simply called "remotes", remote repositories are ones that live remote from your development host. The most obvious one is called origin. The (remote) repository is not the same thing as the branch inside it. Therefore, origin is not the same thing as master. See Working with Remotes.
Also called a “cloned repository” or “local repository”. This is the copy of origin you make locally to work on via a chosen branch.
This file is crucial to your Git activities unless you're careful about making assumption when you add, remove or otherwise make changes to large numbers of files in your subdirectories. To shelter any file or subdirectory from being tracked by Git, create this file at the root of your project and place these files and subdirectories on separate lines.
Here's some stuff that I need to put somewhere or throw away; (how I got rid of the .settings subdirectory without deleting it from the filesystem).
$ git rm -r --cached .settings