How to use tags for versioning in git gui
I'm a complete and utter noob, so be gentle!
I'm using git gui, and never touching the command line interface. I'm a noob, and some of the people i'm working with are even noob-ey-er...
Current state:
- I have a repository on git hub which contains a handful of scripts (henceforth 'code')
- I'm using git gui (mysysgit)
- I have made commits and push's and have a vague understanding of CVS
- I don't believe we will need to branch
I feel that I should be able to use tags to create versions of the code. I also 'feel' like there should be an equivelant structure in the filesystem where the snapshots (or links to...) are stored.
eg:
.\EdsLittleThing\v1.0
.\EdsLittleThing\v1.1
.\EdsLittleThing\v1.2
etc
However, I can not work out how to create a tag within git gui. The only tag reference i can find seems to be tied to merging branches, and that doesn't help me.
I have scoured the web, and can not find a single reference on how to create and manage versions using Git Gui.
I want to be able to create a slightly more simple version of this:
Final note: Whilst I'm led to believe that my answer is found in 'tags', I dont really care if its really answered by using revisions / branches / whatever.
Answer
You want to use gitk, available by Repository->Visualize…
In the top pane, right click on the commit you want to tag at, and select create tag.
In the git model, you do not typically have tags checked out to disk under the same repository. You could have multiple repositories (all cloned from upstream) or the not suggested multiple working directories at different revisions with one revision, but most times simply using git's tool obviates the need to have multiple versions checked out at the same time.
What you are suggesting is nothing like the gitflow model, so I don't recommend using that as a reference. Read the ProGit book, http://progit.org for good advice and a few other workflows. I use one which is none of the above.
Typically you tag at major milestones. I tag when a piece of code becomes customer visible, or when we have code ready to move into formal QA practices. There is typically no need to tag as reminders of when things happened. That is what commit messages are for.