0

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.

enderland
  • 12,091
  • 4
  • 51
  • 63
soungalo
  • 117
  • 2
  • 1
    You want to avoid [this](http://programmers.stackexchange.com/q/302147/52929). – enderland Feb 23 '16 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 '16 at 13:48

2 Answers2

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

Then...

git push --tags                 # Pushes ALL tags

Or...

git push origin RELEASE_2016_02_23

...to push the specific tag.

hlovdal
  • 220
  • 3
  • 13
ManoDestra
  • 201
  • 1
  • 4
  • 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. –  Mar 06 '16 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 06 '16 at 19:31
  • 2
    The references to the state of the repository already exist as the checksum for the commit. From [git tagging](https://git-scm.com/book/en/v2/Git-Basics-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. –  Mar 06 '16 at 19:49
  • Yes, I'm well aware of that. – ManoDestra Mar 06 '16 at 21:07
1

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.

Murph
  • 7,813
  • 1
  • 28
  • 41