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
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.
