> *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 email@example.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 firstname.lastname@example.org. 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.