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.
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.
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)
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.
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.
On Tue, Jan 12, 2010 at 12:38 PM, Chad Myers <chad.my...@gmail.com> wrote: > 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_... > 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.
> -- > You received this message because you are subscribed to the Google Groups > "FubuMVC Development Group" group. > To post to this group, send email to fubumvc-devel@googlegroups.com. > To unsubscribe from this group, send email to > fubumvc-devel+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/fubumvc-devel?hl=en.
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.
> 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.
> -- > You received this message because you are subscribed to the Google Groups > "FubuMVC Development Group" group. > To post to this group, send email to fubumvc-devel@googlegroups.com. > To unsubscribe from this group, send email to > fubumvc-devel+unsubscribe@googlegroups.com<fubumvc-devel%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/fubumvc-devel?hl=en.
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
On Tue, Jan 12, 2010 at 1:07 PM, Josh Flanagan <joshuaflana...@gmail.com>wrote:
> 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.
> On Tue, Jan 12, 2010 at 12:38 PM, Chad Myers <chad.my...@gmail.com> wrote: > > 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_... > > 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.
> > -- > > You received this message because you are subscribed to the Google Groups > > "FubuMVC Development Group" group. > > To post to this group, send email to fubumvc-devel@googlegroups.com. > > To unsubscribe from this group, send email to > > fubumvc-devel+unsubscribe@googlegroups.com<fubumvc-devel%2Bunsubscribe@goog legroups.com> > . > > For more options, visit this group at > > http://groups.google.com/group/fubumvc-devel?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "FubuMVC Development Group" group. > To post to this group, send email to fubumvc-devel@googlegroups.com. > To unsubscribe from this group, send email to > fubumvc-devel+unsubscribe@googlegroups.com<fubumvc-devel%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/fubumvc-devel?hl=en.
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
On Wed, Jan 13, 2010 at 7:10 AM, Chad Myers <chad.my...@gmail.com> wrote: > 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 > On Tue, Jan 12, 2010 at 1:07 PM, Josh Flanagan <joshuaflana...@gmail.com> > wrote:
>> 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.
>> On Tue, Jan 12, 2010 at 12:38 PM, Chad Myers <chad.my...@gmail.com> wrote: >> > 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):
>> > 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.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "FubuMVC Development Group" group. >> > To post to this group, send email to fubumvc-devel@googlegroups.com. >> > To unsubscribe from this group, send email to >> > fubumvc-devel+unsubscribe@googlegroups.com<fubumvc-devel%2Bunsubscribe@goog legroups.com> . >> > For more options, visit this group at >> > http://groups.google.com/group/fubumvc-devel?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "FubuMVC Development Group" group. >> To post to this group, send email to fubumvc-devel@googlegroups.com. >> To unsubscribe from this group, send email to >> fubumvc-devel+unsubscribe@googlegroups.com<fubumvc-devel%2Bunsubscribe@goog legroups.com> . >> For more options, visit this group at >> http://groups.google.com/group/fubumvc-devel?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "FubuMVC Development Group" group. > To post to this group, send email to fubumvc-devel@googlegroups.com. > To unsubscribe from this group, send email to > fubumvc-devel+unsubscribe@googlegroups.com<fubumvc-devel%2Bunsubscribe@goog legroups.com> . > For more options, visit this group at > http://groups.google.com/group/fubumvc-devel?hl=en.
