45

I am researching switching from starteam to git.

Currently, in starteam, we use "floating views" with special names. These floating views basically work like aliases. Therefore, we can specify a specific alias to checkout from and we'll get the branch that we're currently model testing.

How would this be done in git? This is basically how our branches are organized:

These are all branches

master (stable view)
   |  - Branch 2012.05.01
   |          | - Project 1
   |          | - Project 2
   |          | - model [floating view / alias to Branch 2012.05.01]
   |
   |  - Branch 2012.07.11   (these would also have various child views for projects)
   |  - Branch 2012.10.17

(Branch 2012.05.01 would be merged to master when model testing is complete)

In our automated scripts(ant) to run our model deployment, we just checkout from our branch called "model". This way we never have to change our scripts as we change which Branch we are model testing, and finding out which view we're model testing is as easy as figuring out which branch the "model" branch references.

Is there any such way to do something similar in git?

Edit: people are getting confused here.

  1. I want an alias of a branch. A branch, not a commit.
  2. "Branch 2012.05.01" means the branch intended to be shipped on 2012.05.01, it doesn't mean a 2012.05.01 moment in time
  3. I want a alias to Branch 2012.05.01. Branch 2012.05.01 is an integration branch, it's constantly modified. But I don't want to reference it as Branch 2012.05.01, I want to reference it as "model". This way, I can change my the alias to "Branch 2012.07.11" and it will get the most recent code from that branch without changing any of the checkout code script.
Aziz Shaikh
  • 15,104
  • 9
  • 55
  • 73
user606723
  • 4,425
  • 2
  • 25
  • 33
  • if it's an integration branch, then the workflow I gave a link to should work for you. The addition of a release candidate branch would be helpful too. You would track completed tasks or features there. You would use that to deploy to testing or staging environments. – Adam Dymitruk Jan 16 '13 at 19:31
  • 2
    as far as I know git has no such things, but what you can do is simply having a your "youngest" branch actually named "model", and then branching off it for releases – miniBill Jan 16 '13 at 19:32
  • @AdamDymitruk, the link does help. This basically exactly what we're doing except in starteam, but it doesn't answer my question about how to create an alias to a branch. – user606723 Jan 16 '13 at 19:33
  • 1
    As described [here](http://stackoverflow.com/questions/549920/is-it-possible-to-alias-a-branch-in-git#549949), you can create aliases via symbolic references. – g_daniel Jun 20 '13 at 19:22
  • Thanks @g_daniel. I'm not sure what the correct method to fix this, but I've voted to close this question. – user606723 Jun 21 '13 at 13:34

3 Answers3

57

Please see here: https://stackoverflow.com/a/549949/606723

You can rename the master branch trunk as Greg has suggested, or you can also create a trunk that is a symbolic reference to the master branch so that both git and svn users have the 'main' branch that they are used to.

git symbolic-ref refs/heads/trunk refs/heads/master

Note that trunk isn't a first class citizen. If you checkout trunk and perform a git status you will actually be on master, however you can use the trunk command in all places that you use the branch name (log, merge, etc.).

Community
  • 1
  • 1
user606723
  • 4,425
  • 2
  • 25
  • 33
  • 6
    Just a note for anyone struggling like I was - be VERY careful about singulars and plurals in 'refs' and 'heads'. You'll get something completely different if you miss any of the 's's out. – Sridhar Sarnobat Nov 04 '13 at 22:03
  • 5
    Also be VERY careful about the order of the arguments. It's NOT the same as `ln -s` and if you put them the wrong way around, git will happily (and silently) clobber the HEAD ref for the real branch with a symbolic reference to something which does not exist (at which point you'd better hope that it's easy to recover the correct commit hash for that branch). – phils Feb 27 '14 at 01:16
  • 8
    Also, don't try to remove a symbolic-ref with `git branch -d`. It's de-referenced even for that operation, and so you'll actually delete the source branch, leaving the reference behind (and it'll even let you do it if you currently have that branch checked out). It looks like the only 'interface' for removing a symbolic ref is to delete the file. – phils Feb 27 '14 at 01:34
  • 3
    phils wrote: " (at which point you'd better hope that it's easy to recover the correct commit hash for that branch)" It is always easy to recover the commit hash: `git reflog` – Nathan Kidd Mar 08 '17 at 17:17
  • 3
    @phils "It looks like the only 'interface' for removing a symbolic ref is to delete the file." `git symbolic-ref -d refs/heads/trunk` works fine also – iCodeSometime Jan 07 '19 at 22:22
  • @kennycoc Indeed, that was added in v1.8.1. If you wish to support older versions, there is in fact a backwards-compatible interface for that, which is: `git update-ref -d --no-deref "refs/heads/${symref}"` (which I clearly hadn't been aware of when I wrote the earlier comment). – phils Jan 07 '19 at 22:45
  • 1
    You might also find https://stackoverflow.com/a/23532744/324105 useful. It provides a `git branch-alias` command which uses this same `symbolic-ref` technique, but provides all the safety wrappers needed to do so without fear of accidentally trashing things in the process, or otherwise ending up in weird states. – phils Jan 07 '19 at 23:03
4

Git does not support aliases for branches.

This means you will have to rely on variables in your script to make model="branch.2012.10.17" or something like that. Your script would do something like this then:

git checkout $model

I'm leaving the rest of this answer here for where we came from in this discussion:

A very involved discussion on branching strategy can be found here: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Specifically, take a look at the role of the integration branch and the release candidate branch. This may be what you are looking for.

Look at git as something that takes a snapshot of your working directory, not as histories of folders.

progit.org/book explains the Directed Acyclic Graph that stores the history. All references are just things that point to nodes in it. That should clarify how you want to construct your workflow.

make a start tag - version2.1. from there make your int-version2.1 (using nubmers instead of dates for brevity). Any work you start, start from the version 2.1 tag. merge the work into the int-version2.1. Others will do the same.

Community
  • 1
  • 1
Adam Dymitruk
  • 109,813
  • 21
  • 138
  • 137
0

In case when you need branch per feature — answer of Adam Dymitruk is correct, But in case when you need save links branch - specific state (based on time), without changed them you can use git tags.

I used tags for store states of each prod releases.

iMysak
  • 2,022
  • 1
  • 21
  • 30
  • I don't need to save a specific state at all. I just want to checkout from Branch 2012.05.01 by referencing it as "model" instead of by "Branch 2012.05.01" so my scripts don't need to change. – user606723 Jan 16 '13 at 19:19
  • git checkout works same for branches and tags. – iMysak Jan 16 '13 at 19:21