1

I'm very new to git, but last week I installed it, set up bitbucket, and pushed my current project to my first bitbucket repo. All went well and I'm pleased with git as a simple, powerful, yet free way to back up my source code offsite, as well as keep track of my changes.

My next step is to keep track of actual version numbers. I'm developing in Visual Studio, where the version numbers live in the project's assembly information. I've read that version numbers are usually tracked in git with tags, so I went to tag my commit with the current version number I'm on. At this point I realized that the project that I linked to my bitbucket repo contains two projects, an application and a set of web services. At this moment they share the same version number, but most likely in the future they will have differing version numbers.

Right now each of these projects is in their own folder in the repo's root directory. Is there a way for me to mark one of these directories with one tag, and the other directory with another? Or should I step back and create two separate repos, one for the application, and the other for the web services?

Improve this question

1 Answer 1

Reset to default
1

A tag always points to a specific commit, so no. A commit is a given state of the repo in time. You can either use two different sets of tags (e.g. web-v-2.1 and services-v-5.2) or break up the projects into their own repositories.

At the end of the day, I don't think you really care if a tag contains a specific set for the other folder. I'd just pick tags that represent what I was interested in even if it applies to the entire repo when describing just part of it.

Improve this answer
5
  • Since I generally work by myself, source control for me has always been just a way to save my changes offsite. I'm hoping to start using some better practices though. My current development strategy is to code for a day, and then when I'm done in the evening I commit my day's work. Most likely I've done work on both the web services and the application. I can use two tags for each nightly commit, but if I ever got a second person working with me, which would be a better practice?
    – cost
    Jan 4, 2014 at 2:30
  • Tagging every day doesn't seem useful. If you're using it describe a day, that's easy to find from the reflog. My thoughts are "commit early, commit often". Even if you only push once in a while committing is light weight and if you need to roll back to 15 minutes ago because you went down a rabbit hole, well, that's easy. Basically, if I made a change that builds, it appears to work, commit it.
    – Travis
    Jan 4, 2014 at 2:32
  • We have a team of around 20, just for scale, and we only tag major releases. We normally release everything at once so it's a single tag. But that happens pretty rarely. The real better practices start coming into play when you start branching and merging when people are working on features. The isolation for a branch lets you commit all day long them merge it in once you have a final solution.
    – Travis
    Jan 4, 2014 at 2:34
  • Thanks, that makes good sense. So I'll try to commit more often, but I'll hold up on tags except for when I do some manner of a release. After all, it's not like I do nightlies.
    – cost
    Jan 4, 2014 at 2:37
  • I'm realizing now that your method has the added benefit of, if I commit a minor patch to either of the projects, then I immediately know which version of the other project corresponds with it. If I had two separate projects I'd have to keep track of that some other way.
    – cost
    Jan 4, 2014 at 23:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.