Getting started with Git+FubuMVC on Windows

[Chad Myers]

SETTING UP YOUR PRIVATE FORK (ONE TIME ONLY)

Description: In git, you don't work off the main repo. You fork it into your own repo, work there, and then send "pull requests" to the main. One of the main committers/maintainers will then review your request and "pull" it into the mainline repo.

1.) First, create a Github account (www.github.com) if you don't have one already.

2.) Fork the FubuMVC repository via your web browser from here:

http://github.com/DarthFubuMVC/fubumvc

NOTE the "Private" git address for this repo. It should be something like:

g...@github.com:chadmyers/fubumvc.git

SETTING UP YOUR LOCAL DEV ENVIRONMENT (ONE TIME ONLY)

Description: Get git up and running locally so you can pull down the source and contribute to your own repo.

1.) First, get Cygwin + Git (or you can use msysGit, but I did the Cygwin one and it works):

http://airto.hosted.ats.ucla.edu/wiki/index.php/Setting_Up_and_Using_Git#Installing_CygWin_.2B_GIT

2.) Open a cmd.exe and type "git". It should say something other than "git is not recognized blah blah blah".

3.) Set git with some global defaults:

From a command-line, type:

git config --global user.name "Your Name"

git config --global user.email "Your Email {preferably the same one you used to set up your github account}"

git config --global core.autocrlf false

4.) Create your public/private keypair and associate it with your github account (Git uses keys for authentication)

http://help.github.com/msysgit-key-setup/

That link/guid is for msysgit, but the process is the same with Cygwin+Git.

GETTING YOUR REPO (ONE TIME ONLY)

Description:  This will pull down the code from Github locally so you can work with it and start the normal everyday Git workflow

1.) Open a command-line and CD to your code folder (where you keep all your other projects)

2.) Remember your private git address for your repo/fork?  You'll need that now.

3.) Type:  git clone YourPrivateGitAddress

It should now start pulling down your repo. It was most likely named 'fubumvc', so it'll create a 'fubumvc' folder under your code folder.

4.) CD to the fubumvc folder.  Do a 'dir' and you should see things like "src" dir and "Rakefile".

5.) Type "rake" and it should build and run all the tests.  If Rake doesn't work, then you don't have Ruby set up properly. That's OK, just open Explorer, go to the fubumvc folder, then to the "src" folder, then open the FubuMVC.sln file and try to build it in Visual Studio.

[Josh Flanagan]

I assume I'm not the only git noob on the list, so I figured I'd chime
in with a couple tips that I've learned that have made my git adoption
smoother.

1) Pay attention to Chad's advice to set autocrlf=false. There is a
lot of confusing information on the "git for windows" tutorials that
are out there, and many suggest you enable autocrlf. What I've come to
understand is that really only applies if you are committing to a
linux based project (like, say, the linux kernel). If you are working
mostly on Windows-based projects, you dont want git's "help" in
"fixing" your files. Setting autocrlf=false tells git "leave my files
alone, I like the line endings exactly how they are".

2) Always work in a branch locally. After you clone the repo and
before you start making any changes, create a branch. Once you are
happy with your changes, merge your branch back into master, and then
push master to your remote repo.
This gives you at least 2 benefits that I've found useful:
- if you want to throw away your changes, just switch back to master
and delete that branch. I know there is a way to do it, but I've had
so much trouble trying to tell git to throw away my recent changes.
Just blowing away the branch is easy and works.
- if you want to work on a different task that is a tangent from your
original task, just switch back to master and create a new branch. It
wont have any of your in-progress changes from the first branch. This
allows you to commit the work from the 2nd task before finishing the
1st task.

> --
> You received this message because you are subscribed to the Google Groups
> "FubuMVC Development Group" group.
> To post to this group, send email to fubumv...@googlegroups.com.
> To unsubscribe from this group, send email to
> fubumvc-deve...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fubumvc-devel?hl=en.
>
>

[Ben Keeping]

Just some thoughts from another GitHub / git noob :

I didn't fancy installing cygwin, so I used with no problems msysgit
http://msysgit.googlecode.com/files/Git-1.6.5.1-preview20091022.exe

When you create your GitHub account, I'd create your SSH/RSA key
before forking the fubumvc repo, because it needs it. If you don't,
its OK, you just have to go to the Admin settings on your GitHub
account and add a new key.

If you've not installed Ruby (and Rake) before, then you need to do a
"gem install rubyzip" before you build the src, else it will error
with a "cannot find zip/zip" thing.

[Chad Myers]

Side note about the rubyzip thing:

Run "installgems.bat" in the FubuMVC root dir and it should load all the gems necessary to Rake fubu (and probably a few others)

-Chad

[Chad Myers]

Thanks Josh!

One quick additional point for Git noobs:  Git's main power is in branching.  If you abhorred branching in VSS, and tentatively did it in SVN (but it was still somewhat painful),  Git makes branching very near pain-free. Branching is a main part of the day-to-day workflow of Git.  Use it liberally and don't be afraid.

-Chad

[Paul Batum]

An approach I've found useful when working on Fluent NHibernate as a contributor and NOT the official repository owner is to never commit to the master branch. I update it as changes are made to the official repository, but all my commits are done on a seperate "dev" branch (or other fine-grained branches made off of the dev branch). When I have a batch of changes I send James (the official repository owner) a pull request pointing at my dev branch. The advantage of this approach is that it guarantees that the history of my master exactly matches the history of the official repository.

I also make extensive use of the rebase command, to make my commits a simple linear sequence. So if my local dev branch has some changes and then James updates the official repository, I'll pull his changes into my master. Then I will rebase my dev branch onto the master, so that it looks like I made my changes AFTER getting James's changes (when in reality they were made beforehand). Now when I push my dev branch to my github repository and send James a pull request, my changes go straight in, no need to merge.

Keep in mind that git is flexible enough that you can basically design your own workflow. Don't take the approach I've outlined above as gospel. Its just one possibility.

Hope this made sense. I'd be happy to elaborate further if necessary :)

Oh and one more thing. There are heaps of git resources about on the web. This video is the best one I've found so far for understanding how git works, and how to work with git:
http://www.gitcasts.com/posts/railsconf-git-talk


Paul Batum