CODEWITHSUNDEEP
gitbash
U r s u s
U r s u s

Reputation: 6968

Git show last branch deployed

Regardless of the build/deploy process one is using, is there a way to show from which branch the latest deploy was launched with git?

I realise that deploying and git are unrelated, so I am not after a single command.

To illustrate what I mean, imagine you're jumping on a project you haven't worked on before and you're not sure which branch was deployed. Wouldn't it be sweet to find out just with a series of git commands?

Upvotes: 0

Views: 2128

Answers (1)

cmbuckley
cmbuckley

Reputation: 42458

This isn't possible if you want to truly assume nothing about the build process, as that means you can't assume that the build process makes any record of anything back into your version control system (e.g. you could have a deploy process that simply issues a git pull on a box somewhere).

If you make an assumption that your build process is building from a given branch (e.g. master), and tagging the branch every time it makes a build, then git describe master will tell you the latest tag in the master branch.

In this case, this may only tell you about the latest build, not the latest deployment. In this sense the tags are release candidates, and you'd have to make more assumptions in order to find the latest deployment.

We use the following strategy:

M─┐ [v2] [release] Merge branch 'feature-Y' into release
│ o [feature-Y] Commit F
│ o Commit E
│ o Commit D
M─┤ [v1] [master] Merge branch 'feature-X' into release
│ o [feature-X] Commit C
│ o Commit B
│ o Commit A
I─┘ Initial commit

This tells you a few things:

  • We only maintain one version of this application.
  • master points at the current production version. (So v1 is currently live.)
  • Commits are made in feature branches and merged into release when ready.
  • Here, the new feature-Y is our release candidate, which has been build and tagged as v2 by our build process.
  • This is deployed to a pre-production environment for testing.
  • Once testing is complete, the build is promoted to live.
  • Once everyone is happy that it's working in live, master is fast-forwarded to release (git push origin release:master) and now v2 is live.
  • Repeat!

If at any point the release candidate fails testing, the release branch is thrown away and rewound back to master (git push -f origin master:release), so feature-Y is no longer part of the mainline. However, v2 still exists in git for posterity.

Upvotes: 1

Related Questions