删除一个命名不正确的git分支 [英] Deleting a badly named git branch

查看:105
本文介绍了删除一个命名不正确的git分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道这不是严格的编程问题,但它与git有关。我意外地在git中创建了一个名为 - track 的分支(当合并远程分支时,我得到了错误的选项顺序)



常规命令不起作用:

  git分支-D--track

我试图用引号和反斜杠进行转义,但都无效。



有什么想法?

解决方案

$ p> git branch -D - --track

- 通常是接下来不是一个选项,不管它的名字是什么的约定






Unix编程艺术部分命令行选项


传统的做法是将双连字符识别为停止选项解释的信号,并按字面顺序处理所有后面的参数。




您可以在其他(不需要与Unix相关的)CLI(命令行界面)中找到该约定,例如 cleartool


如果非选择参数以连字符( - )字符开头,则可以需要在它之前一个双连字符参数,以防止它被解释为一个选项:



  cleartool rmtype -lbtype  -  -temporary_label- 

P18 (一种快速灵活的文件预处理器,具有宏处理功能和对国际化的特殊支持)也提到了这一点,并对背后的总体思路进行了很好的描述这个约定:
$ b


所有传递给命令的选项参数都以一个连字符开始。

所有选项参数(if任何)必须在所有非选项参数之前。

选项参数的结尾可以使用双连字符来发信号,如果非选项参数以连字符。使用双连字符终止选项参数列表适用于所有命令,即使是那些不带任何选项参数的选项。


用ruby编写的 OptionParser 工具也非常清楚地说明了这一点:*



期权分析终止


习惯上,双连字符是停止期权解读的信号并从字面上读取命令行中的其余语句。所以,一个命令如:



  app  -  -x -y -z 




不会'看见'三个模式标志。相反,它们将被视为应用程序的参数:



  #args = [ x,-y,-z] 






注意:有时,它需要三个破折号而不是两个,特别是当CLI严格遵循Gnu选项样式时:


Gnu样式的命令行选项提供了对选项字(或关键字)的支持,但仍然保持与Unix样式选项的兼容性。

此样式中的选项有时被称为 long_options ,Unix风格选项为 short_options

兼容性为通过在long_options之前用两个破折号来维护



类似于Unix风格的双连字符' - ', Gnu风格有一个三重连字符' --- '来表明选项解析被暂停,并将其余文本作为参数(即re广告从字面上从命令行)


因此...如果' - '是不够的(它应该与Git命令),尝试' --- '


I know this isn't strictly a programming question, but it is related to git. I accidentally have created a branch in git called --track (I got the order of options wrong when merging a remote branch)

The regular command doesn't work:

git branch -D "--track"  

I have tried to escape with quotes and backward slashes, however neither work.

Any ideas?

解决方案

Did you try

git branch -D -- --track

? the "--" is usually the convention for "what follows is not an option, whatever its name"


From "The Art of Unix Programming", section "Command-Line Options":

It is also conventional to recognize a double hyphen as a signal to stop option interpretation and treat all following arguments literally.

You will find that convention in other (not necessary Unix-related) CLI (Command Line Interface) like cleartool:

If a nonoption argument begins with a hyphen () character, you may need to precede it with a double-hyphen argument, to prevent it from being interpreted as an option:

cleartool rmtype -lbtype -- -temporary_label- 

The P18 (a fast and flexible file preprocessor with macro processing capabilities and special support for internationalization) mentions that also and gives a good description of the general idea behind that convention:

All option arguments passed to the commands start with a single hyphen.
All option arguments (if any) must precede all non-option arguments.
The end of the option arguments may be signaled using a double hyphen, this is useful if a non-option argument starts with a hyphen. Terminating the list of option arguments with a double hyphen works for all commands, even those that don't take any option arguments.

The OptionParser tool written in ruby also lays it out quite plainly:*

Option Parsing Termination

It is convention that a double hyphen is a signal to stop option interpretation and to read the remaining statements on the command line literally. So, a command such as:

 app -- -x -y -z

will not ‘see’ the three mode-flags. Instead, they will be treated as arguments to the application:

 #args = ["-x", "-y", "-z"]


Note: sometimes, it takes three dashes and not two, especially when the CLI follows strictly the Gnu options styles:

The Gnu style command line options provide support for option words (or keywords), yet still maintain compatibility with the Unix style options.
The options in this style are sometimes referred to as long_options and the Unix style options as short_options.
The compatibility is maintained by preceding the long_options with two dashes

Similar to the Unix style double-hyphen ’--’, the Gnu style has a triple-hyphen ’---’ to signal that option parsing be halted and to treat the remaining text as arguments (that is, read literally from the command line)

So... if ' -- ' is not enough (it should be with Git commands), try ' --- '

这篇关于删除一个命名不正确的git分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆