Is it possible to alias a branch in Git?

I am looking into using git on a massive scale. I was hoping to increase adoption and make things easier by calling the master branch trunk.

This can and will give SVN users some feelings of comfort. I know I can create a branch called trunk but that seems to deviate from the git norms and might cause some users to get confused.

  • Making Jenkins (Hudson) job depend on another job
  • Git and incremental commit dates/number/something
  • Using TeamCity with GitHub for Windows
  • How to configure a jenkins job to send mail if a SCM commit
  • Automatically remove Subversion unversioned files
  • Assembly Versioning with TeamCity
  • I know that I can also create and delete tags to my heart’s content but when I checkout those tags it tells me it is a non local branch which is just fine with me but probably not what I want to be doing.

    I am a total git newb but a seasoned professional at release and build systems.

    What I want to do is to be able to call master trunk. I have seen the ability to alias commands does this apply for the names of versioned objects as well?

    I know git-svn exists and other tools but the overhead of layered repository systems frightens me.

  • Git Patch to HTML parser
  • How to load private git repository as package at azure website?
  • Compare two git branches
  • How to deactivate the Xcode git feature? (remove git integration)
  • How to clean all data from a specific remote in git?
  • Apache and git-http-backend
  • 3 Solutions collect form web for “Is it possible to alias a branch in Git?”

    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.).

    There is nothing special about the name “master” in Git, it’s just called that by convention (and by default). You can certainly call it “trunk” if you like:

    git branch -m master trunk

    This is very much like Subversion, where the name “trunk” is only called that by convention too. You could have called the main branch “master” in Subversion.

    git-branch-alias script (and feature request):

    This is a safety wrapper around the technique shown in Charles Bailey’s answer.

    $ git branch-alias short some-overly-long-branch-name # creates alias
    $ git branch-alias short # creates alias for current branch
    $ git log short
    $ git checkout short
    $ git push origin short # pushes the branch, not the alias/reference
    $ git branch-alias --delete short

    Updated version for testing:

    # git branch-alias
    # Version 1.09-rc1
    # Author: Phil S.
    # Creates branch aliases, so that you can refer to a long branch name
    # by a convenient short alias. This is just a "do what I mean" wrapper
    # around git symbolic-ref, but without the (considerable) risk of
    # trashing a branch if you get your arguments wrong
    # Examples:
    # git branch-alias short some-overly-long-branch-name # creates alias
    # git branch-alias short # creates alias for current branch
    # git log short
    # git checkout short
    # git push origin short # pushes the branch, not the alias/reference
    # git branch-alias --delete short
    # Caveats:
    # Although everything else I've tried works seamlessly, I note that
    # git merge <alias> will cause the alias name to be mentioned in the
    # commit message, rather than the real branch. It would be nicer if
    # the branch name appeared.
    # Compatibility:
    # Originally developed with git version
    # Tested with git versions 1.9.0, 2.54, 2.80
    # Related git changes between versions and 1.9.0:
    #  * A symbolic ref refs/heads/SYM was not correctly removed with "git
    #    branch -d SYM"; the command removed the ref pointed by SYM
    #    instead.
    # 1.8.1
    #  * "git symbolic-ref" learned the "-d $symref" option to delete the
    #    named symbolic ref, which is more intuitive way to spell it than
    #    "update-ref -d --no-deref $symref".
    # Change Log:
    # v1.09:
    # POSIX-compatible option handling and output.
    # v1.08:
    # Removed test git show-ref --verify --heads --quiet "refs/heads/${symref}"
    # for asserting that the specified reference was valid before deleting a
    # reference, as we need to permit the deletion of references to branches
    # which have /already/ been deleted, and this test prevented that.
    # n.b. We already had another validation test to fall back on, using
    # git symbolic-ref "refs/heads/${symref}"
    # v1.07:
    # Minor tweaks. Posted as feature-request to git mailing list:
    # Also appears at the following URL, but there the code is broken
    # by an email obfuscation filter automatically converting the symbol '@'
    # to the string ' <at> ' (specifically, the shell positional parameter
    # expansion "$@" is changed to "$ <at>"), so don't try to use this copy:
    #cwd=$(git rev-parse --show-toplevel)
    git=$(git rev-parse --git-dir)
    if [ $? -ne 0 ]; then
        exit 1
    command=$(basename $0)
    command="git ${command##git-}"
    # Print argument (and newline) to stdout or stderr
    stdout () {
        printf %s\\n "$1"
    stderr () {
        printf %s\\n "$1" >&2
    # POSIX compatible argument quoting and parameter save/restore
    save () {
        local param
        for param; do
            printf %s\\n "$param" \
                | sed "s/'/'\\\\''/g;1s/^/'/;\$s/\$/' \\\\/"
        printf %s\\n " "
    # parameters=$(save "$@")
    # eval "set -- ${parameters}" # to restore the original parameters.
    # Process option parameters
    while [ $# -gt 0 ]; do
        case "$1" in
            ( --          ) shift; break;;
            ( -d|--delete ) delete=1; shift;;
            ( -h|--help   ) help=1; shift;;
            ( -*          ) {
                stdout "Invalid option: $1"
            ( * ) { # non-option parameter
                parameters="${parameters}$(save "$1")"
    # Process non-option parameters
    eval "set -- ${parameters}"
    if [ -z "${symref}" ]; then
    # n.b. Calling "git branch-alias --help" causes git to look for
    # a man page for "git-branch-alias", so we shouldn't advertise
    # the long option (although we support it if the script is called
    # by its real name, rather than via git).
    if [ -n "${shorthelp}" ]; then
        cat <<EOF
    For help, use: ${command} -h
        exit 0
    if [ -n "${help}" ]; then
        cat <<EOF
    ${command} <alias> [<branch>]
    ${command} (-d | --delete) <alias>
    Creates a symbolic reference <alias> referring to <branch>.
    <branch> defaults to the current checked-out branch.
    This symbolic reference acts as an alias for <branch>, and can be
    used in its place. More specifically, it WILL be dereferenced to
    its target in nearly all situations, so for any given command you
    should treat every usage of <alias> as if it were actually <branch>.
    To safely delete a branch alias, always use:
    ${command} -d <alias>
    WARNING: These symbolic references appear in your branch list as:
     <alias> -> <branch>
    and so you might be tempted to try to delete them like a branch:
     git branch -d <alias>
    However this can cause problems. In git versions prior to
    <alias> will be dereferenced and you will instead delete the
    branch it refers to (git will allow this even if you currently
    have that branch checked out), and the symbolic reference will
    still remain (referencing a branch which is no longer available).
    In later versions of git the <alias> will be deleted rather than
    the branch; however git will still not check to see whether you
    currently have <alias> checked out, and will not prevent you
    from deleting it in that situation. This will leave your HEAD ref
    in an invalid state. Using ${command} -d <alias> resolves
    this situation by first switching HEAD to <alias>'s target branch
    if HEAD was currently set to <alias>.
        exit 0
    # Use the current branch by default.
    if [ -z "${branch}" ]; then
        branch=$(git symbolic-ref -q HEAD)
        if [ $? -ne 0 ]; then
            stderr "Could not establish current HEAD."
            exit 1
    # We expect plain branch names, but also accept the fully-qualified
    # (refs/heads/NAME) paths needed by git symbolic-ref; so strip that
    # refs/heads/ prefix if it is specified.
    # Deleting a symref.
    if [ -n "${delete}" ]; then
        if [ ! -f "${git}/refs/heads/${symref}" ]; then
            stderr "Symbolic reference refs/heads/${symref} does not exist."
            exit 1
        # Verify that it IS a symbolic reference
        if ! git symbolic-ref "refs/heads/${symref}" >/dev/null; then
            stderr "Error validating refs/heads/${symref} as symbolic reference."
            exit 1
        # If we currently have <symref> checked out, deleting it is bad
        # (as HEAD would no longer be a valid reference). I believe we do
        # need to inspect the file here, as attempting to read the HEAD
        # reference via git dereferences it to its target branch, and thus
        # we are unable to distinguish between the branch and the symref.
        if grep -q "^ref: refs/heads/${symref}\$" "${git}/HEAD"; then
            stdout "Cannot delete the currently checked out symbolic reference."
            branch=$(git symbolic-ref -q HEAD)
            if [ $? -ne 0 ]; then
                stderr "Could not establish current HEAD."
                exit 1
            stdout "Switching HEAD to target branch ${branch}"
            # By using git symbolic-ref HEAD to find the target ref
            # and setting HEAD to that target, nothing really changes,
            # but we can now delete the reference safely.
            if ! git symbolic-ref HEAD "${branch}"; then
                stderr "Error updating HEAD from ${symref} to ${branch}"
                stderr "Aborting."
                exit 1
        # Delete the reference.
        # git 1.8.1+ provides: git symbolic-ref --delete <symref>
        # but older versions do not include that option, so we use
        # the backwards-compatible command.
        stdout "Deleting symbolic reference refs/heads/${symref}"
        git update-ref -d --no-deref "refs/heads/${symref}"
        exit $?
    # Creating a new symbolic reference.
    # Error checking. git symbolic-ref doesn't really do any, and will
    # happily mess up your branches; particularly if you get the arguments
    # the wrong way around (treating it like ln -s is a really bad idea).
    if [ ! -f "${git}/refs/heads/${branch}" ]; then
        stderr "Target refs/heads/${branch} does not exist."
        exit 1
    if [ -f "${git}/refs/heads/${symref}" ]; then
        target=$(git symbolic-ref "refs/heads/${symref}")
        if [ $? -eq 0 ]; then
            stderr "Symbolic reference refs/heads/${symref} already exists:"
            stderr "  ${symref} -> ${target##refs/heads/}"
            stderr "To remove it, use: ${command} --delete ${symref}"
            stderr "File refs/heads/${symref} already exists"
            stderr "(and is not a symbolic reference!)"
        exit 1
    if git show-ref --verify --heads --quiet "refs/heads/${symref}"; then
        # n.b. I'm pretty sure this is unreachable, given the previous block.
        stderr "refs/heads/${symref} is a valid reference without a file!?"
        exit 1
    # The parameters are good.
    # Generate the reference and display the confirmed result.
    if git symbolic-ref "refs/heads/${symref}" "refs/heads/${branch}"; then
        target=$(git symbolic-ref "refs/heads/${symref}")
        stdout "  ${symref} -> ${target##refs/heads/}"
        stderr "Failed to create branch alias."
        exit 1
    Git Baby is a git and github fan, let's start git clone.