「gitのcheckoutって結局どういうコマンドなんですか?」と聞かれたのですが、うまく答えられなかったので調べてみました。調べてみると、checkoutには3つの使い方があることが分かったので、まとめてみようと思います。 そもそもチェックアウトとはどういう意味か? バージョン管理システムにおいてチェックアウトとは、バージョン管理システムから履歴を取り出すことをいいます。反対に、バージョン管理システムに履歴を登録することをチェックインといいます。 つまり、gitのチェックアウトはリポジトリから履歴を取り出すという意味です。また、gitのチェックインは、ファイルをステージしてからコミットするまでの一連の流れだといえます。 gitに登場する3つのスナップショット checkoutの説明をする前に、gitの基本的な用語を整理してみます。gitには作業ディレクトリ・インデックス・コミットという3
$ git push error: src refspec master does not match any error: failed to push some refs to 'github.com:xxx/xxx.git' 2行目が赤文字になっていたため、2行目を中心に調べていると、 - pullしてからmerge - git pull --rebase という解決策が出てくる。 これはリモートとローカルでコミットが分かれていて、マージできなくてrejectedされている状態の時のエラーの解決法である。 確かにこのエラーでも 「error: failed to push some refs to 'github.com:xxx/xxx.git'」というエラーが出力されるため、2行目のエラー内容で調べると違うエラーの解決策にヒットしてしまう。 解決策 1行目の「error: src
やりたいこと 会社の GitLab に push するユーザーと、GitHub に push するユーザーを分けたい .gitconfig は会社 PC と私物とで同じものを使いたい .gitconfig は github で公開した状態にしたいので、会社情報が含まれないようにしたい 環境 ↑ をやろうと思うとディレクトリをスパッと分けてくれる GHQ が都合良かったので導入。 GHQ のデフォルト設定は、github からクローンしたら ~/ghq/github.com に、会社の GitLab からクローンしたら ~/ghq/{会社の GitLab の URL} に置かれるようになっている。 以下の方法は 会社のリポジトリ群と、個人のリポジトリ群が、それぞれ別ディレクトリにまとまっているいる場合 に適用可能。 やったこと .gitconfig にこういうものを書く。 includeif
gitで手こずった時に色々ググってると、「git fetch」と「git pull」がぐちゃぐちゃになってしまったのでまとめておきます。 結論から言えば、「fetchもpullもリモートリポジトリの最新情報をローカルリポジトリへ持ってくる」という操作になりますが、それまでの流れが違うので説明していきます。 リモートから最新情報をローカルに持ってくるのですが、場所は「master」ブランチではなく、「origin/master」ブランチに取り込まれます。 初めは「何それ知らない」となるのですが、具体的に言うと 「master」ブランチ…ローカルの中心となる統合ブランチで、他のローカルの作業ブランチと繋がったもの。 「origin/master」ブランチ…ローカルにある、リモートのmasterブランチを追跡するリモート追跡ブランチ。 となります。 両方ともローカルにあるブランチで分かりにくいの
発端 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コミットを元コ
こんにちは、エンジニアの松川です。 普段我々エンジニアがコードを書く際に欠かせないのがコードエディタの存在。 そのなかでも Microsoft が提供する VSCode は現在最も人気のあるコードエディタの一つです。 VSCode の強みは何といってもその拡張機能の豊富さです。標準機能では物足りなくなったときも 54000 [1] もの拡張機能が強力にコーディングをサポートしてくれます。 ただそれほど数が多いと最初は何を入れればよくわからないのもまた事実、そこで今回は現役でエンジニアとして活躍するフォルシア社員にオススメの拡張機能を聞いて 10 個に厳選しましたので、紹介いたします。 おすすめ拡張機能 10 選 1. Whitespace+ みなさんが普段コードを書くとき、文末にくるスペースやタブとスペースの違いに悩まされたことはありませんか? スペースやタブなどはエディタ上に何も表示され
Hello! I always wish that command line tools came with data about how popular their various options are, like: “basically nobody uses this one” “80% of people use this, probably take a look” “this one has 6 possible values but people only really use these 2 in practice” So I asked about people’s favourite git config options on Mastodon: what are your favourite git config options to set? Right now
今年も技術研修資料と動画を公開します!MIXIの新卒技術研修の方針や、LayerX様との合同研修についても紹介します! 研修資料・動画一覧Git研修( 動画 / スライド )データベース研修( 動画 / スライド1, 2 / SQL演習環境 )設計・テスト研修( 動画 / スライド )コンテナ研修( 動画 / スライド1, 2 )iOSアプリ開発研修( 動画 / スライド / リポジトリ )Androidアプリ開発研修( 動画 / スライド / リポジトリ )フロントエンド研修( 動画 / スライド / リポジトリ )ゲーム開発(Unity)研修( 動画 / スライド1, 2, 3, 4, 5, 6 / リポジトリ )Flutter研修( 動画 / スライド / リポジトリ )AI研修( スライド1, 2, 3, 4 / リポジトリ )セキュリティ研修( スライド )チーム開発研修( スラ
はじめに 1台のPCで複数のGitHubアカウントを使い分けたくなるシーンがたびたびあります。 たとえば会社のPCを使っている時に、自分のプライベートなリポジトリにちょっとしたコードをコミットするときなど。 そのような、「1台のPCで複数のGitHubアカウントを使い分ける」方法について、SSHを使った方法は調べると多くの方々の記事が出てきます。 【メモ】githubの複数アカウントにSSH接続するための設定手順 同一端末で、複数のGitHubアカウントを使い分ける方法 GitHubで複数のアカウントを使う場合のSSHの設定 が、httpsを使った方法はあまりweb上に情報が無いような気がします。 両方試してみたところhttpsの方がお手軽な感じがしたので せっかくなので2つの設定方法をメモしておきます。 ※ 元々は自身のブログにも投稿していた内容なんですが、どちらがオススメなのか皆さんか
はじめに Herokuのブロク記事10 Habits of a Happy Node Hacker (2016)を、「洋の東西を問わず、みんな『10のなんとか』って好きなんだな」と思いながら眺めていたら、結構面白かったので内容をピックアップしてみます。 以前、Go言語で幸せになれる10のテクニックというのをあるブログ記事を元にして書いた時には、原題の "Ten Useful Techniques in Go"を意訳して「幸せになれる」としたのだが、今回は原題にシッカリ"Happy"が入っているというおまけ付き。 なお、「2016年版」と言っているのは2013(2014?)年版があるから。これらを読み比べてみるのもまた面白いが、とりあえず今回は最新の2016年版のご紹介。 1. 新しいプロジェクトは npm init で始めろ 新しいプロジェクトはこう始めようよ、と言っている。
※この記事は元々「Gitのこれやめて!リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで!!」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く