My VSCode Config
Hi fellow devs, For my first post, I'm just documenting my VSCode configurations here for posterity's sake or just for my reference later. Keep in mind that this list is going to be language agnostic and more so utility/aesthetic suggestions (though these are inevitably tied to what languages I work with, so take that as you will). Please feel free to suggest any good extensions that I've missed o
主にVSCodeではじめるPython開発環境構築ガイド | DevelopersIO
ファイル比較 VSCodeのエクスプローラで、ファイル２つを選択して右クリックメニューから「選択項目を比較」で比較することができます。 また右クリックで、「比較対象の選択」をした後に「選択項目を比較」でも比較することも可能です。 VSCodeのSnippetの使い方 VSCodeのSnippetも便利です。似たような構造のクラスを実装する場合などや、プロジェクト共通で使いがちな書き方というものをSnippetに登録して、効率化することができます。 また、変数を持たせておくこともできます。この場合、Snippetを呼び出した後に変数部分にカーソルがあたるので、そこで変数部分をタイピングできます。 詳細は以下のリンクをご覧ください。 Visual Studio Codeに定型文（スニペット）を登録する方法 VSCodeのUser Snippetを活用しよう！ また後述するSnippet Gen
『GitUI』を使ってターミナルからでも直感的なGit操作を｜NAVITIME_Tech
こんにちは、みみぞうです。 ナビタイムジャパンで『システムや開発環境、チームの改善』を担当しています。 今回はターミナルで動くGitクライアントツール『GitUI』を紹介します。 本稿は以下のいずれかに当てはまるような方をターゲットにしています。 ターミナルで動くGitクライアントツールを探している方 NeovimからシームレスにGitの操作をしたい方 Windowsで使えるGitクライアントツール探しに困っている方 ℹ️ Neovimは、Vimをベース拡張性を考慮してモダンな技術で作られたプロダクトです。 GitUIとは『GitUI』はターミナル上でもGUIのように快適なGit体験を提供するOSSのツールです。 GitUI provides you with the comfort of a git GUI but right in your terminal extrawurst/gi
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更
GitHubは、これから新規に作成されるリポジトリのデフォルトブランチ名が「main」になると発表しました。これまでデフォルトブランチ名は「master」でした。 既存のリポジトリにはこの変更は適用されませんが、年内にも既存のリポジトリでもデフォルトブランチ名の変更を可能にする予定だと説明されています。下記は「The default branch for newly-created repositories is now main」からの引用です。 Existing repositories are not impacted by this change. Later this year, you'll be able to rename the default branch for existing repositories for your user, organization, or
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
GitHub、作業中（WIP）のPull Requestを示す「Draft Pull Request」機能を発表
GitHub、作業中（WIP）のPull Requestを示す「Draft Pull Request」機能を発表 GitHubは、新機能「Draft Pull Request」を発表しました。Pull Requestを発行する際に、通常のPull Requestにするか、あるいはDraft Pull Requestにするかをドロップダウンメニューで選べるようになりました。 Draft Pull RequestはPull Requestをドラフトの状態として発行します。これは、このPull Requestがコードのレビューやマージまで到達しておらず、作業中（WIP：Work In Progress）であることを明示的に示したい場面で用いることを想定しています。 Draft Pull Requestとして発行されたPull Requestではマージボタンを押せなくなっており、不用意にコードがメ
[macOS向け] gitのクライアントはGitUpがいいぞ。 - Qiita
ツイッタフォローしてやで(ﾎﾞｿｯ https://twitter.com/JotaroUT いろいろ使ってみたけどGitUp、やめられませんでした。 Macbookをスタバで開いてはプロジェクトをgitで管理する機会の多いであろう諸兄・諸姉のために、独断でイケてるなと思ったgitのGUIクライアントについて紹介したい。その名もGitUp。 GitUp : http://gitup.co/ GitUpとは GitUpはmacOS用に開発されたgitのGUIクライアントである。 公式ホームページに、 Work quickly, safely, and without headaches. とあるように、確かに使っている間は頭痛がしない気がする。大きな特徴としては、謳い文句の通り、 早い。 ざっくりした使い方 コミットを参照する。 ここでは、openFrameworks (https://op
![[macOS向け] gitのクライアントはGitUpがいいぞ。 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9cff9c96a28cc3077d4bd2b98bfe29257b729956/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCbWFjT1MlRTUlOTAlOTElRTMlODElOTElNUQlMjBnaXQlRTMlODElQUUlRTMlODIlQUYlRTMlODMlQTklRTMlODIlQTQlRTMlODIlQTIlRTMlODMlQjMlRTMlODMlODglRTMlODElQUZHaXRVcCVFMyU4MSU4QyVFMyU4MSU4NCVFMyU4MSU4NCVFMyU4MSU5RSVFMyU4MCU4MiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YjI1NDlmNGE3ZDUxYmZkNWQ3MTE4ZWQyN2M0YWE0YTE%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBKb3Rhcm9TJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1kOTU1ZmZiNmExMWE4YWYyNjRhMTZmM2M4NzE5ZWNlMg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd18c2743a394d738a76f3ab95cd53758)
Gitはどうやってテキストファイルとバイナリファイルを自動識別しているのか？ - Qiita
tl;dr 先頭 8000 バイト以内に NUL が有ったらバイナリファイル。 Gitの実装 Gitの内蔵diffは FIRST_FEW_BYTES だけ検索するようになっている。 https://github.com/git/git/blob/6e0cc6776106079ed4efa0cc9abace4107657abf/xdiff-interface.c#L187 #define FIRST_FEW_BYTES 8000 int buffer_is_binary(const char *ptr, unsigned long size) { if (FIRST_FEW_BYTES < size) size = FIRST_FEW_BYTES; return !!memchr(ptr, 0, size); }
git-updateがクソ便利 - くりにっき
git-sync にインスパイヤされて作りました qiita.com ソースコード gist.github.com モチベーション 例えばトピックブランチで作業してて、リポジトリのmasterが更新されたから最新のmasterを取り込んでrebaseするってことよくやると思うのですが、その時にいちいち git checkout master git pull --ff git checkout topic_branch git rebase master みたいなことをやるのが大変なのでサブコマンドにしました。 *1 3ヶ月くらい使ってるけど割と開発が捗ってます。 ~/.gitconfig のaliasにも up = update で登録してるので、1時間に1回くらいは g up 叩いてるんじゃないかなｗ https://github.com/sue445/dotfiles/blob/65
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだGitGitHub小説 タイトルは釣りではありません。 最近、小説の執筆にあたって Git を導入して原稿の進捗履歴を管理しました。めちゃくちゃ便利でした。 GitHub を使って友人と一緒に校正校閲の作業をしました。めちゃくちゃ捗りました。 短編 SF 小説が短期間で完成しました。でも広告が目的ではないのでリンクは貼りません。 Git のことを何も知らない奴が Git と GitHub の使い方を覚えたら便利だったし捗ったので、記事にしてしまおうぜという試みです。 2019年1月4日 追記 本記事は「執筆」および「校正・校閲」の段階における Git と GitHub の有用性を主張する記事です。 「組版」や「デザイン」の段階における Git の有用性について
JenkinsとGitLabとAWS CodeBuildを連携する
はじめに JenkinsからAWS CodeBuild Plugin経由でビルドを実行しCIを実行する手順を以下にまとめます。 AWS CodeBuildはAWSが提供しているビルドサービスで、buildspec.ymlを設定すると指定したコンテナ上で処理を実行してくれます。 AWS CodeBuildはGitHubやGitBucketからは直接webhookで連携することができますが、残念ながらGitLabは対応していないため、Jenkinsとプラグインを経由して実行するようにします。 前提 Jenkins、GitLabがAWS上に構築されていてそれぞれお互いに連携可能な状態であることを前提とします。 JenkinsとGitLabの連携についてはこちらをご参照ください。 AWS CodeBuildを設定する 「ビルドプロジェクトを作成する」を選択してビルドプロジェクト作成画面へ遷移します
gitのmerge --no-ff のススメ - Qiita
2015年も終わりになって、gitの基本的な使い方の話に更なる需要があるとは思っていないのですが 本日が私のAdventCalender担当日であることと、本日偶然遭遇したトラブルの都合上、もしかしたらまだ需要が微レ存かもしれないと思い記事を書いていきたいと思います。 まとめ 皆しとくといい。 git のデフォルト設定はどうなっているか gitはデフォルトではmergeコマンドを使った際に、mergeコミットを発生させる必要がない場合mergeコミットを発生せずにmergeを行うfast-forwardでのmergeを行うようになっている。 --no-ffというオプションを付けることで意図的にfast-forwardを行わないコミットをすることが出来る。 どういうトラブルが起こるか 仮にmasterにtopicAブランチをmergeしたとする。 fast-forwardであるmergeの場
最近GitLabの人気が高まっているらしいので、GitHubのリポジトリをミラーリングしてみた - えいのうにっき
先日、「最近、GitLabの人気が高まっているらしい・再評価されているらしい」と同僚（先輩）から聞いた。あくまでもその人の観測範囲で、ではあるが、GitHub から GitLab に乗り換えたって人も何人かいるらしい。 GitLab の GitHub に対する優位性のひとつとして、CI ツールとコンテナレジストリがバンドルされていることがある、んだそう。なるほどたしかに、CI とかコンテナレジストリってそのリポジトリとの関係は密でもいい・密にしておきたい、ってかんじがするもんなぁ。 GitLab、僕のなかでは「セキュリティなどの理由により、github.com を使うことができないケース」「コストなどの理由で GitHub Enterprise を使うことができないケース」で、"自分たちの環境" に "自分たちで" セットアップして使うもの......という印象だったんだけど、そうか、普通
git rebaseの使い方をやっと理解したので忘備録 - Perlテックブログ(跡地)
git rebaseの使い方をやっと理解したので忘備録を書いておこうっと。 他の人とのやりとりはgit mergeだけで十分 普段の作業はgit mergeだけで十分。ほぼすべての場合は、git mergeだけで十分。これを肝に命じておく。 git rebaseはコミット粒度を上げるためにgit branchとセットで使う git rebaseとは、小さな多数のコミットを、ひとつのコミットにまとめたいときに使う。 少し修正して、commit、試験。少し修正して、commit、試験。少し修正して、commit、試験。普段の作業はこんな感じじゃないのかな。 でも、コミットのメッセージを書く単位よりも小さく、コミットしたいときはよくある。ここ一行だけ変えて、試験したいとかね。コミット粒度を小さくしておけば、間違った部分だけを、git revertで戻せるし、git resetで戻れるから。 gi
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary
はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Visual Studio Code完全入門』重版出来記念、全文無料公開キャンペーン - インプレスブックス
Gitハンズオン研修 / Git Hands-on
GitExplorer
