2009-02-14 5 views
49

Я изучаю использование git в массовом масштабе. Я надеялся увеличить усыновление и упростить задачу, позвонив в магистральную ветку.Возможно ли в псевдониме филиал в Git?

Это может и даст пользователям SVN некоторое чувство комфорта. Я знаю, что могу создать ветку, называемую trunk, но это, похоже, отклоняется от норм git и может заставить некоторых пользователей запутаться.

Я знаю, что я также могу создавать и удалять теги для контента моего сердца, но когда я проверяю те теги, он говорит мне, что это не локальная ветка, которая мне в порядке, но, вероятно, не то, что я хочу делать.

Я полный git newb, но опытный профессионал в системах выпуска и сборки.

Что я хочу сделать, так это позвонить главному багажнику. Я видел, что способность к командам псевдонимов делает это применительно к именам объектов с версией?

Я знаю, что git-svn существует и другие инструменты, но накладные расходы на многоуровневые системы репозитория пугает меня.

ответ

63

Вы можете переименовать магистральную ветвь ветви, как предложил Грег, или вы также можете создать соединительную линию, которая является символической ссылкой на главную ветвь, так что у пользователей git и svn есть «основная» ветвь, к которой они привыкли ,

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

Обратите внимание, что багажник не является гражданином первого класса. Если вы закажете trunk и выполните git status, вы фактически будете на master, однако вы можете использовать команду trunk во всех местах, где вы используете имя филиала (журнал, слияние и т. Д.).

+0

Обслуживание для обоих типов пользователей - моя главная проблема. Делает ли это на сервере достаточно, чтобы псевдоним действительно был полностью видимым? Я бы проголосовал за вас, у меня пока нет к этому никакого доверия. – ojblass

+0

Да, это так. Когда пользователи git fetch, они будут видеть удаленный реф для исходных/главных и начальных/магистральных. Из выборки не обязательно быть очевидным, что они одно и то же, но когда кто-то нажимает на мастер или туловище, то оба ветви будут «волшебным образом» обновляться вместе. –

+1

Я не думаю, что передача symrefs к клону, если вы используете git: // или протокол ssh - вам лучше проверить его. –

9

Нет ничего особенного в названии «master» в Git, его просто называют по соглашению (и по умолчанию). Вы, конечно, можно назвать это «ствол», если вам нравится:

git branch -m master trunk 

Это очень похоже на Subversion, где название «ствол» только называется, что по соглашению тоже. Вы могли бы назвать главный «главный» ветку в Subversion.

+0

Не зная вашу новую конвенцию бы новые съемники не знают, с чего начать? – ojblass

+0

HEAD из общего хранилища будет указывать на «багажник», поэтому съемщики не должны были знать. –

3

git-branch-alias скрипт (и запрос функция):
http://www.mail-archive.com/git%40vger.kernel.org/msg49171.html

Это безопасность оберткой техники, показанной в ответ Чарльз Бейли.

$ 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 

Обновленная версия для тестирования:

#!/bin/sh 
# 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 1.7.12.4 
# Tested with git versions 1.9.0, 2.54, 2.80 
# 
# Related git changes between versions 1.7.12.4 and 1.9.0: 
# 
# 1.8.0.1 
# * 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: 
# http://www.mail-archive.com/git%40vger.kernel.org/msg49171.html 
# Also appears at the following gmane.org 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 "[email protected]" is changed to "$ <at>"), so don't try to use this copy: 
# http://permalink.gmane.org/gmane.comp.version-control.git/247581 

#cwd=$(git rev-parse --show-toplevel) 
git=$(git rev-parse --git-dir) 
if [ $? -ne 0 ]; then 
    exit 1 
fi 

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 
# http://www.etalabs.net/sh_tricks.html 
save() { 
    local param 
    for param; do 
     printf %s\\n "$param" \ 
      | sed "s/'/'\\\\''/g;1s/^/'/;\$s/\$/' \\\\/" 
    done 
    printf %s\\n " " 
} 
# parameters=$(save "[email protected]") 
# eval "set -- ${parameters}" # to restore the original parameters. 

# Process option parameters 
parameters= 
while [ $# -gt 0 ]; do 
    case "$1" in 
     (--   ) shift; break;; 
     (-d|--delete) delete=1; shift;; 
     (-h|--help ) help=1; shift;; 
     (-*   ) { 
      stdout "Invalid option: $1" 
      shorthelp=1 
      shift 
     };; 
     (*) { # non-option parameter 
      parameters="${parameters}$(save "$1")" 
      shift 
     };; 
    esac 
done 

# Process non-option parameters 
eval "set -- ${parameters}" 
symref=$1 
branch=$2 

if [ -z "${symref}" ]; then 
    help=1 
fi 

# 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 

EOF 
    exit 0 
fi 

if [ -n "${help}" ]; then 
    cat <<EOF 
Usage: 
${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 1.8.0.1 
<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>. 

EOF 
    exit 0 
fi 

# 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 
    fi 
fi 

# 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. 
branch=${branch##refs/heads/} 
symref=${symref##refs/heads/} 

# 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 
    fi 

    # 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 
    fi 

    # 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 
     fi 
     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 
     fi 
    fi 

    # 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 $? 
fi 

# 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 
fi 
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}" 
    else 
     stderr "File refs/heads/${symref} already exists" 
     stderr "(and is not a symbolic reference!)" 
    fi 
    exit 1 
fi 
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 
fi 

# 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/}" 
else 
    stderr "Failed to create branch alias." 
    exit 1 
fi 
+0

Это не подходит для меня с Git 2.7.0 на OS X в zsh: 'Target refs/heads/-l не существует.' Независимо от того, какие аргументы я использую. – iconoclast

+0

Спасибо за ответы! В ответ на ваш вопрос, * да *, это было точное сообщение: «Целевые refs/heads/-l не существует». Я тестировал под bash, и он все еще это делал. Я отменил аргументы, и он все еще это сделал. Я сделал «unalias git» в zsh, чтобы гарантировать, что ничего не мешает, и все еще это делало. Я использовал полный путь к git, и он все еще это сделал. Я использовал полный путь к 'git-branch-alias', и он все равно это сделал. – iconoclast

+0

Я не думаю, что это может быть связано, но 'which -a git' показывает 2 версии в моей системе. Я не думаю, что второй может быть использован вообще, но ... У меня есть '/ usr/local/bin/git' и'/usr/bin/git', с первым ранее в PATH , Второй - 2.5.4. – iconoclast

Смежные вопросы