For this kind of work, I suggest you to learn about Maven which deals with dependency compatibility (among a lot of other things).
With Maven, you could for example use one of these two ways:
Either the "standard" way: by creating a Nexus repository which you will feed with a compiled jar of each version of your common package and to fully exploit maven/nexus the version(s) of JDBC you use. Each time you build your project from any commit, the versioned config file will be read and will use the good revision of your library "common".
(I say Nexus, but there are others software doing the same thing, I've also heard of one named Artifactory).
Or, you could make a more complicated script which, when you build your server or client project, go download the source of your library on your "common" repository and build it.
Maven may seems a bit overkill and is (in my opinion) a pain to learn alone, but it's handy, powerful, and is the professional standard in Java and works seamlessly with Eclipse.
As for the Maven usage, the Nexus way is (depending on your scripting skill) a bit heavier to init, but more standard, easy to scale with your project, and can be used for all your other future projects.
If you're working in a professional context, I strongly advise to look for a colleague knowing it to help you mavenize your project.
The solution I decided was simplest and kept the most advantages for me was to rebase and then merge. After using github to go back and forth on the pull request and committing a few minor changes it was time to merge it into the master branch. On my local setup I did:
git pull
git checkout feature
git rebase -i HEAD~8 # combine small commits and separate file moving
git checkout master
git merge --no-ff feature # comment this with `close #<pull_request_number>`
git push
The advantages are:
- On the master branch the history is cleaner and more concise
- The explicit merge at the end links the pull request to the merging commit
The disadvantages are:
- The rebased commits in the pull request no longer link to commits in the master which could be confusing.
- I didn't actually go back and make sure each of rebased commits works in the new rebased context so small chance of bugs there
Not sure if this is a recommended approach or a little too hacky and I should stick to one or the other. But we'll see if any problems stem from this. Very flexible to different suggestions from other people though.
Best Answer
In practice, because every commit in a git system already has a hash, if all you need is a unique identifier to reproduce a build, or identify a particular state of your branch, you already have that with the commit hash. And obviously your CI system already knows that commit hash. So in this sense, all of those tags are a bit of a waste.
Is it bad practice? I haven't seen anything that would say it's bad, and I can't think of any real problems this will create, but it does seem quite unusual to me. Typically tags are used for releases, and the tags are semver'd. As long as you're semver'ing every tag, it's probably not terrible. Supposing that you actually deploy these builds, maybe it's marginally more useful to identify builds and their associated problems by tag rather than by git commit.
Your usage though seems to fall for me into a very large category we call "personal preference". I doubt the world will burn down if you keep doing it. It wouldn't be my choice, but if your build pipeline isn't broken, I wouldn't recommend "fixing" it to some ethereal state of git perfection.