MacOS ユーザが WSL では無い Windows のコンソール環境を整える - 2nd life (移転しました)
先日、メインの開発環境を MacOS から Windows 10 Professional へと移しました。理由としては主に2点で、現在仕事を自宅の固定席で行っており PC を持ち運びする必要がなくなったため Mac より高速で安価な Windows デスクトップ機を使いたいこと(Ryzen 9使いたい!)、WSL2 が正式版となり使ってみた感じ問題なく WSL2 で仕事の開発ができそうだったことが挙げられます。 WSL2 はふつうに Linux なので問題なく開発環境の構築が行なえ、Windows からも VSCode Remote のおかげでで違和感なくWSL2上のコードを編集、実行ができ快適な開発が行えています。(なお、WSL2 についての記事は山程溢れているので、ここでは殆ど触れません。) しかしながら、WSL2 ではないふつうの Windows 上で開発する機会が出てきたので、M
master への push を禁止するローカル git hook の正しい書き方 - 永遠に未完成
GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。 GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。 何がまずいのか 上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。 しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin maste
GitHub - liquidprompt/liquidprompt: A full-featured & carefully designed adaptive prompt for Bash & Zsh
There are many prompts configurations out there, but here is what makes Liquid Prompt stand out: UX Design: The Liquid Prompt was very carefully design from the beginning, to allow for the best user experience. That is, it displays meaningful information with minimal visual clutter and maximum readability. While most of the other prompts are focused on aligning as much colored "segments" as possib
gitが無くてもgit cloneするコマンドfakegitを作りました - hnwの日記
最近は一段とGitHubが流行してきたように思います。多くのオープンソースプロジェクトがGitHubに移転するなど、いまやOSS開発者にとっては無くてはならない存在ですね。 ところで、GitHubにホストされているプロジェクトの中には、インストール方法として「git cloneしてね」などと書いてあるものがあります。確かに開発者の立場からはgit cloneが一番自然な方法かもしれませんが、ソフトウェアのユーザー全員がgitコマンドを用意しているとは限りません。 もし、こうした意識のズレがソフトウェアの普及を妨げているとすれば不幸なことです。この事態を解決するため、gitコマンドがなくてもGitHubからのgit cloneをエミュレートするbashスクリプト「fakegit」を作ってみました。 fakegitは、指定されたGitHubリポジトリからのダウンロードをgit以外のコマンドで実
uu59のメモ | VCSとITSとテストがない開発環境で正気を保つには Part 1 git 編
Part 0 プロローグ まずバイト初日、サーバに入れるようになったあと、scpとrsyncを適当に使って指示された変更に関係しそうなファイルをダウンロードします。だいたい揃ったらgit init; git add -A; git commit -m "ファイル取ってきた(noedit)"でとりあえずの体制は構築できました。 ここから開発を進めていくわけですが、色々と難関があります。 sjisとeuc-jpのファイルが混在してるのでgit diffが文字化けして使えない lvやnkfにパイプしても、そもそも異なる文字コードの文字列が混在してるのでどうしようもありません。これを解決するにはdiff.externalを設定して、ファイルごとに自前でdiffを取ります。 $ cat ~/mydiff.bash #!/bin/bash old=$2 new=$5 # バイナリは無視 if [ -n
メモcache: gitを知らないデザイナとgitで共同作業するには？
2009/12/14 gitを知らないデザイナとgitで共同作業するには？ デザイナとgitで共同作業するまでの過程をログに残しておきます。 第一段階 会社で使っているフレームワークの Vの部分(いわゆるテンプレートまわりとか)はデザイナもさわるので、 .gitignore で無視することにして、 フレームワークのMVCのVの部分を除いてプログラマしかさわらない部分だけの リポジトリを作ってgitでバージョン管理することにした。 第二段階 ところが、Vの部分はデザイナしか関わらないわけではありません。 当然のごとく、プログラマ側から 「できればVの部分もgitでバージョン管理したい」 との要望がでてきました。 第三段階 そこで、デザイナに「バージョン管理は何を使っていますか？」 と聞いてみたところ「Mac の Time Capsule です。」 と言われ若干放心状態に…。 確かにバージョン
zshでもbashと同じくらい快適にgit補完関数を使う | uuu
zshにおけるgitの補完関数の実装はいまいちでした。zsh + git使いはzshの補完関数_gitを速くしたい! その2のような対抗策を講じるか、gitのときだけbashを使うかしていました。僕は一時期後者でした。 さてgitのtarballにcontrib/completion/git-completion.bashというのがあるのはディープなgit使いならご存知かと思います。残念ながらファイル名の通りbashでしか使えませんでしたが、v1.7.4-rc0でzsh compatibleになりました add the following lines to your .zshrc: autoload bashcompinit bashcompinit source ~/.git-completion.sh と指示通りに.zshrcに追記するだけでzshでもbashなみの快適さでgitを使え
gitのブランチ名をプロンプトに表示すると結構便利 - （ひ）メモ
gitの配布物に含まれる contrib/completion/git-completion.bash を . すると、gitのサブコマンドやそれに応じたオプション、加えて~/.gitconfigで自分用にaliasしたサブコマンドまで補完してくれるようになり、小学生もにっこりです。 同じく git-completion.bash の中で定義されてる関数 __git_ps1 を使ってシェルプロンプト($PS1)を設定すると、 #... if [ -r "$HOME/.bash_completion.d/git" ]; then # = git-completion.bash # boldにするエスケープシーケンスは省略してます PS1="${PS1}[\$(__git_ps1 \"%s)\")\w]\\$ " else PS1="${PS1}[\w]\\$ " fi #...こんなふうにg
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitを使い始めたらやっておきたい便利な設定いろいろ