.gitignore を設置 GitHub に .gitignore のテンプレートがあるのでそれを使うとらくです。 github/gitignore .gitignore をコミット チームで開発していたり、複数のマシンで編集する可能性がある場合は、他の環境でも同様にこれらのファイルを無視してくれるように、.gitignore 自体をコミットしてしまいましょう。
![あとからまとめて.gitignoreする方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b8349d862eac380fbc6bbcd712283f6f609a8b8a/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUUzJTgxJTgyJUUzJTgxJUE4JUUzJTgxJThCJUUzJTgyJTg5JUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJUUzJTgxJUE2LmdpdGlnbm9yZSVFMyU4MSU5OSVFMyU4MiU4QiVFNiU5NiVCOSVFNiVCMyU5NSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9ZDMxM2JjYjk1YjZiYzc0YWY5ODA1ZWZiYWIyM2Q0M2Q%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5dXVBbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NTNiNjg3MmQyNzQwNWRiYmVlOTViNmMzOWE5OTcxYWM%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D9d6949b4c148f9afb1a42480460fb58e)
昨日Macで使えるGitフロントエンドの紹介を書いたところ、友人のPishenさんからForkというツールもあることを教えていただきました。 How about https://t.co/fDZq7jzQoo ?— Pishen Tsai (@pishen) 2017年8月30日 Webサイトはこちら。現時点ではMac版(動作にはMacOS X 10.11以降が必要)のみですが、Windows版も提供予定のようです。 git-fork.com リリースノートを見ると昨年から開発されていたようですが、完全にノーマークだったので早速試してみました。 1ウィンドウで複数リポジトリをタブ切り替えで操作できる ブランチの状況も把握しやすい履歴ビュー(見た目的にはSourceTreeに近い) コミット時点のファイルツリーを確認できる 動作は軽快(ただし安定度についてはまだ不明) ターミナルから起動する
$ homebrew updateがうまく実行されなかったので、メモします。 homebrewをアップデートしようとすると、 /usr/local/Library/brew.rbのpermissionが原因で、実行できない。 $ brew update /usr/local/bin/brew: line 28: /usr/local/Library/brew.rb: Permission denied /usr/local/bin/brew: line 28: exec: /usr/local/Library/brew.rb: cannot execute: Undefined error: 0
GitHub や BitBucket などの Git ホスティングサービスの Hook や Webhook サービスを使って、Git に Push した時、自動的にサーバー側でに最新版の master ブランチを pull するための PHP を拾ってきて、ちょっと改造しました。 大きいプロジェクトであれば、きちんとちた CI/CD サービスを使いましょう。 続きはブログ記事で 最初 Qiita を使って書いていたのですが、ちょっと大掛かりになりすぎたので、ブログに移行します。 http://ja.katzueno.com/2019/08/3712/ 豆知識: Hook とは Git には、標準で hook と呼ばれる機能があります。アクションの各段階において、シェルスクリプトを実行できるものです。 UNIX系の OS を使っていて黒い画面に詳しい人は、詳しくは、 「[7.3 Git のカ
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
多分、Gitを使い始めて詰まる(というか悩む)ところの大多数が、「コミットコメント」だと思う。 これについては色々な人が色々なことを書いていて、結構どれも正しいので、それらを参考にしてもらうのが良いと思う。 じゃあ俺はこれから何を書くのか、というと、 こういう風にコメントするとチーム開発が捗るよ というのを書こうと思う。 俺自身も出来てないことが多いので、自戒を込めて書くことにした。 ※注意! この記事は「ウチのチームで俺はこういうのを意識してコミットコメントを書いている」というものであって、 万人にドンピシャリと来るものではないというのを予めお伝えしておく。 コミットが何を変えるのかを明確にする たとえばこんなコミットコメントがあったとする。 アウト。ダンゴで試合終了。 "Fix some bugs"、直訳すると「いくつかバグ直したぜ!」である。どこの、どんなバグを、何個直したのかが全く
この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの? と思ったことはありませんか? 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う? git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
最近、以降に紹介する書籍を購入して、Gitを通じて分散バージョン管理に入門、バージョン管理に再入門しています。 ローカルでのバージョン管理の仕組みはとても軽快で、さくさく動くのがとても気持ちいい感じです。バージョン管理システムとしてもSubversionとは少し違った考え方もあり、理解できればより良い考え方といえると思います。今回は、その中で私がとても気に入ったgit rebaseの考え方を紹介したいと思います。 参考にした書籍 この書籍は、一人で管理する場合から始まり、チームでの開発の例、また自分がコミット権を持っていないオープンソースプロジェクトの参加の仕方など、かなり実践に近いかたちで書かれていて、とてもためになりました。 今回は上記の書籍によく使われている図の形を真似しています。書籍の上ではこのような図で上記に紹介したようなケースを表現してくれています。rebaseを仕様する上で想
VM で開発用のサーバを構築するにあたって、開発用PCではなく他の高スペックPCを母艦にしたいよねーという話。*1 で、とりあえず「vagrant リモート」でググってみれば、やはり同じことを考える人がいたようだ。 VagrantでリモートのVirtualboxを実行するvagrant-remoteを作ってみました - @masuidrive blog vagrant-remote 公開されているスクリプトを拝見すると、アイディアとしては ssh でつないで vagrant コマンドを叩いているようだ。 なるほどと思いつつも、母艦にしたい PC に vagrant をインストールしたくない、コマンド実行のたびに ssh 接続しているので時間かかりそう、ということで残念ながらこのスクリプトは見送ることにした。 さてどうしたものかと考えてみたところ、自分の要件としては 母艦に ssh 接続は可
Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の3つのコマンドだ。 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
2012年07月11日01:20 カテゴリその他 gitでの操作ミスへの対処 スライドを作成したので公開します。初歩的な内容です。 gitで過去に戻りたい View more presentations from tattyamm #この文章の目的 * gitでできることを知っておく * 特に操作ミス、やり直しのできる範囲を知りたい #コミット漏れ、ちょっとした編集ミス 例 hoge.txtとfuga.txtを編集した 正解 $ git add hoge.txt fuga.txt $ git commit -m "大事な変更をしました" ミス $ git add hoge.txt $ git commit -m “大事な変更をしました” //ここで足りない事に気がついた $ git add fuga.txt $ git commit -m “大事な変更をしました(その2)" やりたいこ
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く