3

I am working on a phing script with git for build automation, and am still new to it. To give a little idea, we plan to have multiple branches in our project, and any of them could be rolled out (we are almost certain about this part).

During the course of development of my thought process for implementing the build script, I considered providing the git branch as an input to the build script for some time, then switched to providing the git revision instead (which could belong to any branch). Now, as my knowledge is increasing further, I am again in favor of using git branch references.

I would like to explore all the pros and cons of having either of these, which people have experienced, so that others have some reference to begin with.

The latest problem with using revisions that I realized today is that, it seems, I will have to pull all the branches to local in order to be able to find the one containing the revision, so that I can then move the working directory to that revision. Check How to take local working directory to any git revision irrespective of its branch after remote changes?.

Community
  • 1
  • 1
Sandeepan Nath
  • 9,966
  • 17
  • 86
  • 144
  • Why do you need to know the branch that contains the commit, just `fetch` the latest changes of the repository and `checkout` the sha you want to have. – Vampire May 06 '16 at 14:26
  • @BjörnKautler Doesn't fetch update only the branches existing already in the local repository? – Sandeepan Nath May 06 '16 at 14:42
  • As I said in your linked question, a fetch updates the whole remote including getting new branches (and removing stale if you use --prune), at least if you didn't tell Git otherwise by config or arguments. It will of course not create local branches from the new remote ones, but neither will a clone without according parameters – Vampire May 06 '16 at 14:44

1 Answers1

2

If you want to refer to a specific revision, create a tag. Tags are meant for things like identifying specific builds and released versions. A tag points to a specific commit just like a branch head does, but unlike a branch head, it doesn't change as additional commits are added.

Wyzard
  • 33,849
  • 3
  • 67
  • 87
  • "A tag points to a specific commit just like a branch head does, but unlike a branch head, it doesn't change as additional commits are added." Are you saying this is a benefit of using tag references instead of branches? Sorry, but I am unable to understand how is that an advantage? – Sandeepan Nath May 18 '16 at 10:48
  • When you build and deploy a specific revision, you want a reliable way to refer to that exact revision: you want to be able to say "this revision is version 1.0", and have it stay the same even after more commits (e.g. changes for 1.1) are added. You can use a commit ID for that, but they're hard to remember. A tag is a human-readable name for a specific commit ID. – Wyzard May 18 '16 at 13:02