現在業務で女性向けの情報サイトのような物を作ってるのですが、デザインで少々詰まってましまいました。情報サイトとなると自然と文字数も多くなってゴチャゴチャしがちなうえに、元々女性的なデザインを意識して行った事があまりないので中々アイデアが出てこなくて困っていました。 いつも通りGoogle先生に訪ねてみたものの、案外見つからないんですよね。どうしようかなと悶々と悩んだ末に、ググれカスと言われるのを覚悟してwdscratchのフォロワーさん達に参考になりそうなサイトを教えて頂きました。 という事で今日はGoogle先生とwdscratchのフォロワーさん達が教えてくれた女子向け情報サイトをご紹介したいと思います。 今回協力して頂いた皆さん、本当にありがとうございました。助かりました。 追記1：ひとつ掲載漏れがありましたので修正しました。 追記2：コメント欄でご紹介いただいたサイトを追加いたしま
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
マストドンと改正プロバイダ責任制限法 鯖管が知っておくべき義務と権利 - ashphy's commit logs
概要 Twitterをイーロン・マスク氏が買収したこと*1により、マストドンをはじめとする分散SNSへアカウントを作る動きが加速*2しています。現在はサーバの処理能力についての話題が多いですが、人が増えればTwitterで起きていたトラブルが分散SNSでも起きるようになると思われます。 そこでこの記事では、分散SNS上でなにかしらの権利侵害が起きた場合に、安心して問題に対処できるようになることを目的として、プロバイダ責任制限法のもとでサーバ管理者の義務と権利、取るべき対応を解説します。 対象の読者 個人でマストドン/Misskeyのサーバを運用しているサーバ管理者 この記事での前提 この記事では読みやすくなるように以下の前提を置いています。 分散SNSはマストドン マストドンの用語を使うだけでMisskeyやPleromaでも一緒です。 マストドンのサーバは日本国内に設置されている サーバ
作りました！ pixe.la これはなに？ お好きな数値を登録、その登録された数値情報に基づいて、アレのあれっぽくグラフを作れるサービスです！ アレのあれってのは、これのコレ↓っぽいやつです！ ↑commit回数をグラフにした場合のイメージ。 ↑プロダクトのデプロイ回数をグラフにした場合のイメージ。 ↑体重の変動（前日比）をグラフにした場合のイメージ。 どうやって使うの？ Pixela は、サービスのトップページ以外は全部 Web API のみで構成されるサービスです！なので、ユーザー登録からなにから、全部 API でおこないます！ $ curl -X POST https://pixe.la/v1/users -d '{"token":"thisissecret", "username":"a-know", "agreeTermsOfService":"no", "notMinor":"
以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。 さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。 しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDF
git commitをやり直しする＆取り消しする(「get commit --amend」と「git reset」) - hogehoge foobar Blog Style Beta
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す（git commit --amend） 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page
[この発想はなかった] 専任のSubversionオペレータなる人がいるらしく、受理された申請書と変更ファイル(を入れたUSBメモリ)をSubversionオペレータさんに手渡すと、あとはオペレータの人が代わりにコミットしてくれるみたいですよ。
「commit-m: GitHubコミットメッセージの文例が検索できるサービス」がとても便利だったのでcliから使えるコマンド書いた - ( ꒪⌓꒪) ゆるよろ日記
http://commit-m.minamijoyo.com/:titele という有名OSSのコミットメッセージを検索できるサービスがあって、英語のコミットメッセージを書くときに「あれ? これどういう風に書けばいいんﾀﾞｰ」ってときに例文を検索できて捗る。 commit-m.minamijoyo.com が、自分の場合はコミットメッセージ書くときはvim とか git commit -m とかからなのでCLIで検索できたらより捗るかと思ってGolangで書いた。 APIとかは無いようなのでクロールしてる。 GoQuery 使えばこの手のクローラーが一瞬でかけるのでよさがある。 github.com go get github.com/yuroyoro/gommit-m で入れた後に gommit-m keyword [page] で検索できる。
[レポート] 『きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会』に参加してきました | DevelopersIO
はじめに こんにちは、クラスメソッド最年少らしい黒澤です。 先日、『きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会』 というものに参加してきましたので情報を共有します。 情報 日時 : 3月27日（火）20:00-21:30 場所 : 東京都渋谷区道玄坂1-9-5 渋谷スクエアA 11F 【勉強会】きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会 スライド @imaizume さんに講師をしていただきました。 この勉強会ではタイトル通り、きれいな commit, pull request というテーマについてお話をいただき、 そのためのテクニックなどもご紹介いただきました。 きれいな commit を積む目的 commit : 変更の塊 変更には必ず意図がある。commit に含まれる変更の意図は見えるべ
![[レポート] 『きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会』に参加してきました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/449a6ff1c4f7545a1c9c8678f784a4711116a965/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F01%2Fgit.png)
git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したい #git - Qiita [キータ]
git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したいGit やっちまった〜 commit してたら最強の味方 reflog 使えるけど add しかしてないしなぁ…… でも、git は objectdb だし、add している時点で 何処かに保存されているはず！！ と思って調べたら git fsck を発見！！ どこにも属してないものが見れる！！ やった！！ これで hash とれるので git unpack-file で内容だけは復元できる！！ つまり
![git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したい #git - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/adbaf09775fe6b713d0b3670963d78f7f02a1ad1/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-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9Z2l0JTIwYWRkJTIwJUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJTgyJUUzJTgxJUE4JUUzJTgwJTgxY29tbWl0JTIwJUUzJTgxJTk5JUUzJTgyJThCJUUzJTgxJUFFJUU1JUJGJTk4JUUzJTgyJThDJUUzJTgxJUE2JUUzJTgxJUE2JTIwcmVzZXQlMjAtLWhhcmQlMjAlRTMlODElOTclRTMlODElQTElRTMlODIlODMlRTMlODElQTMlRTMlODElOUYlRTMlODElOTElRTMlODElQTklRTMlODAlODElRTUlOEYlOTYlRTMlODIlOEElRTYlODglQkIlRTMlODElOTclRTMlODElOUYlRTMlODElODQmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTAwZTBjM2RkODk4YWUxMTE2MTM3Mzk0NzJkYTA3ZDI0%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQweW9zaGlvcmkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTA4YTg5ZDczZTQ1NjEwNjI3MGY3ZmMwMjU0MDdiYmVi%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Db5f931c45f0432b71eed2ceb96d948bf)
Fusion-io、10億IOPSの新技術「Auto Commit Memory」発表。ストレージなんてレベルじゃない、パーシステントなメモリだ
現代のコンピュータにおいて、メモリとストレージはプロセッサと並ぶもっとも基本的な構成要素です。高速なアクセスを担当するのがメモリ、データの永続性を保証するのがストレージです。 Fusion-ioは、ストレージ性能に換算すると10億IOPSという超高性能を実現するAuto Commit Memory（ACM）を発表。ACMとは、永続性を備えた新しいタイプのメモリだと説明しています。 ACM is a new memory type that uses the underlying flash to present a persistent memory directly to applications. ACMはフラッシュを基盤に用いた新しいタイプのメモリであり、アプリケーションに対して永続性を備えたメモリを直接提供する。 Fusion-ioは、PCIeスロットに接続する高速なサーバ内蔵型フ
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
始めに 私は最近エンジニアに復帰し、現場で便利に思ったことを今後記事にできたらと思っています。 そして1発目は、gitのオプションについて記事を書いてみようと思います。 --fixup はどんな時に使えるの？ Pull Requestなどで、軽微な指摘や後から気付いた修正など、本来の機能のコミットとは別に修正コミットを残すのは少し嫌な時がありますよね。 コミットが一つ手前であれば、直前のコミットを修正してくれる git commit --amendなどで対応できますが、3つ前のコミットに修正を混ぜ込みたい時などは、少し大変。 そんな時に便利なのが、この git commit --fixupです。 使い方 例えば、下記のコミットの状況で、Fix article pageのコミットに対して、追加の修正をしたいとする。 ❯ git log --oneline 1131338365 (HEAD -
Commit a047be85247755cdbe0acce6f1dafc8beb84f2ac to MrMEEE/bumblebee - GitHub
m README m install.sh GIANT BUG... causing /usr to be deleted... so sorry.... issue #123, issue #122, issue #121
空コミット便利！git commit --allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -
何か？ git commitのオプション--allow-emptyご存知でしょうか？ これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
GitHubのcommitのURLの末尾に ?w=1 とつけると差分がわかりやすい（時がある） - 納豆には卵を入れる派です。
各commitのURL https://github.com/hoge/fuga/commit/xxxxxxxxxxxxxxxxxxxの末尾に "?w=1" をつけてhttps://github.com/hoge/fuga/commit/xxxxxxxxxxxxxxxxxxx?w=1とすると、差分がホワイトスペースのみの行を省いて、文字の変更があった行だけを差分表示してくれるので、何を変更したかがピンポイントですごくわかりやすくなる場合があります。 例えば下記の例。CoffeeScript内である部分をコールバックにして、コールバックした部分のインデントをごっそり下げてるのですが、インデントを変えただけの行も全部差分に表示されてて、何を変えたのかひと目でわかりづらい。 普通のcommit表示 ↓ これがURLに"?w=1"をつけるとこうなる！！！ ↓ 単にインデントを変えただけの行が省かれ
先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の（親コミットと差分がない）コミットを作成できるらしいですね。 僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。 WIP PR って何？ Work In Progress Pull Request の略です。 Github に Pull Request （以下、PR と表記）という機能があるのは皆さんご存知だと思います（知らない方はググってください）し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。 作業途中のトピックブラン
発端 Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？— codehex.bsky（へっくす） (@codehex) 2024年2月25日 ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。 git commit --fixup このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コ
はじめに 英語力をあげるために、コミットメッセージを英語で書こうとしても実践するのはなかなか難しいものです。 GitHubで使われている実用英語コメント集 - Qiita のような記事を読んでもコミットするときには忘れています。 そこで、git commit時に表示されるコメントに、英語でメッセージを書くためのヒントを表示してみました。 完成イメージ やり方 ~/.gitmessage.txt を作成 # fix, add, changeといった事実ではなく、このcommitで実現する要件や仕様を書きましょう。（リファクタなどは除く） # # 例文） # - Fix typo in docs # - Remove unused code # - Remove use of deprecated method # - Update Modernizr to v1.6 # - Make it
Writer and NHK board member Naoki Hyakuta, seen here last year at the launch of one of his books, believes the Japanese did not commit war crimes in World War II and that the U.S. fabricated themThe Asahi Shimbun In the clearest signal yet of U.S. unhappiness with the rightward tilt of Japan’s political leadership — and by extension, Prime Minister Shinzo Abe — the U.S. embassy in Tokyo has strong
:chart_with_upwards_trend:Add or update analytics or track code.
Rails Developers Meetup 2018: day 1 (https://techplay.jp/event/639872)
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
Git のコミットには、Author と Commiter の2つが存在します。 例えば、いつもと違う PC を使ったときに、.gitconfig の設定が違うと、コミットに意図しないメールアドレス・ユーザー名が入ったりします。 Git で見るとこんな感じ $ git log -1 --pretty=full commit befdbcd2389373088fe3e83d9c0d401a9de7717d Author: hogehoge <dummy@example.com> Commit: fugafuga <test@example.com> add test.txt GitHub 上では、コミットに表示される、いつもの自分のアイコンが表示されなくなるので、ちょっと気になります。 そこですでにコミットしてしまった、コミットの Author と Commiter を変更する方法についてま
ローカルで持っているGitリポジトリをGitHubにpushしてしまいたいなぁ、と思ったのだが、pushする直前にAuthorおよびCommitterとして自分の本名を使っていることに気づいた。そういえば、Gitを使い始めたころはuser.nameに正直に本名を入れていたなぁ…。 そのままでも大した問題はないのだが、ネット上ではidesakuで通すことにしているので、こいつらを修正した。その際、あまり使わないコマンドを使ったので、作業ログなど残してみる。 さて、どうすればよいか。すぐに思いついたのは、git-rebaseを使うことである。 ところで、Gitは全てのコミットにAuthorとCommitterの二つの名前を記録している。これは、オープンソース分野でよくある「パッチを書いた人(Author)と、それをリポジトリにコミットした人(Committer)が違う」ケースに対応するための措
はじめに git commit するまえに考えるべき10のこと | Act as Professionalを読んでいろいろと思うことがあったので書きました。 これはSCMBootCamp主催者としてとか、Mercurialユーザーを代表してとかではありません。 僕はこう思う。ということです。 読むの面倒な人は最下部のまとめだけ読めばok。 commit != push DVCSの利点はローカルコミットという概念を持ち込んだことです。これにより、高速な履歴追加、安全なマージを手に入れることができました。 件の記事を読んでいて気になったのは、commitという単語です。 特に、 1コミットに1つの対応 コメントアウトしたコードをコミットしない テストが正常に通過したものにしてください コミットメッセージの1行目は”短い説明” コミットメッセージのスタイル コミットメッセージのボディは有意義な内
コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記
Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu
何個もCommitがあるような一つのPull Requestを全てRevertしたいようなときに使えます。 そもそもRevertとは あるコミットを打ち消すような、全く逆のコミットを作ることです。 追加した部分を削除して、削除した部分を追加して、変更した部分を変更前の状態にするコミットを作成します。 取り消したいコミットがあるのだけれど、既にリモートにコミットしてしまって、git reset, git rebase -i, git reflogなどを使っての取り消しが不可能なときに使います。 通常のRevert 普通のcommitなら、revertは
continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました - tomykaira makes love with codes
2013-07-13 continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました Scala Git いままで git rebase -i に何度泣かされたことでしょう。 git は最高のツールですが(他の SCM に勝るという意味ではありません)、あれは非常に出来がわるい。 テストを回すたびに自動コミットする continuous commit のプラクティスを採用している私達にとって、 interactive rebase は頭痛の種でした。 (continuous commit については Continuous Commit (kyon_mm さんの発表資料)、最近の git の使い方について - tomykaira makes love with codes など)。 git-rebase--interact
VS Code でコミットするときに GitHub Copilot を使っていると コミットメッセージを生成してくれたりします。 図 1 コミットメッセージを Copilot で生成 英語苦手な自分からすると「マジうれしいんですけど」という感じなのですが、コミットメッセージはできればエディターで記述したいと考えてしまいます。 そこで今回は「コミットメッセージをエディターで編集する利便性」を維持しつつ、「GitHub Copilot による生成機能もできるだけ利用しよう」という内容のメモになります。 VS Code のエディターでコミットメッセージを記述するとは VS Code でコミットメッセージを記述する方法としてはソース管理タブの利用が一般的かと思われます。 図 1-1 ソース管理タブのフィールドから普通に入力 一方で上記とは別に、コミット用のコマンドを実行しエディターの中で記述する方
VS Codeにお勧めのフォント！ 似た字形をはっきり区別でき、プログラミング向けに読みやすさを追求 -Commit Mono
コードがはっきりときれいに見えるように、プログラミング向けに読みやすさを追求したフォント「Commit Mono」を紹介します。 似た字形（「tl1I|!ij」「O0QDØ38B」「:;.,''''"」「2Z5S7T6b」）ははっきりと区別できるようにデザインされており、また等幅フォントでよくある特定の文字間で幅が等しく見えない問題（「mm」「oの左右」など）も改善されています。 Commit Mono. Neutral programing typeface Commit Monoは、デンマーク出身のクリエイティブデベロッパー兼デザイナーであるEigil Nikolajsen氏によるプロジェクトで、プログラミング向けに読みやすさを追求して作成されたフォントです。 ライセンスはSIL OPEN FONT LICENSE Version 1.1で、商用利用は無料、Webフォントに変換したり改
commitとpushしかできない人のためのgithubの使い方まとめ - Just $ A sandbox
github(というよりgit)使っている方は結構な数いらっしゃると思います。 私もそのうちの一人ですが、正直「addしてcommitしてpushするだけ」です、はい。 branchとかmergeとかfetchとかあの辺がいまいちわからない情弱です。 あんまりこの辺をまとめて書いた記事が見当たらなかったのでまとめることにしました。 基本的にはgithub:helpの要約だと思ってくださればよいかと思います。 レポジトリを作る レポジトリ gitで作ったレポジトリは./.git以下に全てのcommitなどが保存されます。gitはさらにリモートでレポジトリを持つことができ、これの一つがgithub repositoryになります。 レポジトリの作り方: $ mkdir ~/Hello-World # "Hello-World"ディレクトリを作ります $ cd ~/Hello-World # 作
First commit が git rebase -i できない問題 → git rebase -i --root でできる - 納豆には卵を入れる派です。
git init してから一番最初のcommit内容を、2番目のcommitと一緒にまとめたい、と後で思った。 よーし、git rebase -i HEAD~~からのfixupで… $ git rebase -i HEAD~~ fatal: Needed a single revision invalid upstream head~~えっ・・・(ΦωΦ) 一番最初のcommitはgit rebase -i HEADほにゃららでは遡れないのか・・・一番最初のcommitはgit rebase -i できないのか・・・？— TAE ✅ (@ken_c_lo) April 21, 2013 @ken_c_lo それ方法あったら知りたいですねー。調べた限りでは無さそうなのもあって、自分でリポジトリ作る時はgit flow initを使って最初に空のInitial commitを作るようにしてます
タイトル写真は商用利用無料の写真サイトソザイングより。 なんとなく雑貨屋さんのサイトを作るときに参考になりそうなサイトを集めてみました。 ヴィレッジヴァンガード通販 みんな大好きヴィレッジヴァンガードのオンラインショップ。 個性の出しにくい雑貨屋さんのwebサイトの中でもさすがの存在感。 [ad#more] Francfranc フランフランのオンラインショップ。 COLOR Searchという色で商品を検索出来るサービスが面白いですね。 そういえば昔フランクフランクって読んで大恥かきました。 印デザイン オンラインストア – In Design onlinestore ヘッダー周りがカラフルで印象に残るサイト。 scope インテリア家具と雑貨を扱ったECサイト。写真のインパクトが大きく印象に残るサイト。 mahna mahna factory 写真がぴょこぴょこ動くFlashサイト。販
git-revertかgit-resetを使う 両者の違いは以下の通り git-revert ある特定リビジョン（過去にcommitしたバージョン）に戻すパッチを自動生成してコミットする git-reset ある特定リビジョン（ryに戻す（戻したリビジョン以降を無かったことにする） もし複数の人共同作業していて共有リポジトリを変更する場合はgit-resetを行うとまれにひどいことになるので極力git-revertを使った方がいいかも 作業の流れ git-logでどこまで戻すか決める（あとSHAをコピーする） % git log commit 46cdec49ae85012327b663531e569d77bf09b1b2 Author: amacou <amacou.abf@gmail.com> Date: Sat Jan 17 22:53:55 2009 +0900 test comm
プログラマーのミスを指摘しバグの発生を未然に防ぐAI「Commit Assistant」をUbisoftが発表。ゲーム開発の効率を高めるねらい - AUTOMATON
ホーム ニュース プログラマーのミスを指摘しバグの発生を未然に防ぐAI「Commit Assistant」をUbisoftが発表。ゲーム開発の効率を高めるねらい 全記事ニュース
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
女子のための情報サイトデザイン21+4 – Commit Lab
tigでgitをもっと便利に！ addやcommitも - Qiita
git commit --fixup とは何か - 詩と創作・思索のひろば
commit以外の数値でも草を生やせる、PixelaというAPIサービスを作った！ - えいのうにっき
svn＋TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆:Geekなぺーじ
GitHub - azu/awesome-commit-english: コミット英語についての記事まとめ
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
git commit --fixup が便利 - Qiita
How to Write a Git Commit Message
git commit --allow-empty を使った WIP PR ワークフロー - Qiita
git commit --fixupを使いましょう - Don't Repeat Yourself
git commit時に英語でメッセージ書くためのヒントを表示する - Qiita
Japanese Broadcast Official: We Didn’t Commit War Crimes, the U.S. Just Made That Up
gitmoji | An emoji guide for your commit messages
Commit message will never die
Subversionで日本語ログ入りのcommitメールを送る
Git の Commit Author と Commiter を変更する - Qiita
GitのCommit中のAuthor名およびCommitter名を変える - idesaku blog
「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組
GitでMerge CommitをRevertする方法 - Qiita
VS Code + GitHub Copilot 環境でも git commit しちゃうんだな、これが
Commit Lab | カワイイ or カッコイイ 雑貨屋さんのWebデザイン:19選
gitリポジトリを特定のcommitバージョンまで戻す方法 - AorBorF
良い Commit Messageを書きましょう(翻訳)