2>/dev/null 部分

2>/dev/null 部分

次のスクリプトを作成しました。現在のブランチを対応するリモートブランチにプッシュします。

#!/usr/bin/env bash

# Usage: pushes current checkout branch to its remote counterpart.

current_branch=$(git symbolic-ref HEAD 2>/dev/null) ||
current_branch="(unnamed branch)"

git push origin ${current_branch}

git symbolic-ref ...私がやりたいことをどのように成し遂げられるかグーグルをして、結局こんなことをするようになりました。私が望むように動作するようですが、これを達成するための別の方法がありますか?

この部分の意味/機能もわかりません。2>/dev/null

編集する:少し読んだ後バッシュ文書これがリダイレクトの王だと思いますか?

答え1

さて、コードレビューが始まります。

# Usage: pushes current checkout branch to its remote counterpart.

最初の単語をスキップします。これはスクリプトの使用方法ではなく、スクリプトの機能を説明するコメントです。

current_branch=$(git symbolic-ref HEAD 2>/dev/null) ||
current_branch="(unnamed branch)"

を実行しgit symbolic-ref HEADて削除し、変数にstderr割り当てています。stdout失敗した場合は、支店名を使用できます(unnamed branch)

git push origin ${current_branch}

最後に、ローカルブランチをソースにプッシュします。


以下はいくつかの説明です。

2>/dev/null 部分

stdinLinux / Unix端末で実行されるすべてのプログラムには、通常、キーボードから入力を収集する入力チャンネルと呼ばれる入力チャンネルがあります。またstdout、(通常動作情報を印刷するための標準出力)とstderr(警告とランタイムエラーを印刷するための標準エラー)という2つの出力チャンネルがあります。これらのチャネルはハードウェアで開始されましたが、現在はすべての端末とすべてのシェルでサポートされているソフトウェア専用の標準です。 Bashがstdoutとstderrチャネルを処理する方法は1数字と2。これ2>は、プログラムに標準エラーを別のターゲットにリダイレクトするように指示することだけです。/dev/null基本的にブラックホールとして機能する仮想デバイスです。そこに送ったすべては失われます。したがって、2>/dev/null文字通りの意味は「非標準出力を印刷しない」です。

||部分

Bashのデュアルパイプは、左側のプログラムが失敗した場合、つまり左側のプログラム以外の終了コードを返す場合は、ダブル0パイプの右側を実行することを意味します。 「右」は、同じ変数に代替値を割り当てる次の行に続きます。


今コメントに戻ります。

新しく作成したブランチを元のリモートブランチにプッシュし、ローカルブランチと同じ名前を持ちたいです。

あなたのコードはこれを行いません。まあ、信じられません。

HEADgitで現在チェックアウトされているブランチの最新のコミット(ある場合)を指す特別な参照です。最後の部分はコードが危険にさらされる部分です。HEAD常にポイントを指す必要はありません。いわゆる別々のHEAD状態にすることもできます。この場合、エラーによりコマンドが失敗しますfatal: ref HEAD is not a symbolic ref。このエラーはスクリプトによって削除され、ブランチ名は引き続き使用されます(unnamed branch)。最後の行は(unnamed branch)おそらく不要なローカルポイントをプッシュしようとします。

コマンドが成功しても同様の出力が表示されますrefs/heads/yourbranchname。このオプションを使用して--short最後の部分のみをインポートできます。

git symbolic-ref --short HEAD

結果は次のとおりです。

yourbranchname

支店がなければどうなりますか?単純な。あなたは何も押したくありません!ブランチ名を解決できない場合は、スクリプトを終了する必要があります。方法は次のとおりです。明示的にexit $errorcodeまたはbashを使用してフラグを追加しますset -e

current_branch=$(git symbolic-ref HEAD) || exit $?

これには$?最後のコマンドの終了コードが含まれているため、git呼び出しが失敗しました。隠す必要はありませんstderr。これは何が間違っているのかを知るのに役立ちます。

または:

set -e
current_branch=$(git symbolic-ref HEAD)

set -eエラーが発生するたびにスクリプトを終了する特別なbashモードを有効にします。すべてのスクリプトでこれを使用することをお勧めします。

次の部分:

git push origin ${current_branch}

この順序には何の問題もありません。しかし、私の考えでは、あなたがあなたの人生を少し難しくしているようです。この詳細コマンドは、ローカルポイントとリモートポイント間のリンクを作成するために一度だけ必要です。-u次のオプションを使用してリンクを保存できます。

git push -u origin ${current_branch}

このコマンドを一度実行してから入力するだけで、git push自動的に正しいリモートブランチにプッシュされます。このリンクは、リモートポイントをチェックアウトまたは複製するときに自動的に設定されることに注意してください。これは、ローカルに生成された分岐にのみ必要です。

まとめてみよう

次のようにスクリプトを再構築したい場合があります。

#!/usr/bin/env bash

# Pushes current checkout branch to its remote counterpart.

set -e

current_branch=$(git symbolic-ref --short HEAD)
git push -u origin "${current_branch}"

新しいブランチに対して一度実行したら、次を使用します。

git push

答え2

push.default内部設定を見てくださいgit help config

私はその一部を引用します:

   push.default
       Defines the action git push should take if no refspec is
       explicitly given. Different values are well-suited for specific
       workflows; for instance, in a purely central workflow (i.e. the
       fetch source is equal to the push destination), upstream is
       probably what you want. Possible values are:

       ...

       o   current - push the current branch to update a branch with
           the same name on the receiving end. Works in both central
           and non-central workflows.

一言で言うgit config --global push.default current 一度お使いのコンピュータでgit pushこれから使用を開始します。


ストーリーのレッスンは、私がシナリオを書く2つの基本的なルールの1つです。

新しいホイールを発明する前に、必ず文書を確認してください。 (広く使用されているツールの場合)しばしば、「shim」スクリプトを直接書くことなく、必要な操作を正確に実行するオプションがすでにあります。

(この規則に対する一般的な違反は、同じタスクを実行する特定のコマンドラインフラグを無視するツール用の長くて複雑な「ラッパー」スクリプトを作成することです。

関連情報