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
Discuss code Read old and new versions of files with syntax highlighting and colored differences. Discuss specific sections with others to make the right changes. Manage and serve Git repositories Gerrit includes Git-enabled SSH and HTTPS servers compatible with all Git clients. Simplify management by hosting many Git repositories together. Schedule git gc over all managed repositories and replica
Standardized and automated development environments Self-host in 3 minutes
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って? git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ! # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
最初に なんとなくでも使用できるGitですが実はとても奥深く複雑な構造をしています。 そんなGitを使い始めた時ほぼ全員が思う「HEAD」とは何者なのか説明したいと思います。 また合わせて「Branchとは」「detached HEADとは」についても話します。 先に結論ファーストで話しますと 今自分が作業している場所を示すポインタ Branchとは 開発の本流から分岐し、本流の開発を邪魔することなく作業を続ける機能 detached HEADとは HEADがBranchを指していない状態のこと そして僕自身以前までブランチとはなにか聞かれた場合、下図のようなイメージを持っていました。 そしてこれは誤った認識です。 この記事はMake IT アドベントカレンダー9日目の記事として寄稿しています! 明日は @wh1tecat が投稿する予定です。 楽しみですね(笑) Branchとは まずG
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。 梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。 $ git pull warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebas
結論 Git管理下のディレクトリにおいて、 .git/info/exclude に指定したファイルは、.gitignore と同様にGit管理から除外されます。 この場合、他のリポジトリ(=リモートや他人のローカル)には影響ありません。 公式ドキュメント https://git-scm.com/docs/gitignore 本文 まえがき システム開発をしていると、テスト用のファイルだとか、自分用のメモやスクリプトだとかを使う機会も出てきます。開発しているコードと関連するので同じディレクトリに入れたいです。他のディレクトリに入れるとなくします。 しかし、共同開発者には関係のないファイルをコミットするわけにはいかず、かといって .gitignore に自分専用の設定を書くわけにもいきません。 そこで、 .git/info 以下にある exclude というファイルを使うとこの問題を解決できま
I have changed a few files name by de-capitalize the first letter, as in Name.jpg to name.jpg. Git does not recognize this changes and I had to delete the files and upload them again. Is there a way that Git can be case-sensitive when checking for changes in file names? I have not made any changes to the file itself.
Ubuntu 18.04 LTS, git 2.17.1, bash 4.4.19で確認しています。 いつの頃から、手元の環境で git branch を実行した際に、単にターミナルに出力されるのではなく、pager内で表示されるようになりました。 大量にブランチがあれば便利なんでしょうが、pagerを抜けるために qとタイプする必要があるし、抜けたら抜けたでgit branchの表示が消えてしまう。 だいぶ耐えていましたが、もう我慢ならないのでggってみました。 啓示をくれるのはいつだって Stackoverflow。 Git branch command behaves like 'less' https://stackoverflow.com/questions/48341920/git-branch-command-behaves-like-less git config すればい
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
Git is one of the most widely used collaboration tools in Software development. Even software developers working without teams often use Git as a version control system. Most people interact with Git through the command line, but many code editors and IDEs have Git integrations with built-in tools to make your workflow easier. Though Git is widely used, many developers only have a surface-level ap
今所属してるチームに入ってから1年が経った。開発してるサービスのコードベースの中でも、「このへんはわりと土地勘がついてきたな」という場所と「ここはまだ全然わからん」という場所が混在している感じになってきた。 自分がまだ触ったことないのはどのあたりかを知りたかったので、今までの自分のコミット数をファイルごとに見れるようにしてみようと思った。調べてもそういうツールは見つからなかったので、作った。 ファイルの履歴 ファイルのコミット履歴を出力する: git log ファイル名 リネーム前の履歴も欲しい: git log --follow ファイル名 しかし --follow つけると、ファイルをコピーしてからちょっと編集したやつも同一ファイルと見做されてしまうので、それをなるべく避ける*1: git log --follow --find-renames=100% ファイル名 そのコミット履歴を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く