Windows GitBash で Python・Node.js・Docker が上手く動かない場合は winpty を設定する - Corredor
Windows GitBash にて、$ python や $ node コマンドを叩いて、プロンプト上で簡単なコードを動かしてみたかったのだが、どうもプロンプトの応答が戻ってこない。 また、$ docker 関連のコマンドを使うと、以下のようなエラーメッセージが返ってきた。 $ docker exec -it my-container bash the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty' 調べてみると、GitBash では、一部の対話式プロンプトを伴うコマンドは winpty というコマンドを経由して実行してやらないと、上手くプロンプトが表示されないようだ。 まずは解決法だけ winpty を設定している /etc/profile.d/ali
git pull実行時にローカルで未コミットの変更を保持する方法 | DevelopersIO
git pullを実行する際に、ローカルで未コミットの変更に対して、リモートの状態で上書きせず、ローカルでの変更を保持したい場合や、やっぱりリモートの変更で上書きしたくなった場合の対処方法についてのご紹介です。 こんにちは、CX事業本部の若槻です。 git pullを実行する際に、ローカルで未コミットの変更をリモートに反映させずローカルでだけ保持したい場合があります。 例えば、以下のようにhoge.txtの変更がローカルで行われていますが、この変更はリモートには反映したくないため、未コミットとしています。 $ cat hoge.txt ローカルでの変更 $ git fetch $ git diff remotes/origin/master diff --git a/hoge.txt b/hoge.txt index 48ee78d..e3130ae 100644 --- a/hoge.t
難しいGitコマンドは、仕組みから理解してみよう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらはLife is Tech ! Advent Calendar 2016 22日目の記事です。 自己紹介 こんにちは！先日GitHubのIDがha1fha1fからha1fになりました、はるふ(@_ha1f)と申します。 Life is Tech ! では、主にiPhoneコースのメンター・講師をしています。 本記事について Gitについての記事は、世の中に多くあります。 gitコマンドの使い方 gitの仕組み gitを用いたプロジェクト管理・運用 subversionなどとの比較・歴史 など、テーマが色々有ると思いますが、本記事で
【入門者向け】Gitのstatusコマンドの使い方
「git status」はバージョン管理の状態を確認するためのコマンドだ。 このページではgit statusコマンドの使い方と、情報の見方について解説を行なっていく。 statusコマンドの基本 このコマンドは、ワーキング・ツリーの状態を表示するためのものだ。以下に示す条件でコンテンツのパスが表示される。 ワーキング・ツリーに追跡されていないものがある。 ワーキング・ツリーとインデックスに違いがある。 コミットされたものとインデックスに違いがある。 コマンドの基本は簡単だ。 git status [オプション] このコマンドを実行すると、下記のようなコンテンツの状態が表示される。 では、実際の使い方と、どのように状態が表示されるかを見てみよう。 追跡されていない場合 新たなファイル；Program01.javaをワーキング・ツリーに加えただけだと、statusコマンドで表示されるのは「追
Git初心者が絶対に覚えておくべきコマンド - idesaku blog
Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる！massageじゃない、messageだ！マッサージを作ってどうする！ 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi
Gitのマージを図解する | To Be Decided
このエントリでは、Gitが提供するマージのための機能の内、主なもの4つ、真のマージ、リベース、ファストフォワードマージ、チェリーピック について図解する。 ここでマージとは、とあるブランチのコミットが入れた修正を別のブランチに取り込むこととする。 この記事を事前に読んでGitのオブジェクトモデルを理解しておくと分かりやすいかもしれない。 ここで説明するマージは全てローカルリポジトリ内のブランチを操作対象とする。 真のマージ 真のマージは、複数のブランチでそれぞれ開発が進んでいて、つまりそれぞれのコミットグラフが伸びている場合に、それらの修正を統合するときに実行する。 マージするブランチはいくつでも指定できる。 基本的なコマンドはgit merge <ブランチ(複数可)>。 操作に成功すると、マージ後のプロジェクトの状態を表すコミット(マージコミット)が作られ、カレントブランチの先頭に追加さ
GitのHEADとは何者なのか - Qiita
最初に なんとなくでも使用できるGitですが実はとても奥深く複雑な構造をしています。 そんなGitを使い始めた時ほぼ全員が思う「HEAD」とは何者なのか説明したいと思います。 また合わせて「Branchとは」「detached HEADとは」についても話します。 先に結論ファーストで話しますと HEADとは 今自分が作業している場所を示すポインタ Branchとは 開発の本流から分岐し、本流の開発を邪魔することなく作業を続ける機能 detached HEADとは HEADがBranchを指していない状態のこと そして僕自身以前までブランチとはなにか聞かれた場合、下図のようなイメージを持っていました。 そしてこれは誤った認識です。 この記事はMake IT アドベントカレンダー9日目の記事として寄稿しています！ 明日は @wh1tecat が投稿する予定です。 楽しみですね（笑） Branc
git reset についてもまとめてみる - murankの日記
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
gitのコミットの歴史を改変する(git rebase) 1 / 2 · けんごのお屋敷
git には rebase というとても便利なコマンドがあります。その中でも特に便利なのが -i または --interactive オプションです。便利なのですがよく忘れるのでまとめもかねてこの記事で詳しく紹介します。 前提 この記事では説明のために以下のようなコミット状態である前提で話を始めます。よくあるコミットの流れです。 git rebase -i -i は --interactive とあるように、対話的に rebase が実行できるコマンドです。これでなにが出来るかというと コミットメッセージを編集する コミットをまとめる コミットを分割する コミットの順番を移動させる コミットを削除する など、いろんなことが出来ます。基本的な構文は [kengo@tkengo-mac] $ git rebase -i <commit> これだけ。 <commit> には特定のコミットを指定し
Gitのリポジトリの中身をなるべく正確に理解する | To Be Decided
このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO’Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使えるようになったり、なにより、Gitを使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェクトをクローンしたときとかにできる.gitディレ
git rebase についてまとめてみた - Qiita
git rebaseについてまとめてみた はじめに なんとなくでしかgit rebaseを使ってないなと思ったので、 git manualなどを読んで自分なりのメモを残すことにしました。 ここ(Qiita)に上げておけばきっと読み返す機会が多くなるはず。 そもそも、この記事の投稿時は仕事でGITを使っているわけではなく、個人で使うオプションも、ほぼ"--continue"と"--abort"だけなので、 この際、きちんと他のオプションも理解しておきたいと思いました。 もしも、記事の中で間違いなどありましたら、編集リクエストやコメントなどで教えていただければ幸いです。 ※オプションも全て記載しようと思ったのですが、結構な量があったため断念 今後、使用する機会、リクエストや学ぶ機会があったら追記もしくは別記事で投稿します。 注意事項 ※多人数で開発している場合すでにプッシュしているコミットを改
【Git】追跡を維持したままフォルダ名やフォルダ構成を変更する方法 | プログラミング実践.com
Gitでソースコードの管理を始めたは良いけど、途中でプロジェクト構成を変更したくなったことはありませんか？ もしくは、名前空間の変更に伴ってフォルダ名を修正したくなったりしたことはありませんか？ Finderやエクスプローラで変更すると、元のファイルが消えた扱いになってしまったりして、ちょっと微妙な感じになってしまいますよね。 実は、既存の履歴を維持したまま、フォルダ名やフォルダの配置を変更するコマンドがあるんです。 その便利なコマンドは「git mv」コマンドといいます。 参考：Git – git-mv Documentation 今回はGitで既存の履歴追跡を維持したまま、フォルダの名前や構成を変更する方法についてご紹介しますね。 そもそもGitがよくわからないよ、という場合は、まず入門用の書籍を1冊読んでみるのが良いと思います。
Gitの複数コミットをrebaseとsquashでまとめる方法
コミットをまとめる コミットをまとめるにはGitのrebaseを使用する。 (ほかにも方法があるが割愛) まず下記のコマンドでログを表示。 git log --oneline 例としてこのようなログが表示されたとする。 C:\test>git log --oneline 6b78b9d last commit d12871a test3 db92104 test2 e4ae077 test1 fe87ecf first commit 今回はtest1, test2, test3のコミットをまとめてtest allにする。 まず以下のコマンドを入力。 git rebase -i fe87ecf するとテキストエディタが起動してこのような内容が表示される。 pick ～の中にfe87ecf first commitが含まれていないのはgit rebase -i fe87ecfはfe87ecfよ
EKSでFlux with KustomizeのGitOpsチュートリアルを試してみた | DevelopersIO
はじめに おはようございます、もきゅりんです。 先日、EKSでWeave Fluxを使ってGitOpsしてみる によって、かなり楽にk8sでCI/CDを体験することができました。 しかし、実用の場面ではstg, prodといった複数の環境ごとに設定の調整することを考慮しなくてはなりません。 ということで、Kustomize *1 を使ったFluxでGitOpsを再びEKSでやってみました。 Using Flux with Kustomize を元に進めていきます。 このチュートリアルのシナリオとしては、staging と production と2つのk8s clusterがあり、それぞれに設定される最小のpod数がstgが1つ、prodが2つとなっていますが、この稿では、1clusterで2回デプロイすることで対応します。 環境について EKS Workshpの GETTING STAR
EKSでWeave Fluxを使ってGitOpsしてみる | DevelopersIO
おはようございます、もきゅりんです。 最近は故あって、空いた時間をひたすら Amazon EKS Workshop に費やしております。 非常にコンテンツがボリューミーで中身が濃いです。 そのコンテンツの中から、GITOPS WITH WEAVE FLUXをやってみた、というものです。多少の行間を埋めるように心掛けました。 元々は、こちらのブログの内容かと思います。 Deploying GitOps with Weave Flux and Amazon EKS 今回やることの趣旨を簡単に述べると、Gitのみをソースとして、EKSにContinuous Delivery(以下CD。継続的なデリバリ)する、という内容です。 よく似たツールに Argo CD があります。 弊社記事でも紹介されています。 EKSでArgo CDのチュートリアルを試してみた Argo CDと同様、Pull型の同期で
gitlab.com で いますぐCI してみよう - Qiita
QiitaでもMicrosoftによるGitHub買収でいろいろと盛り上がっていますが，よほどのアンチMSでもなければ，特にGitHubからGitLabへ移行することも無く「ふーん」で終わってしまうでしょう． しかし，GitLabにはGitHubには無い魅力も満載です！ （わかりやすいところでは，プライベートリポジトリが無限に作れるところとか．GitHubもMicrosoftに買収されてやってくる気もしますが） 見方によっては本番DBを吹き飛ばしかけたところも，とてもお茶目でかわいらしいですね GitLabの目玉機能 CI/CD Pipeline 今回はその魅力の一つ， CI / CD機能のご紹介です． もちろん無料です （が， 1ユーザ1ヶ月あたり2,000分の制限があります ） GitHubの場合，別途 Travis や CircleCI，Drone.ioといった外部のCIサービスと，
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
忘れやすい人のための git diff チートシート - Qiita
[To Be Decided ~]$ find /tags/git/
Gitの社内勉強会資料 | To Be Decided