> *how often to commit.*
>

I would'nt automate commits; I would not commit with every save

A commit is a piece of progress you commit when you see that it works;  but
you can't ensure that nothing else breaks due to what you have changed.  So
when you later notice that something is broken and want to find out at which
point
the breaking occured small focused commited with clear messages are helpful
(if you working solo then after a few months revisting code can still seem
alien)

git flow is very helpful in assisting with workflow

it maintains branches for specific tasks; eg bug fixing, feature creation
and releases

say you are making a site that is working pefectly in all browsers but not
IE

and you have created a branch which focuses on resolving the IE issues.  You
can continue to make progress on other features since you are
uninspred/reluctant to make the ie issues go away.

the ie-fix branch has an alteration to the readme and todo marker comments
in various places within the source (you have painstakingly code that is
part of the problem but have not decided upon the correct solution as yet)

The newly developed features get merged into the ie-fix branch so that it is
not left behind the production site (which does not have extensive comments
where you curse Gates, Balmer et al) At some point try an idea to resolve
soe ie issues and notice that other issue have resolved themselves YAY.  You
then manage to fix it pinning things down to a point where you know the
exact piece of code that either fixes or causes the issue - the one that
fixes it is a commit.

the files changed are various html and css files (there is another issue you
have spotted - but it remains in the repo and you note it down on paper -
its another commit not the focus of this branch implementing it not
contaminates the commit)

"Solved IE Css formating issue; had to use these wierd css hacks and in
addition have various divs for wrapping content just for IE" (you then solve
a few more things which you have noted as different issues - each of these
is its own commit)

these commits can be cherry-picked in to your master (tagging master so that
if other issue arise from these fixes you have a starting point resolving
these issues)

this way you don't find yourself in a situation where you notice 6 issues
and don't know at what phaze of development youwent wrong.


>
> *Should I have multiple git repositories or a single monolithic one?*
>

don't have chaos; I am recovering from a chaotic setup dating back to when I
was starting out with git

what I am trying to get to (this seems to work well):
Have repos on github
Have a master local repo (push from this to github)
Have local repos (these can pull direct from the local master; and the local
master can pull from it - NOT PUSHING - that would mess things up)

temp repos set something up get it to do what you need; test out things; if
you mess it up delete if its good
PLAN how to merge the updates in to master-local and push to www-repo


>
> *Is it possible to save out multiple versions of a single file? (easily?)*
>
>
so you have multiple variation of the same project; just branch the changes

git checkout -b newBranch [basedUpon]


> *Is git for me?
>
> *
>

its a life - changer for many; it means I can be more productive; I don't
need to have an insane bewildering collection of tars; I can use gitk to
walkthrough the history of my code and then pop right back to the future

git is my DMC 12 and that makes me Marty McFly

as for tutorials
github.com have a wealth of documentation and its really clear informative
stuff
they have a site with videos too (Scott Chacon)
http://git-scm.com/documentation

lots of people come to git from svn, I never did get on with SVN (or any
visioning control*),
searching for git for SVN users may be helpful if you are familiar with SVN


Get a book or two.  I got an O'Reily Press one with Bat on the front

ProGit is one that I have much good things about;
and also Travis Swicegoods book also

* I never got on with visioning code and had to perform intense and
labourous task to be able to revert to a stage when the project was working
better than it is currently since these improvements turned out to be false
hope.

Now when I need to revert a project I can do so with a few lines  in the
console and all is right again and I can make a new attempt to implement
those improvements - without the chore and NULL time spent regressing
through archives or getting on with SVN in a civil manner

git is a simple solution to problem that other proposed solutions have often
proved to be more complex than what they set out to solve.

git it straight from the source :)
http://www.youtube.com/watch?v=4XpnKHJAok8

On 7 February 2011 20:31, Mark (my words) <elib...@gmail.com> wrote:

> Hello,
>
> I'm new to git. I'm trying to develop a workflow for my creative writing. I
> figure that other's must have came before me, so why reinvent the wheel?
>
> *Here are some issues I'm dealing with*
>
> *Stay out of the way/how often to commit.*
> I can use launchd on OS X to call a script to make commits periodically
> and/or when a file changes. Is making a commit every time a file is saved
> too much? (I tend to save a bunch.)
>
> *Should I have multiple git repositories or a single monolithic one?*
> I usually have several projects in the works, each individual piece (poem,
> story) has it's own directory which I use to keep working drafts.
> I'd hate to have to remember to run git init, git add . , and setup a
> laucnhd script, every time I start a new poem, but I would also hate to be
> overwhelmed by navigating a huge repository.
>
> *Is it possible to save out multiple versions of a single file? (easily?)*
> I often need to open three, four, or more versions of a file. And I
> occasionally need to print several old versions. Can git do this? I know I
> can use diff to compare two versions, and I can open a particular version,
> is it possible to open/save the last n versions of a file?
>
> *Is git for me?*
> Am I running into a fundamental incompatibility problem? Do I just need to
> learn more about git? What are some good resources to look at—I'm
> overwhelmed by the sheer number of git articles online.
>
>
> Thanks,
>
>
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To post to this group, send email to git-users@googlegroups.com.
> To unsubscribe from this group, send email to
> git-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/git-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to