Setting Up a Remote git Repository

Paul — Wed, 15 Sep 2010 19:48:34 +0000

There’s no substituting for git help remote. The following is a common situation. It assumes that reponame.git does not exist on the remote machine and that you’re in a hurry to get things done.

 // The remote repo
 mkdir reponame.git
 cd reponame.git
 git init --bare
 cd ..
 scp -r reponame.git server.com:/path/to/reponame.git
 rm -r reponame.git

 // Optional: add existing code
 cd code
 git init
 git add *.c *.h Makefile
 git commit -m "initial import"
 // if you somehow already have a remote, first issue `git remote rm origin`
 git remote add origin ssh://server.com/path/to/reponame.git
 git push origin master

 // Clone remote repo to local system
 git clone ssh://server.com/path/to/reponame.git
 // ... now get to work!

Git: Recovering a file that you deleted

Paul — Wed, 10 Mar 2010 21:02:36 +0000

You might be doing some spring cleaning to your source code, or you might move files around that you think are unnecessary. Later on, you realize that one of the files you removed was a dependency. Now what? For this, we use git checkout.

If this is you:

...edit files...
git add edited-file
git commit -m "made changed"
git rm seemingly-useless-file
git commit -m "removed unreferenced dependency"
... edit file ... realize you dynamically included that file elsewhere..

Then you can simply follow up with:

git checkout 0a323 // the previous revision (hash from `git log`)
cp seemingly-useless-file seemingly-useless-file.1
git checkout master
mv seemingly-useless-file.1 seemingly-useless-file
git add seemingly-useless-file
git commit -m "Restored seemingly-useless-file"

You may want to git blame yourself while you’re at it.

If you know of a better way, please let me know.

Untrack Files with Git

Paul — Wed, 09 Dec 2009 04:22:21 +0000

When I found this little gem, I couldn’t not (double negative for emphasis) store it for reference.

git rm --cached filename

Don’t worry, it won’t remove your local copy. It just stages it for removal from the history of tracked files.

Reference:
untrack files in git

Git – Install and Configure

Paul — Wed, 04 Nov 2009 23:19:50 +0000

Git is a code revision system not much unlike subversion and CVS. One of the best features of git is that it is a distributed revision system, so you can check-in, check-out, commit, revert, etc without ever needing direct access to the central repository. You can work with your repository as if it were a centralized system if need be found.

Installation (from source)

Go to http://www.kernel.org/pub/software/scm/git/ and pick the latest version (1.6.5.2), then from the command line, issue:

# Make a temporary directory from which we'll work mkdir ~/gittmp cd ~/gittmp
# Get the source, compile and intsall wget http://www.kernel.org/pub/software/scm/git/git-1.6.5.2.tar.gz tar xzf git-1.6.5.2.tar.gz cd ~/gittmp/git-1.6.5.2 ./configure make sudo make install cd ~/gittmp
# Get and install the man pages wget http://www.kernel.org/pub/software/scm/git/git-manpages-1.6.5.2.tar.gz sudo tar xzf git-manpages-1.6.5.2.tar.gz -C /usr/local/share/man/ cd ~ rm -r ~/gittmp/

Testing

Now that we’ve got everything set up, go ahead and check that everything’s visible to your path. Note: You may need to log back in for the settings to be read.
$ which git /usr/local/bin/git $ git config --help --- man page retrieved ---

Configuration

Now we need to set some globals. These are used to identify you when pushing changes.
$ git config --global user.name "Scott Chacon" $ git config --global user.email "schacon@gmail.com"

In a distributed environment, your workflow might go something like: A writes some code and commits. B pulls code, makes updates, commits. A updates local copy with B’s committed changes, continues development. The flow goes: get updates from peer, make changes, commit. Here’s an example:
alice: $ cd ~/project alice: $ git init alice: $ git add lib src README CHANGELOG alice: $ git commit -m "Initialization" bob: $ git clone /home/alice/project myrepo bob: $ echo 'I made a change' >> CHANGELOG bob: $ git commit -a -m "Appended changelog info" alice: $ cd ~/project alice: $ git pull /home/bob/myrepo master alice: $ echo "Confirmed, changes were merged" >> CHANGELOG alice: $ git commit -a -m "Merged bob's changes with some new additions"

Another setup might be to have a public repository for centralized access. It’s not really a central repository, but it’s the place where you push all your changes to from any machine you work on. In this way, anyone can go to exactly one place to get changes you’ve made, and you can work from any machine with git, using your own public repository as a starting point.
$ git clone --bare ~/proj proj.git $ touch proj.git/git-daemon-export-ok $ scp -r /proj.git user@host.com:/path/to/proj.git
Want to have access to the repo via http? Try this:
$ mv proj.git /var/www/html/repos/proj.git $ cd /var/www/html/repos/proj.git $ git --bare update-server-info $ chmod a+x hooks/post-update
Now anyone can access your repository like so: $ git clone http://example.com/repos/proj.git

Prefer a private repository? It’s easier than the public setup.
You: $ git clone --bare /home/user/myrepo/.git /tmp/myrepo.git $ scp -r /tmp/myrepo.git myserver.com:/opt/git/myrepo.git
Peer: $ git clone myserver.com:/opt/git/myrepo.git

So how do these shared repositories work?

clone to initialize local git revision management
modify/commit/revert/etc locally (1 or more times)
push up to the shared repository

Peer: … makes changes to source …
Peer: $ git commit -a -m "I made a few changes"
Peer: … continue editing until ready for consumption …
Peer: $ git commit -a -m "I made a few more changes"
Peer: $ git push ssh://yourserver.com/~you/proj.git master[:master]
You: $ git clone myserver.com:/opt/git/myrepo.git
You: … editing/conflict management/etc. …
You: $ git commit -a -m "Pretty up peer's changes (minor edits)"
You: $ git push ssh://yourserver.com/~you/proj.git master[:master]

Using Git on Windows

If you plan on using Git on Windows (Sure, why not? masochists pssht) you could install Git Extensions (Windows) from http://git-scm.com/tools. At least, that’s what I did. It was confusing as all hell, until I went through all possible alternatives that appeared easier than understanding what a remote is. The key to getting it all to work is setting up ssh keys so that you can auto-logon to whatever server has your git repositories with the ssh protocol. If you’re using the git protocol, I don’t think that applies. I could be wrong on this.

Once you’ve installed Git Extensions, load it up, do some general configuration (user.name, user.email, etc.), then select from the menu bar Remotes->PuTTy->Generate or import key. This assumes that you’ll be using PuTTY for all your ssh needs (if applicable). Anyway, generate a key and save the public key somewhere handy, save the private key somewhere safe. Now, using that pubkey, follow the advice for Setting up SSH Keys. You’re going to want to add that pub key to your authorized_keys on the git repo server. After that, make sure the PuTTY authentication agent is running (Remotes->PuTTy->Start authentication agent). A new icon should appear in your system tray. Right click on the new icon to “Add Key.” This key will be your private key. The agent handles the hand-shaking.

After doing all this the hard way, maybe you should just use the git protocol, but then again, I haven’t tried it myself.

Resources

Finally, it’s probably best to read Git’s HOWTOs and Tutorials.

cat brain.log | less » git