Question

I am new to development and version control.

My present workflow to make changes to the project:

1. I created index.html with minimum features. Being new, I don’t have enough confidence on various CSS tags that break a page, by changing something small. For now I am using Bootstrap, which is simple to use, but with limited features.

2. To add some new content I copy index.html to index_.html and change index.html. This is purely for a fear that if the page breaks, I instantly copy index_.html to index.html and have a sigh of relief. This is my workflow, which would change when I have a little experience.

How do I use Git just to this and nothing else for now. I don’t want to copy index.html.
I have already read progit and seen following posts. They seem to point to a multiple users, versions and so on. It would take me a while to reach there. But if I know Git now, I can reach there in shape.

Workflow best practice with git and github?

Git Workflow Best practices

http://news.ycombinator.com/item?id=1826279

http://gweezlebur.com/2009/01/19/my-git-workflow.html

http://yehudakatz.com/2010/05/13/common-git-workflows/

http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

http://nvie.com/posts/a-successful-git-branching-model/?

http://thinkvitamin.com/code/source-control/git/our-simple-git-workflow/
(I have placed all these links, so that someone knows I have read enough and does not pull this post down.)

None of them seem to answer my stupid question that is important for my evolution.

Answer 1

To set up your repository for the first time:

git init
git add index.html
git commit

That saves a snapshot of your index.html exactly as it is now. Whenever you want to try something new, make changes directly to index.html.

If the page breaks, just do this:

git checkout index.html

That throws away your most recent changes and restores the last saved snapshot of index.html.

But if the change goes well, do this instead:

git commit index.html

That saves a new snapshot, so that you can go back to it if the next change breaks.

Now, as you know, git has a lot more power to it. You may find a better workflow that has advantages over the way you do it now. But if you want to start with an analogy to your familiar pattern, that’s how to do it.

(By the way, whenever you run “git commit” a screen will appear asking you for a commit message — you can use that to describe the changes so you can keep track of them. Nobody sees it but you, so if that doesn’t sound useful, you could decide to ignore it.)