git

Revision as of 23:09, 22 November 2008 by VartanSimonian (talk | contribs) (Branching)



How we use git

Task How we're doing it now How we think we should be doing it How Randal thinks we should do it
Deployment Use Capistrano recipe to invoke git on each production server. (1) clone the live repository into a new, never again touched repo (uniquely numbered) (2) symlink "current" to the new numbered repo Tag the commits, use git archive on the tag, or if we use tags we can browse our history forward or backward ... or do a lightweight clone git clone -s (--shared) or something like that so that it uses the first clone's object tree
Branching Create an entirely new repository using git clone on repository coordination server we call this a branch branches are really a name for a commit ... commits on top of commits ... names are illusionary ... work in a way that linearizes commits (use rebase) use git fetch, never pull (get rid of it from your vocabulary) ... git pull is fetch plus merge ... get rid of merge from your vocabulary
Staging Checkout the "branch" repository locally, work in it and push changes to share with other developers ... each branch is locally accessible via the webserver on the local machine under the branch name. For exampl http://urlmagic is the locally staged urlmagic branch
Merging Pull from live by hand into the branch as you are working. Pull into live. Fix any conflicts. Run the test suite. Push into live. Deploy. Git rebase -i

Vocabulary

See the git glossary for details

Novice (general terms that are not git specific)

  • scms
  • repository
  • working directory
  • SHA1

Advanced beginner (terms specific to git)

  • repository
  • object database
  • working directory
  • reference (ref)
  • symbolic reference (symref)
  • SHA1
  • clone
  • commit
  • push
  • pull

Competent

  • index
  • head
  • remote
  • refspec
  • blob object
  • tree object
  • commit object
  • tag object
  • branch
  • fetch
  • merge
  • master
  • origin

Expert

  • pack
  • rebase
  • rewind
  •  ???

Master

  •  ???

Configure

$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email 

Branching

[on nimbus]
cd /opt/git/aboutus-merged
git branch BRANCHNAME

[on local box]
cd ~/git/aboutus-merged
git branch BRANCHNAME
git pull origin BRANCHNAME

[to push]
git push origin BRANCHNAME

[to pull]
git pull origin BRANCHNAME

[to merge]
git checkout BRANCH-TO-MERGE-TO
git pull . BRANCH-TO-MERGE-FROM
...
(if necessary)
git commit -m "successfully merged BRANCH-TO-MERGE-FROM into BRANCH-TO-MERGE-TO"

.gitrc

[user]
        name = Brandon CS Sanders
        email = <email>25cabbaf80e6a421007cc77e456b0902</email>
[color]
        status = auto
        diff = auto
        branch = auto
[merge]
        tool = opendiff
[core]
        excludesfile = /Users/brandon/.gitignore

Checkout

git clone  name

Checks out a copy of repo into the named directory

git clone nimbus.aboutus.com:/opt/git/aboutus aboutus-1.10.0

you'll want to edit .git/info/exclude and add at least LocalSettings.php, don't know how we can get these transmitted automatically

Status

git status

Diff

git diff
git diff --cached

Update

git pull

Commit

git commit -a -m "commit message"

This will commit the changes to your local repository.

make *sure* you check status first, this will add all new files and commit them to your local repository.

If you don't want to use -a (probably a good idea) then run git add for each file you want to update before you run git commit.

Yes, that means that you have to git add a file every time you modify it, even if the file is already being tracked.

Push

git push origin
git push #This defaults to push to origin

will push all commited patches you have on your local repository to the shared one you checked out from

Revert

for CVS style revert, i.e. to replace a fie with what it was before you changed it:

git diff filename | patch -R -p1

or

git checkout filename


making gitk not ugly

Add these lines to your ~/.gitk file. Apparently only the first three lines are really necessary. From http://scie.nti.st/2006/12/20/gitk-on-mac-os-x-screenshot

set mainfont {Arial 12}
set textfont {"Courier" 12}
set uifont {Arial 12 bold}
set findmergefiles 0
set maxgraphpct 50
set maxwidth 16
set cmitmode patch
set wrapcomment none
set showneartags 1
set bgcolor white
set fgcolor black
set colors {green red blue magenta darkgrey brown orange}
set diffcolors {red "#00a000" blue}
set permviews {}

For colored output

execute these commands:

  • git config --global color.branch auto
  • git config --global color.diff auto
  • git config --global color.interactive auto
  • git config --global color.status auto

Make a new Shared Repository

$ mkdir new_shared_repo
$ chown jason.developer new_shared_repo
$ chmod g+s new_shared_repo
$ cd new_shared_repo
$ git --bare init --shared
$ git --bare fetch /home/jason/new_project master:master

Branches via Multiple Repository

  • make a new shared repo, cloned from the main repo
  • developers on the branch clone from the new repo, and only push / pull to that
  • to bring the branch up to date with changes to trunk, do a git pull and specify the trunk repo location

Things to Research

  • how to revert a messed up merge between branches (can't revert multiparent commit)
  • git seems to love branches but we aren't really using them ... what don't we know about branches that maybe would be helpful in the future?


Retrieved from "http://aboutus.com/index.php?title=git&oldid=17027352"