In my company we have a 'production pipeline', which is a bunch of code which we use to produce data, with the data later shipped to customers. The code is still being developed, bugs get fixed etc.

Currently, we are still using SVN, but we are on the process of moving to git. Using SVN, we used revision numbers to define specific 'points in time' to which we could come back. For example, we could tell that certain data were created using revision-1234, and monitor changes this way.

I am wondering what would be the best practice of using git for this matter. I have read about branches, tags and releases, but not sure what's the best way to go.

  • 1
    You want to avoid this.
    – enderland
    Feb 23, 2016 at 13:16
  • 3
    You would probably benefit from using tags in SVN to define those "specific points in time". Then, when you established that in your team, you can use tags in git as well.
    – Doc Brown
    Feb 23, 2016 at 13:48

2 Answers 2


Normally, when I release a version of software, the code is tagged in Git with a sensible naming convention e.g. v1_0_0 or RELEASE_2016_02_23, etc. This creates a baseline copy of all the code as it exists at the point of the tag. You can also compare tags for differences, etc. VERY useful and simple to do in Git Bash with two commands:

git tag RELEASE_2016_02_23


git push --tags                 # Pushes ALL tags


git push origin RELEASE_2016_02_23

...to push the specific tag.

  • 2
    The pedantic in me wants to point out that it doesn't create a copy of the code that exists at that point of the tag, but rather associates a name with a particular state of the git repo. No copies are made.
    – user40980
    Mar 6, 2016 at 14:11
  • Yes, obviously not a physical copy, just a virtual one, in terms of references to the files at that point.
    – ManoDestra
    Mar 6, 2016 at 19:31
  • 2
    The references to the state of the repository already exist as the checksum for the commit. From git tagging: "Another way to tag commits is with a lightweight tag. This is basically the commit checksum stored in a file – no other information is kept." The entirety of the tag is the information "ca82a6dff817ec66f44342007202690a93763949" - the identifier of the commit that is tagged.
    – user40980
    Mar 6, 2016 at 19:49
  • Yes, I'm well aware of that.
    – ManoDestra
    Mar 6, 2016 at 21:07

At the most basic level, the equivalent value you need to use for git is the SHA-1 for the commit.

You may (probably will) want to find a way to attach a more human friendly tag but the key value is that SHA-1 (or at least the first 8 characters thereof) because that is what will take you to the version of the source that generated the code (subject to a modest amount of hand waving about the versions of any dependencies at that point in time).

At a higher level it rather depends on your development patterns and so its harder to make practical suggestions - but I'd go look at A successful git branching model - usually referred to as gitflow - to at least give you a reference point for getting your thoughts in order.

Your Answer

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

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