【Git】Windows環境でGitHubにSSH接続してコミットするまでの手順 - Qiita
前提条件 WindowsにGitがインストール済みである GitHubのアカウントが作成済みである GitHubでリポジトリを作成する GitHubにログインし、RepositoriesのNewボタンから新規リポジトリを作成できます。 本記事では具体的な作業は省略します。 コミット履歴が空の新規リポジトリが作成できてればOKです。 Gitの初期設定をする メールアドレス、ユーザ名を設定する WindowsにGitをインストールしたら最初にメールアドレスやユーザネームの設定をしておくことをおすすめします。 既に設定済みの場合は飛ばしてもらって大丈夫です。 注意：以降の操作はコマンドプロンプトではなくGit Bashです git config --global user.name "ユーザー名" git config --global user.email "メールアドレス" git conf
秘密鍵・公開鍵を作成する（Win） - Qiita
# フォルダ作成 $ mkdir ~/.ssh && cd ~/.ssh # 秘密鍵・公開鍵の作成 $ ssh-keygen -t rsa -b 4096 -C "hoge@example.com" -f ~/.ssh/id_rsa Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): <-- パスフレーズを入力（ Enterキーを押す ） Enter same passphrase again: <-- もう一度、パスフレーズを入力（ Enterキーを押す ） Your identification has been saved in id_rsa. Your public key has been saved in id_rsa.pub. # ファイル確認 $ ls id_
.gitignoreを後から設定し、git管理から除外する方法 - Qiita
git管理したくないファイルをコミットしてしまった時に、後から.gitignoreファイルを作成し、リポジトリから削除する方法を説明します。 1..gitignoreファイルを作成する .gitignore を作成したいプロジェクトのディレクトリに移動し、下記コマンドを実行します。 すると、 .gitignore ファイルが作成できます .gitignore が作成できているか確認するために、プロジェクトのディレクトリに行ってみると、.gitignoreファイルは隠しファイルなので、発見することはできません。そこで、「⌘ + shift + .（ドット）」を押すと、こんな感じで隠しファイルを表示することができます。 2. git管理から除外したいフォルダ・ファイルを記入する .gitignoreファイルを開き、git管理から除外したいフォルダやファイルを記入します。 今回はPodsフォルダ
入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita
自分が実際に企業で働くうえでよく使ったコマンドや役に立った設定をまとめてみました。 Git入門系に関しては飽和していると思いますが、ちょっとした応用編としてご覧いただければ幸いです。 自分の環境 ファイルの数や行数が膨大 複数の案件が同時進行することが多く、質問などに答えたりするためにブランチ移動をすることが多い プロジェクト内に複数文字コードが混在している（Shift-JISとUTF-8） コマンド編 基本のコマンド書きなぐり $ git clone <ブランチ名> <ディレクトリ名> # clone先のディレクトリ名まで指定してcloneする $ git pull # pullする。必要に応じて -u や、 remote名、ブランチ名を打ち込む $ git diff # 差分見る $ git diff master HEAD # 現在の状態とmasterを比較する $ git chec
Gitでfatal: invalid upstream ‘HEAD~が出る原因とは？ | IT資格マニアのエンジニア技術ブログ×英語
Gitでリベースを行うときに「fatal: invalid upstream 'HEAD○○’」（○○は数字）と出てしまう場合があります。 今回はGitのリベースでfatal: invalid upstream 'HEAD~が出る原因についてご紹介いたします。 Gitでfatal: invalid upstream 'HEAD~が出る原因とは？ 結論から言うと、「fatal: invalid upstream 'HEAD○○’」と出てしまう原因はリベースを行うときに履歴をさかのぼりすぎているのが原因です。 〇〇には数字が入るかと思いますが、例としてコミットの数が５個しかないのに「git rebase -i HEAD~6」と入力してしまうと「fatal: invalid upstream 'HEAD~6’」というエラーが出てしまいます。 しかし、コミットが５個で「git rebase -i
独立したGitリポジトリのマージをすると発生するfatal: refusing to merge unrelated historiesの解決 - NAKKA-Kの技術ブログ
GitHubでリポジトリを作る。 ローカルでリポジトリを作る。 その後、マージしないとと思い立ちgit pull origin masterをすると、fatal: refusing to merge unrelated historiesが表示されてしまいました。 そんな時はということで、git merge --allow-unrelated-histories origin/masterを走らせると見事にマージしてくれました。 完全に独立した2つのブランチがマージされている様子が見られるGitログ 参考 Gitのマージ概要および、共通の分岐元を持たないブランチ同士のマージ（割としょうもない話） - clock-up-blog
[git] 戻したい時よく使っているコマンドまとめ - Qiita
はじめに コミットのバージョンを戻す、ステージングしたものを編集内容ごと取り消す、ファイルのステージングを取り下げる...と戻すにも色々あります。 整理も兼ねて業務でよく使っているコマンドをまとめます。 目次 編集内容を取り消したい(addする前) ステージングを取り消したい コミットのバージョンを戻したい 特定のファイルのみ、コミットのバージョンを戻したい リモートリポジトリのコミットのバージョンを戻したい 編集内容を取り消したい(addする前) git checkout [ファイル名] ファイル名のところを.にすると、ステージング前の全ての変更内容がなくなる。 ステージングを取り消したい git reset [ファイル名] ステージングを取り下げる。編集内容は残る ファイル名を指定しないと全てのステージングが取り下げられる。 git checkout HEAD -- [ファイル名] ス
![[git] 戻したい時よく使っているコマンドまとめ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/32feede1acaffeac41a2df80e23a5d287ad304d2/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCZ2l0JTVEJTIwJUU2JTg4JUJCJUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJTg0JUU2JTk5JTgyJUUzJTgyJTg4JUUzJTgxJThGJUU0JUJEJUJGJUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgxJTg0JUUzJTgyJThCJUUzJTgyJUIzJUUzJTgzJTlFJUUzJTgzJUIzJUUzJTgzJTg5JUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1jMjY0ZGY2MjVhYjc2ZmZmMzZlMWZiZTIzYTJhNzQ0Nw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDByY2gxMjIzJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0zNzUzYjdlZGFkYzBkYmNjYmExNTBiNTYwZTRlNjQ5MA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gaVJpZGdlLCBJbmMu%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3De5d10c2063fb5819c190e2cc393c5a8a)
GitUML
Understanding source code is every programmer's biggest challenge GitUML helps programmers understand new code more quickly. Understand code quickly Rapidly generate diagrams from programming source code. Diagrams from git repositories - automatic diagram updates when you push! Upload source code files Live UML Fiddle converts source code into UML as you type UML Fiddle (Python) UML Fiddle (Javasc
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Git フックの基本的な使い方 - Qiita
# テンプレートディレクトリを作成 $ mkdir -p ~/.git_template/hooks # テンプレートを読み込む $ git config --global init.templatedir '~/.git_template' # pre-commit スクリプトを作成 (中身は下に記載) $ touch ~/.git_template/hooks/pre-commit # commit-msg スクリプトを作成 (中身は下に記載) $ touch ~/.git_template/hooks/commit-msg # 実行権限を付与 $ chmod a+x ~/.git_template/hooks/pre-commit $ chmod a+x ~/.git_template/hooks/commit-msg # 適当なディレクトリを作成 $ mkdir git-hooks
【セキュリティ ニュース】Gitに深刻な脆弱性、認証情報など取得されるおそれ（1ページ目 / 全1ページ）：Security NEXT
分散型バージョン管理システム「Git」に深刻な脆弱性が含まれていることがわかった。アップデートがリリースされている。 同システムの「credential helper」において改行を含む細工したURLを用いることで、Gitクライアントより認証情報を任意のホストに送信させることが可能となる脆弱性「CVE-2020-5260」が明らかとなったもの。 米国立標準技術研究所（NIST）の脆弱性データベース「NVD」による共通脆弱性評価システム「CVSSv3.1」のベーススコアは「9.3」で「クリティカル（Critical）」とレーティングされている。 脆弱性の判明を受けて、開発チームでは脆弱性へ対処した「同2.26.1」「同2.25.3」「同2.24.2」「同2.23.2」「同2.22.3」「同2.21.2」「同2.20.3」「同2.19.4」「同2.18.3」「同2.17.4」をリリース。また脆
Gitリポジトリの内容を別のマシンに送る時にgit bundleを使う - Qiita
手元のマシンでgitで管理しているファイルを別のマシンに送りたいと思ったときに、以下の3つが自分の中にはあった。 一旦リモートリポジトリにpushして別マシンからcloneする git reset --hardした後、zip圧縮して送る git clone project-name copy-of-project-nameした後、copy-of-project-nameを圧縮して送る ただ、どれも微妙な気がしていた。 そこでgit bundleというものを知ったので試した。 ざっくりいえば、gitリポジトリのある範囲の内容を1ファイルにまとめる的な事をやってくれるらしい。 手順 今回はmasterブランチの内容をまとめて持っていく感じで使う。 まず、masterブランチを対象に project-name.bundle というバンドルファイルを作る。
macOS CatalinaにしたらGitコマンドが動かなくなった - Qiita
さっそくCatalinaにアップデートしてみましたが、恒例のやつです。 Gitコマンドが動かなくなったのでまたメモです。内容は全く同じ。 macOS MojaveにしたらGitコマンドが動かなくなった macOS SierraにしたらGitコマンドが動かなくなった 毎年やってる（笑）けど、ハマったときの検索ワードがOSアップデートによっても変わってくるのでまた残しておきます。 $ git xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
Git超絶まとめ - Qiita
ファイル保存領域 ワーク（ワーキング）ツリー インデックス（ステージング） リポジトリ ワーク（ワーキング）ツリー ユーザーが作業しているディレクトリ領域 インデックス（ステージング） ワークツリーとリポジトリの中間領域（一時領域） コミット対象のファイルを登録する領域 リポジトリ ファイルやディレクトリの状態を管理する領域 ブランチ 履歴の流れを分岐して保存していくための機能 masterブランチ 追跡ブランチ HEAD masterブランチ gitリポジトリに最初にコミットすると作成されるブランチ 追跡ブランチ リモートブランチの状態を監視するためのブランチでローカルブランチの一種 git branch -aで表示されるブランチは作業ブランチと追跡ブランチ（remotes/<remote>/<branch>）で、共にローカルに存在する。（"作業ブランチ"という名前は仮。追跡ブランチと区
git rm したファイルを元に戻す方法 - Qiita
% git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: 削除したファイルパス git reset --hard HEAD 削除したファイルパス で元に戻せると思ったが、2ステップ必要だった。 方法 以下のステップで解消する。 ステップ1：削除したファイルのステージングを取消し ステップ2：削除したファイルをチェックアウトにより復元 ステップ1：削除したファイルのステージングを取消し
git rebaseを初めて使った際のまとめ - Qiita
環境 とくになし はじめに 今までrebaseを使ったことが無かったのですが、コードレビューを依頼した際に「マージコミットが邪魔で見づらい…」と言われてしましました。「ログを綺麗にするため」にrebaseについて学んだことのまとめです。 まず、ログがどのように綺麗になるのかを以下に説明します。 mergeを使った場合のログ（あまり綺麗ではないログ） 例えば下図のようなブランチが存在し、自分が今featureにいるとします。この状況でbugfixが入った最新のdevelopを取り込みたいと考えているとします。 マージを使って取り込みます。 無事取り込むことができました。しかし「git log」をしてみると時系列順に並ぶためfeatureのコミットが飛び飛びになってしまい、すごく見づらくなっています。 rebaseを使った場合のログ 最初の状況は先程と同じです。 rebaseを使って取り込んで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あとからまとめて.gitignoreする方法 - Qiita
git logのオプションと綺麗にツリー表示するためのエイリアス - Qiita
リモートリポジトリの登録とデフォルトリモートブランチの設定 - Qiita
gitのフックを使って，コミット時にコードチェックを自動実行するようにした - Aqutras Members' Blog