What's New Qiita

20200323のGitに関する記事は8件です。

  • 投稿日：2020-03-23T22:40:35+09:00

あつめる（共同開発）

Git 　

・プログラムを複数人で共同開発するために使用するシステム
・共同開発には3つのステップ（1.コード変更 2.共有する準備 3.共有）がある
・共同開発では自分の変更の把握と、その中で相手に共有すべき部分を選択することが大切。

・git statusで変更したaddしていないファイル名を赤、addされたファイルを緑で表示
・git diff で変更前のコードは赤、変更後のコードは緑で表示
・git add ファイル名 で共有するファイルを選択
・git commit -m “メッセージ” で選択したファイルを記録（コミット）
・git log でメッセージ内容を確認、上ほど新しいメッセージ
・git log -p で変更内容も同時に見れる。上下キーで表示内容変更、Qキーで終了

Github

・Gitをオンライン上で管理するサービス
・ソースコードの閲覧、バグ管理、SNS機能といった開発者に必須なものが揃っている
・Gitを用いて操作ができる
・Webサイトに情報を公開できる

SSH接続

・ネットワークに接続された機器を遠隔操作し、管理する手段
・通信経路は暗号化されるため、安全にアクセスできる

1.サーバー用の公開鍵と、クライアント用の秘密鍵をペアで作成
2.SSHクライアントを操作し、ログイン意思を伝える
3.鍵が合っていることを確認して暗号化、復号化
4.暗号化完了！

リモートリポジトリ

・共有ファイルの置き場
・ファイルのアップロードやダウンロードができ、開発者同士がファイルを共有できる
・git remote add リモート名 URL で指定のURLを付けたリモート名で登録
・git push リモート名 master でリモート名にアップロード
・git pull リモート名 master でリモートからファイルをダウンロード

ローカルリポジトリ

・リモートリポジトリとは異なり、自身の手元のマシンに配置するリポジトリ
・ローカルリポジトリの内容を公開する際、リモートリポジトリにアップロードする。

クローン

・リポジトリをコピーするためのコマンド

プル　

・リモートリポジトリで管理していたファイルをダウンロードすること

プッシュ

・ローカルリポジトリで管理していたファイルをアップロードすること

プルリクエスト

・ローカルリポジトリの変更を他者に通知する機能
・多数の開発者がオープンソース開発に参加しやすくなり、高品質のコード作りが可能になる

イシュー

・開発者同士が共有し、必要な事項をスレッド形式で立てられる機能

ステージングエリア　

・Git レポジトリにコミットするファイルを置く場所
・git add で追加されたファイルが溜まる
・git commit でgitレポジトリにコミットされたファイルが格納される

アド　

・共有するファイルをステージングエリアで共有

コミット

・ファイルやディレクトリの追加・変更をリポジトリに記録する操作
・コミットでは、全気合いコミット時から現在の状態の差分の記録が作成される
・時系列にしたがって格納される
・最初のコミットはmasterブランチに追加される

ブランチ

・履歴の流れを分岐して記録するもの
・他のブランチの影響を受けないため、同一リポジトリ内でそれぞれ開発が可能
・作業ブランチはチェックアウトによって切り替える
・チェックアウトすると、最後のコミットがワークツリーに展開される
・現在使用しているブランチの先頭をHEAD

トピックブランチ

・機能の追加ややバグの修正といった課題の作業時に作成するブランチ
・統合ブランチから分岐する形で作成し、完了後に統合ブランチに取り込む

統合ブランチ

・リリース版がいつでも作成可能にしておくためのブランチ
・トピックブランチの分岐元としても使用
・通常は、masterブランチを統合ブランチとして使用
・ブランチの統合にはマージとリベースが存在する

リベース（rebase）

・作業が完了したブランチを分岐元（master）にくっつけること
・くっつけた順番でコミットが記録される
・通常は分岐先ブランチで分岐元につなぐことに注意！
・「re+base」と、ブランチの付け根を植え替えると考えるとわかりやすい

マージ（merge）

・複数の履歴の流れを合流させる
・マージ時の新しいコミットが作成され、過去の履歴は改変されない

リベースとマージの違い

・mergeは履歴が残るが複雑になる
修正内容がわかりやすいが、規模が大きくなると履歴が増える点に注意
・rebaseは履歴は単純だが元のコミットから変更内容が変わる
履歴が一本化され、見やすくなるが、競合発生時の対処が複雑になる点に注意

参考

https://www.youtube.com/playlist?list=PLh6V6_7fbbo_M3CqTeJvuXB08--fibyBu
https://backlog.com/ja/git-tutorial/stepup/04/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-23T21:45:29+09:00

きくちゆうきが残業時間とGitコミット行数の関係を調べてみた

システムエンジニアの菊池 祐騎(きくちゆうき)です。
※「100日後に死ぬワニ」の作者きくちゆうきさんとは別人です

さて、唐突ではありますが
働き方改革の流れで長時間労働のみならず従来の週5勤務も含め、様々な部分で変革が起こっています。

が、悲しいことにデータを無視した(つまり現実を見ていない)対策ばかり散見されるように思います。
そこで今回はデータドリブンをテーマに、果たして勤務日数や残業時間が仕事の成果にどう関係するのか明らかにすべく、これらとGitのコミット行数との関係性を調べてみることにしました。

先に結論：
・週5日勤務時と週4日勤務時で、コミット行数に有意な差は見られない
　→週に5日働いた日と4日働いた日で、1週間あたりの成果は変わらない
・残業時間が多いときと少ないときでコミット行数に有意な差は見られない
　→残業をたくさんしたときと、しなかったときで1日あたりの成果は変わらない

どうでしょう？
驚いたでしょうか？それとも、やはりという感じでしょうか？

それでは、今回の調査方法を解説します。

■集計・分析方法
・Gitのコミットログから週別のコミット行数を取得し、それを自身の勤怠情報(週合計残業時間など)と比較しました
・当記事でいうコミット行数とは、追加された行数のことを指します

■コミット行数の取得
コマンドラインでGitのコミット行数を調べるためのコマンドはこちら
git log --numstat --pretty="%H" --author='Gitのアカウント名' --since="集計開始日 00:00:00" --until="集計終了日(開始日+1週間) 23:59:59" --no-merges | awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d\n", plus)}'

■勤怠情報
単に日別の稼働時間からエクセルで残業時間を集計しただけ

これを読んでいる皆さんの勤怠情報とコミット行数の関係はどうでしょうか？
参考にしてみてください。

※ただし最後に付け足しますが、あくまでデータが示す事実を提示しただけに過ぎず、逆説が成り立つ(勤務日数や残業時間を意図的に制限もしくは増幅しても生産性が変わらない)ことの証明ではないです
※あらゆる人について普遍的にいえることの証明でもないです

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-23T20:40:55+09:00

名前は可愛いしやるやん、cherry-pick

はじめに

現在プログラマとして働かせていただいている会社では、developブランチへのマージや開発環境へのデプロイは全て自動化されています。
しかし、developと開発時に切ったブランチをマージする際にコンフリクトが発生した場合には、仕方なく手動でマージを行います。
ここでのブランチの切り方によっては、developに存在するが、開発用に切ったブランチに存在しないファイル等があったりもします。
こうなると、マージする際に余計な差分が出てしまうことになります。（後で詳しく解説します）
つまり、差分(コミット)を選んでマージしなければなりません。
そんな時に使えるのが、今回紹介するcherry-pickです。
名前が可愛くて好きです。
しかも私が今携わっているプロジェクトではたくさん使います。
独学でgitを勉強した際には名前すら聞いたことがなかったので、復習がてら紹介します！

状況解説

ブランチの状況を解説します。
今回は、ラインログインの機能を追加したい！ということにします。

スクリーンショット 2020-03-23 20.33.24.png

masterからdevelopブランチを切り、そのdevelopブランチからdevelop_LINEブランチを切り、そのdevelop_LINEブランチを
個人の環境へpullし、feature/LINEというブランチを個人用開発ブランチとして切っています（錯乱）。

そして、developとdevelop_LINEというブランチをマージする際に余計な差分が生まれてしまうとします。
この時点でfeature/LINEの差分はdevelop_LINEへ取り込んであるとします。

状況はこんな感じです。

いざ実践

と言っても使い方は簡単です。
まず、develop_LINEブランチへ移動します。
そこで、gitのログを確認しましょう。
すると、コミットIDが出てきますね。

$ git log

commit abcdgehrkd1fhfuqwh359.....
Merge: .......
Author: .......
Date: ...........

調べ終わったらdevelopブランチへ移動します。

ここでcherry-pickの登場！

$ git cherry-pick abcdgehrkd1fhfuqwh359.....

「abcdgehrkd1fhfuqwh359.....」はさっきdevelop_LINEで調べた、developブランチへ取り込みたいコミットIDです。

これでOKです。

あとはpushして終わりです。

ちなみに

developへのpushの権限がない場合は、developブランチからdevelopへマージするようにブランチを切り、同じ操作を行えばOKです！

あと、複数コミットを取り込みたい場合は、

git cherry-pick コミット１ コミット２ ... コミットn

これでできます:cherry_blossom:

終わり

こんな感じで、特定のコミットのみを特定のブランチへ取り込みたい時にcherry-pickは使えます。

名前が可愛いので覚えてあげましょう。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-23T20:40:55+09:00

【Git】名前は可愛いしやるやん、cherry-pick

はじめに

現在プログラマとして働かせていただいている会社では、developブランチへのマージや開発環境へのデプロイは全て自動化されています。
しかし、developと開発時に切ったブランチをマージする際にコンフリクトが発生した場合には、仕方なく手動でマージを行います。
ここでのブランチの切り方によっては、developに存在するが、開発用に切ったブランチに存在しないファイル等があったりもします。
こうなると、マージする際に余計な差分が出てしまうことになります。（後で詳しく解説します）
つまり、差分(コミット)を選んでマージしなければなりません。
そんな時に使えるのが、今回紹介するcherry-pickです。
名前が可愛くて好きです。
しかも私が今携わっているプロジェクトではたくさん使います。
独学でgitを勉強した際には名前すら聞いたことがなかったので、復習がてら紹介します！

状況解説

ブランチの状況を解説します。
今回は、ラインログインの機能を追加したい！ということにします。

スクリーンショット 2020-03-23 20.33.24.png

masterからdevelopブランチを切り、そのdevelopブランチからdevelop_LINEブランチを切り、そのdevelop_LINEブランチを
個人の環境へpullし、feature/LINEというブランチを個人用開発ブランチとして切っています（錯乱）。

そして、developとdevelop_LINEというブランチをマージする際に余計な差分が生まれてしまうとします。
この時点でfeature/LINEの差分はdevelop_LINEへ取り込んであるとします。

状況はこんな感じです。

いざ実践

と言っても使い方は簡単です。
まず、develop_LINEブランチへ移動します。
そこで、gitのログを確認しましょう。
すると、コミットIDが出てきますね。

$ git log

commit abcdgehrkd1fhfuqwh359.....
Merge: .......
Author: .......
Date: ...........

調べ終わったらdevelopブランチへ移動します。

ここでcherry-pickの登場！

$ git cherry-pick abcdgehrkd1fhfuqwh359.....

「abcdgehrkd1fhfuqwh359.....」はさっきdevelop_LINEで調べた、developブランチへ取り込みたいコミットIDです。

これでOKです。

あとはpushして終わりです。

ちなみに

developへのpushの権限がない場合は、developブランチからdevelopへマージするようにブランチを切り、同じ操作を行えばOKです！

あと、複数コミットを取り込みたい場合は、

git cherry-pick コミット１ コミット２ ... コミットn

これでできます:cherry_blossom:

終わり

こんな感じで、特定のコミットのみを特定のブランチへ取り込みたい時にcherry-pickは使えます。

名前が可愛いので覚えてあげましょう。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-23T17:16:15+09:00

リモートワークや副業で役立つ。複数の開発プロジェクトを効率的かつ安全に取り扱うための Tips 集

個人・本業・副業などで、認証アカウントや設定の異なる複数のプロジェクトを間違いを起こさず便利に使い分けるための Tips 集です。

使えそうなものをつまみ食いしてもらえると幸いです。

（前提）

作業環境

普段使っている作業環境です。必須要件ではありません。

  • Mac
  • bash

ディレクトリ構成

認証アカウントは大体案件毎に共通になり、その中に複数のプロジェクト（リポジトリ）があることも多いので、大体このような形にしています。

~/
    .bashrc
    .gitconfig
    Work/
        CompanyA/
            ProjectA-1/
                .git/
            ProjectA-2/
                .git/
        CompanyB/
            ProjectB-1/
                .git/
            ProjectB-2/
                .git/

シェル操作関連の Tips

プロジェクト毎に環境変数を切り替える。

direnv を使います。他の使い分け設定のベースとなるアプリケーションです。

# インストールして Hook を設定します。
$ brew install direnv
$ echo 'eval "$(direnv hook bash)"' >> $HOME/.bashrc
$ source $HOME/.bashrc

# git リポジトリ内で設定するかもしれないので、グローバルに無視されるようにしてあります。
# グローバルの .gitignore については後述します。
$ echo '.envrc' >> $HOME/.gitignore

インストールしたら、必要な環境変数を各ディレクト内の .envrc ファイルに書き込みます。

$ cd ~/Work/CompanyA
$ direnv edit .
# direnv に edit コマンドが用意されていますが、直接 .envrc ファイルを作成しても大丈夫です。

エディタが開くので以下のような内容に編集して保存します。

~/Work/CompanyA/.envrc
export FOO=foo
export BAR=bar

direnv allow しろという警告が表示されたら素直に従ってコマンドを実行して下さい。

デフォルトでは、遡って一番近い親ディレクトリの .envrc しか読み込んでくれないので、プロジェクト毎に定義しつつ親の案件毎のものも参照して欲しいような場合は、子の方に source_up と書いておきます。

~/Work/CompanyA/ProjectA-1/.envrc
source_up

export FOOBAR=foobar

重複した場合は、子の方で上書きされます。

これで、そのディレクトリ配下に移動するだけで、さまざまな作業環境が一度に切り替わることになります。（後述する設定を追加していくことで）

~/.bashrc などに移動コマンドの alias を登録しておくと Tab 補完も効いて便利です。

~/.bashrc
alias company_a='cd ~/Work/CompanyA'

.bashrc を分けて管理する。

案件固有のシェル設定は .bashrc を分けておいて、本体の方では以下のようにファイルを読むこむだけにしておけば、~/.bashrc が散らからずプロジェクト終了時にメンテナンスもしやすいです。

~/.bashrc
for rc in $(ls $HOME/work/*/.bashrc 2>/dev/null); do
  source $rc
done

自動的にファイルを探しにいくので、案件が追加された場合は（必要に応じて）ディレクトリ直下に .bashrc を作るだけで OK です。

Git 関連の Tips

いつも使う Git 設定をグローバル化する。

~/.gitconfig を用意しておけば、グローバルに設定が反映されます。

git config --global で設定した内容が書き込まれる場所なので、こちらのコマンドで設定しても OK です。

使い勝手の向上や、いつも付けておきたいコマンドオプションを書いておきます。

例えば以下のようなものです。

~/.gitconfig
[alias]
    st = status
    ci = commit
    co = checkout
    br = branch
[color]
    ui = true
[merge]
    tool = vimdiff
    ff = false
[pull]
    ff = only
[core]
    autocrlf = false
    quotepath = false

いつもリポジトリに Commit しないファイルを、グローバルの設定で自動的に無視する。

自分の環境だけに生成されるファイルを Git から無視したいことはよくあります。しかし、プロジェクトの .gitignore に書き込むのは抵抗があったり、毎回 .git/info/exclude に追記するのが面倒だったりします。

毎回無視しても大丈夫という確信のあるものについては、グローバルに設定してしまいます。

# ホームにある .gitignore をグローバルの無視設定ファイルにします。
$ git config --global core.excludesfile ~/.gitignore

あとは無視したい内容を ~/.gitignore に書いておけば以降は自動的に無視されます。direnv の設定ファイルもここに書いてあります。

~/.gitignore
.DS_Store
.envrc

確信がない場合は、リポジトリ毎に .git/info/exclude をメンテするようにします。

Git のユーザー情報（など）を自動的に使い分ける。

よくあるのが Git ログに書き込まれる名前とメールアドレスの使い分けです。

仕事用の新しいリポジトリで、誤ってグローバルに設定してあるプライベートなメールアドレスを入れてしまったり、リポジトリ毎に毎回設定するのが面倒だったりします。

案件毎に作った親ディレクトリで一括管理し、配下のリポジトリは自動的に同じ設定が適用されるようにしたいと思います。

git config の Conditional includes を使います。

  1. 案件毎のディレクトリ直下に専用の設定ファイル ~/Work/CompanyA/.gitconfig.inc を用意します。

    ~/Work/CompanyA/.gitconfig.inc
    [user]
  name = name_on_work
  email = name_on_work@example.c0m

  2. ~/.gitconfig にディレクトリごとのファイルを読みに行くよう設定を追加します。

    ~/.gitconfig
    [user]
  name = name_in_private
  email = user_name_in_private@users.noreply.github.c0m

[includeIf "gitdir:~/Work/CompanyA/"]
  path = ~/Work/CompanyA/.gitconfig.inc

[includeIf "gitdir:~/Work/CompanyB/"]
  path = ~/Work/CompanyB/.gitconfig.inc

これで direnv のように、特定のディレクトリ配下では専用の設定が適用されるようになります。

ユーザー情報以外に、独自の Git 規約があるような場合にも使えます。

GitHub の複数アカウントを使い分ける。

GitHub ではアカウント間で SSH Key を使い回すことができないので、複数の SSH Key を管理することになります。

この状態では少し手を加えないと SSH 認証での git コマンドが通らないアカウントが出てきます。

アカウントが異なるのは大体案件単位なので、前項で作った ~/Work/CompnayA/.gitconfig.inc 内で設定を行います。

~/Work/CompanyA/.gitconfig.inc
[core]
  sshCommand = "ssh -i ~/.ssh/id_rsa_company_a

~/.ssh/id_rsa などの、 ssh がデフォルトで読みに行くキーを使っているアカウントは設定不要です。

クラウドサービス関連の Tips

主に CLI ツールを使ったクラウドサービスの操作に関する手順です。

意図せず本番環境を書き換えてしまったりすることがないよう、設定切り替えをなるべく自動化したいと思います。

GCP 環境を自動で切り替える。

gcloud や bq コマンドでの、操作を行うアカウントや対象のプロジェクトを切り替えます。

これらコマンドを含む Google Cloud SDK には、アカウントやプロジェクトなどのプロパティを保持する「構成」を複数作成して、適宜切り替え可能な仕組みが用意されています。

SDK 構成の管理  |  Cloud SDK のドキュメント  |  Google Cloud

単純には以下のような流れになります。

# 好きな名前を付けて、新しい構成を作成します。
$ gcloud config configurations create [NAME]

# 構成のプロパティを設定していきます。（以下は例）
$ gcloud auth login
$ gcloud config set project [PROJECT_ID]

# 別の構成に切り替えるのは activate コマンドになります。
$ gcloud config configurations activate [NAME]

# 作成された全ての構成のリストは、以下で確認できます。
$ gcloud config configurations list

gcloud config configurations activate で切り替えていく仕組みも十分便利なのですが、全コンソールセッションで同じ構成が有効になるという（自分の使い方では）問題があります。

  • コンソールセッション毎に有効な構成を変えたい。
  • direnv と連携して、今いるディレクトリに応じて自動的に構成を変えたい。

という挙動にしたい場合は、上記の設定に加えて direnv の .envrc に設定を付け加えます。（公式ドキュメント にも記載があります。）

~/Work/CompanyA/.envrc
export CLOUDSDK_ACTIVE_CONFIG_NAME=CompanyA-dev # gcloud config configurations create で付けた NAME を指定します。

AWS 環境を自動で切り替える。

aws コマンドでの、アクセスキーを元にした認証情報や初期リージョン設定などを切り替えます。

aws コマンドをインストールした直後、aws configure コマンドでアクセスキーや初期リージョンを入力させられると思います。

この時 default の Profile が作成されるのですが、Profile は複数作成することができます。

以下のような流れになります。

# 好きな名前を付けて Profile を作成します。
$ aws configure --profile=[NAME]
# アクセスキーや初期リージョンの入力が求められ、Profile が作成されます。

# Profile を指定してコマンドを実行できます。
$ aws s3 ls --profile=[NAME]

# 作成された全ての Profile は、以下で確認できます。
$ cat ~/.aws/config

# 現在有効な Profile は以下で確認できます。
$ aws configure list

Profile は、環境変数 AWS_DEFAULT_PROFILE によって切り替えることができるので、これを direnv を使って自動設定されるようにします。

~/Work/CompanyA/.envrc
export AWS_DEFAULT_PROFILE=[NAME] # aws configire --profile= で付けた NAME を指定します。

Kubenetes 環境を自動で切り替える。

kubectl コマンドでの、操作を行うユーザーや対象のクラスターを切り替えます。

kubectl ではユーザーとクラスターを組み合わせて context として管理し、適宜切り替え可能な仕組みが用意されています。

Configure Access to Multiple Clusters - Kubernetes

ですが、gcloud の場合と同じくデフォルトの状態では、全コンソールセッションで同じ context が有効になってしまいます。

また、自動切り替えも実現したいため、 ここでも direnv を使って（context の保存ファイルを変更する）KUBECONFIG 環境変数が自動設定されるようにします。

※ context を設定する前に行う必要があります

~/Work/CompanyA/.envrc
export KUBECONFIG=$(pwd)/.kubeconfig

あとはディレクトリに入って context を作成し利用します。(以下は GKE の場合の例）

# 認証情報を取得して context を作成する。
$ gcloud container clusters get-credentials company_a_cluster_name --region us-west1

# 作成された全ての context は、以下で確認できます。
$ kubectl config get-contexts

# 自動で長い名前が付いているので、気になるようなら分かりやすい名前に付け替えます。
$ kubectl config rename-context [OLD_LONG_NAME] [NAME]

# context が 1 つの場合は、いつもそれが有効になります。
# 複数の context を作成した場合は、 適宜 use-context コマンドで切り替えます。
$ kubectl config use-context [NAME]

現在の状態をターミナルに表示して注意を促す。

プロンプトにクラウドサービス毎の現在の設定名を表示しておくと、すぐに確認できて間違いも起きにくいです。

リスクのある環境になっている時だけ表示された方がアラートになるので、プライベートな環境には 'default' や 'private' といった設定名が付くようにしておいて、その場合は何も表示しないようにしています。

~/.bashrc に以下のような内容を追記しておくだけです。

~/.bashrc
function cloudps1() {
  if [ -x "`which gcloud`" ]; then
    __gcp=${CLOUDSDK_ACTIVE_CONFIG_NAME:-default}
  fi

  if [ -x "`which aws`" ]; then
    __aws=${AWS_DEFAULT_PROFILE:-default}
  fi

  if [ -x "`which kubectl`" ]; then
    __kube=`kubectl config current-context`
  fi

  if [ -n "${__gcp}" ] && [ "${__gcp,,}" != 'private' ] && [ "${__gcp,,}" != 'default' ];then
    echo -en "${__gcp}\U1F176 "
  fi

  if [ -n "${__aws}" ] && [ "${__aws,,}" != 'private' ] && [ "${__aws,,}" != 'default' ];then
    echo -en "${__aws}\U1F170 "
  fi

  if [ -n "${__kube}" ] && [ "${__kube,,}" != 'private' ] && [ "${__kube,,}" != 'default' ];then
    echo -en "${__kube}\U1F17A "
  fi
}

PS1='\[\e[01;30;43m\]$(cloudps1)\[\e[00m\]'$PS1
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-23T13:49:14+09:00

githubに別アカウントでプッシュする方法 - 間違えて他のgithubアカウントでpushしたとき

間違えて会社のアドレスで作ったGitHubアカウントじゃなくて私用のアカウントでcommitしpushしたとき、見ず知らずのアカウンが、チーム開発のリポジトリのcommitに乗ってしまうことがあります。

そんなときは、ローカルで、下記のように実行して直して

% git config user.name ryosuke.fujisawa 
% git config user.email ryosuke.fujisawa@社用アドレス.com

んで、確認して

% git config user.name   
% git config user.email

上記のコミットは間違って私用アカウントでpushしたものですよとチームに伝わればok

 % git commit --allow-empty -m "gitユーザーの変更"
 % git push
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-23T10:05:44+09:00

小技集: tigからファイルを削除したい

WHAT

tigからファイルを削除する方法

$HOME/.tigrcに以下を追加

bind status D !rm %(file)

ハイライトされているファイルに対して, ctrl+dでtigからファイルを削除できます

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-23T09:34:39+09:00

remoteブランチをcheckoutする方法 - Git

まずはフェッチしてリモートのブランチをローカルの追跡ブランチへ持ってくる

% git fetch

フェッチされた追跡ブランチを見る、ここにあればチェックアウトできます

% git branch -a                                           
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/feature/dev

追跡ブランチをローカルの新しいブランチとしてチェックアウトする、これでリモートへpushできます

% git checkout -b dev origin/dev
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧