Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...
Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...
エンジニアHub > 記事一覧 > Visual Studio Codeのうれしい機能を使いこなして、初心者を最速で脱出する!《VSCode実践入門》 Visual Studio Codeのうれしい機能を使いこなして、初心者を最速で脱出する!《VSCode実践入門》 VSCodeは初版が2015年リリースの新しいエディタですが、インテリセンス、ユーザースニペット、Emmet、マルチカーソル、拡張機能というコーディングにうれしい機能が充実しています。VSCodeを検討中あるいは使いはじめたばかりの若手エンジニアが、いち早く初心者を脱出するための使いこなし方を解説します。 はじめまして、KC(けーしぃ、@kcpoipoi)と申します。技術書典6にサークル参加してたら「キミ、Web執筆に興味ない??」とお声がけいただきました。Web執筆は初めてなので至らない点があるかもしれませんが、何卒よろしく
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
おことわり この記事はプログラミング&業務未経験の新入社員に、Gitについて1時間くらいでバババッと説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達するのは無理ですが、今後Gitを使う必要がある人にとって学習の足がかりになればいいな、という内容です。 それと、新入社員に教えるという都合上、表現がやや正確でなくざっくりしたところがあるかもしれませんが、質の悪い誤解を招くようなものでなければご容赦下さい。 全体像 まずはGitとは何かをざっくり分かって貰った後で、VSCode上での操作を行って貰います。 Windowsでの説明を行いますが、
はじめに 一年前に新人研修でGitを担当してTigの記事を書いたのですが,今年も同じくGitの研修を担当することになりました.新人さんたちにとってはターミナル環境はとっつきにくい人も多いようで,短い研修期間では操作自体に苦戦してしまい,Gitそのものを理解するというところに力を割けない人も少なくありませんでした. それを踏まえて今回はGUIで操作しやすい環境を検討したのですが,以下のポイントを踏まえてVSCodeを使うことに決めました. マルチプラットフォームで使える.(研修はWindows環境で行いますが,業務ではLinuxデスクトップ環境も使うので) Gitの基本的な内容はVSCode上でGUI操作が可能. Gitの内容とあわせて,プログラミング用のテキストエディタの一例として,導入しやすそうなVSCodeを紹介. VSCodeを使ったGitの基本的な操作を一通りまとめていきます. イ
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだGitGitHub小説 タイトルは釣りではありません。 最近、小説の執筆にあたって Git を導入して原稿の進捗履歴を管理しました。めちゃくちゃ便利でした。 GitHub を使って友人と一緒に校正校閲の作業をしました。めちゃくちゃ捗りました。 短編 SF 小説が短期間で完成しました。でも広告が目的ではないのでリンクは貼りません。 Git のことを何も知らない奴が Git と GitHub の使い方を覚えたら便利だったし捗ったので、記事にしてしまおうぜという試みです。 2019年1月4日 追記 本記事は「執筆」および「校正・校閲」の段階における Git と GitHub の有用性を主張する記事です。 「組版」や「デザイン」の段階における Git の有用性について
いかがでしょう! この通り、デザイナーからモテモテです! ■真面目な話… タイトルはふざけていますが、真面目な話をすると4年前の私がこんな教え方をしてもらえていたら、本当にGitに怯えることもなかったと思います。 なぜ、あのころ理解ができなかったのか。 あの時どうしてもらえていたら、エンジニアもデザイナーもお互い幸せになれたのか。 Gitを使い始める時にデザイナーとして知りたかったことや知らなくても困らなかったことを一生懸命まとめました。 情熱を込めすぎたせいで、1万字を超えるエントリーになってしまっています。 順番も意識したので、上から順に読み進めていただけると、うれしいです。 ■あらすじ 【その1】「図解」を活用し、「簡単」って嘘をつかないエンジニアはモテる 【その2】Gitで幸せになる世界を共有してくれるエンジニアは素敵だ 【その3】環境構築をサポートしてくれたエンジニアはものすごく
わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉posted with カエレバ湊川 あい シーアンドアール研究所 2017-04-21 Amazonで探す楽天市場で探すYahooショッピングで探す 目次 目次 はじめに コミットメッセージにdiffを表示する 前回コミットした時の状態に戻す 直前のコミットをなかったコトにする 直前のpushをなかったことにしたい。 履歴を残さない 履歴を残す(より安全) 無理やりリモートリポジトリにローカルを合わせる 間違えたgitのaddを取り消す 一つ前のコミットを修正 git pullした時にコンフリクトしたファイルを調べる 更新されたファイルの一覧を表示する ブランチのグラフを見たい gitで管理していないファイルやディレクトリをすべて削除する。(gitinore対象のファイルも含めて) 過去のコミッ
SlideShare上の本資料は現在メンテされていません。 ↓↓↓SpeakerDeck版をご覧ください!(時々アプデしてます)↓↓↓ https://speakerdeck.com/ihcomega56/githazimefalse-bu
Git(GitHub)おじさん 何かを布教することをネットの一部では「**おじさん」というみたいです。最近、あまり得意ではないのですが、色々な事情で仕事でソフトをつくることが多くなり、その関係で何周か遅れでGitとGitHubを使うようになりました。そして、今頃その素晴らしさに感動して打ち震えている(大げさ)ので、私もGit(GitHub)おじさんになってみようかと思います。 といっても、私が今更Git(GitHub)の何が素晴しいかを語ったところで…というのもあるのと、何よりうまく伝えられる気がしないです。何故ならそもそも自分がまだそんなにわかってないし使いこなせてない。なので、今回はGit(GitHub)を少し使ってどのようなことが変わった(良いことがあった)のかという具体例をGit使用前(Before Git)、Git使用後(After Git)として列挙した後、オススメのサイトをま
先日、『アーマードール・アライブ』2巻の発売日を正式に発表させていただきました。 【お知らせ】『アーマードール・アライブ』2巻についてのお知らせ - Funny-Creative 記事内でも記載したとおり、まだ校閲や改稿など、編集作業が山積みを粛々と進めている最中です。 知人に下読みしてもらって矛盾点や改良点を洗い出したり、誤字脱字の山をひたすら切り崩したりと一人では大変な作業続いています。 下読みについては直接epubやテキストを送っても手伝ってもらえるんですが、細かい誤脱の修正やマークアップについては、どうしても口頭でフィードバックして解決しなければいけない状態です。 特に誤脱の指摘については、「○○ページ目の○行目に誤字があったよ」と教えてもらっても、リフローなEPUB形式のため追跡作業に難航してしまいます。 できれば直接原稿ファイルに手を入れて手伝ってもらいたいけど、複数人で1つの
2014初頭に書いた「WindowsにおけるGit利用環境は整った: Git for Windows と SourceTree for Windows」の最後の文: ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示(樹形図)の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
いろいろあって職務経歴書を作成してみることにしました。お便りお待ちしています! 要約すると 理工系出版社の開発部という部署で約13年間半、主にコンピュータネットワークとプログラミングの本を企画し、制作してきました(「企画制作に携わった主なコンテンツ」および「企画者として公式に社内に名前が出ている、かつ、制作でも中心だった書籍の一覧」を参照)。 特にTCP/IP関連書籍と、翻訳技術書は、たくさんの技術者の方に手に取ってもらえた(願わくば役に立てた)と思います。 読者が読んだことを後悔しない本を作るのは当然として、著者や訳者が出版したことを後悔することがないように、編集制作プロセスの透明化にも努めました。 通常、著者や訳者は、出版物に対する責任があるにもかかわらず、その最終的なデータを手にすることがありません。 著者による校正の終了後に編集者が内容のデグレにつながるような修正を勝手に加えてしま
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
MS Wordで書かれた原稿を電子書籍化する作業を行ったのですが、個人的には使い慣れたRe:VIEWで管理したいものです。 そこで、MS Wordをテキストファイル化してRe:VIEWファイルに書き換えることにしました。 docx2txtを使ってMS Wordをプレーンテキストに変換する ワードファイルのテキストをコピペしてテキストファイルに置き換えるのは流石に面倒ですし、ヒューマンエラーも発生しそうです。 そこで、何か良い方法はないかと思って、おもむろにGoogleで『docx2txt』と検索してみると、まったく同じ名前のソフトウェアを発見することができました。 Docx to Text convertor ページはややレトロですが、ツール自体はメンテナンスもされているようで、これを導入することにしました。 リポジトリ作成 まずはリポジトリの作成です。とりあえず、次のようなファイル配置を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く