春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
Gitで全てのリポジトリのignore指定を ~/.gitignore_global に置いている例はよく見られます。実際、この名前はGitが公式で公開している本 (Pro Git 2) (→日本語版) でも言及されています。 このような設定を行うには、グローバルな .gitignore のようなファイルが必要です。 ~/.gitignore_global ファイルへ次の内容を書き込んで、 (...) ところがこれはややミスリーディングです。この部分は core.excludesfile 自体の説明にほかならないのでわざわざ設定を書き換えていますが、実はデフォルト値があります。これは gitignoreのマニュアル で説明されています。 Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is eith
対象読者 Gitをより深く理解したい方 Gitの自作に興味がある方 Gitの内部構造を学ぶ意義 Gitの使い方を知っている人でも、それぞれのサブコマンドが実際どういった挙動をしているか、ましてや内部構造がどうなっているかを学んだことがある人は少ないかもしれません。というのも、Gitが内部を知らなくとも十分使える優秀なツールになっているからだと思います。 しかし、Gitの内部実装を知ることで、コマンドの挙動を正確に理解できるだけでなく、Gitを使っていて何らかの問題が起きたときにも、自分で対処できるようになります。そうしたGitの地力を鍛えるために、内部構造の把握は重要な要素になってきます。 また、今回の内容を学べば、Gitの大枠を実装することもできてしまうので、興味がある方はぜひ挑戦してみてください。 Gitについての誤解 それでは、まずGitについて多くの人が誤解しているであろう点を挙げ
みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 この記事では、Git を使った仕事のやり方（以降は Git ワークフローと記載）を設計する上での検討事項を説明します。 これによって、読者の皆さんがGitワークフローを適切に定義できるようになることを主たる目的としています。 また、筆者の能力不足によって記載しきれなかった考慮事項について、より深く Git を使いこなしている識者からの指摘を受ける機会を得ることを副次的な目的とします。 この記事には書かれていないものの、検討すべき事項について知見のある方はブログ記事を書いたり、Twitter等のSNSで指摘してくださるとありがたいです。 はじめに 基本的な考え方 Git ワークフロー設計における考慮事項 チームの人数 monorepoの検討 参考文献 プロジェクト管理ツールと
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
これらのステップを実行してください： リモート リポジトリの追加 新しいリモートを追加するには、リポジトリが保存されているディレクトリでターミナルから git remote add コマンドを使います。 git remote add コマンドは 2 つの引数を取ります。 リモート名 (例: origin) リモート URL (例: https://github.com/OWNER/REPOSITORY.git) 次に例を示します。 $ git remote add origin https://github.com/OWNER/REPOSITORY.git # Set a new remote $ git remote -v # Verify new remote > origin https://github.com/OWNER/REPOSITORY.git (fetch) > orig
複合要因でなかなか面倒な SourceTree + Bitbucket の認証エラーの対策について、良く分かってない人（例えば自分）向けに情報をまとめておきます。 Windows 環境がターゲットの記事になります。 症状としては、SourceTree のGUIからリモートリポジトリにアクセスしようとすると、こんな感じのエラーが出るパターン。 fatal: HttpsRequestException encounterd. remote: Invalid username or passwordでも、ターミナルから直接 git コマンドを打てば認証も通るしPUSHもPULLもできる、というケース。 解決方法としては、2つのパターンがあります。 1つ目は、以下のサイトから「Git Credential Manager for Windows（以下、GCMW）」の最新版を入手してインストールすれ
はじめに（読み飛ばしてO.K.） こんにちは。 コーダーをやっているものです。 開発サイドにいる方であれば、一度は使おうとしたであろうツール。 「GitのGUIクライアント」。 私は普段ツールで悩んだ際はシェアの高いものを選ぶようにしているため、「GitのGUIクライアント」に関しても一番人気だった『Sourcetree』を使っていました。 シェアの高いものであれば、固有のバグが発生した際にネットからいくらでも情報が得られますので。 しかし、最近『Sourcetree』が不調&超重かったのと「見た目がかっこいい」という理由で『GitKraken』に浮気。 そうして『GitKraken』を使っているうちに、『GitKraken』と『Sourcetree』それぞれの良い部分・悪い部分が見えてきたので、誰かの助けになればとまとめてみました。 どうぞご参考まで。 『GitKraken』を選ぶメリッ
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
+1 for telling me about diff3 alone—how often I was looking on an incomprehensible conflict, cursing whoever is responsible for not telling me what the common ancestor had to say. Thank you very much. Well said, John of StackOverflow. The diff3 conflict resolution strategy is a hidden gem in git that has saved me uncountable conflict-resolution headaches and has turned git conflict resolution into
原文(投稿日：2020/04/07)へのリンク 2005年4月7日、今からちょうど15年前、Gitはセルフホストの可能な完成度に到達した。すなわち、コードをコミットするためにGit自身を使用できるようになったのだ。今日、Gitは最も広く使用される開発ツールのひとつとなり、開発者がコードを管理する方法を大きく変えている。InfoQは今回、GitHubの上級(Distinguished)ソフトウェアエンジニアであるJeff King氏、GitLabのシニアデベロッパエバンジェリストであるBrendan O'Leary氏と、Gitの持つ重要性について話す機会を得ることができた。 Gitは元々、LinuxカーネルのSCM問題に終止符を打つために、Linuxの作成者でメンテナであるLinus Torvalds氏の手によって生まれた。氏は当時のLinuxが使用していたSCMであるBitKeeperの代
2018/3/27 追加加筆 はじめに GitKrakenのインストールから初回起動、リポジトリ操作やリモートリポジトリの取り込みまで簡単に紹介します。 操作はMac版で行っていますが、おそらくWindows版でもほぼ変わらないとは思います。 はじめに GitKrakenって？ GitKrakenのインストール 初回起動 GitKrakenでリポジトリ操作を行う。 新規にローカルにリポジトリを作成してGitKraken管理していく リモートにあるリポジトリを読み込んでGitKrakenで管理する GitKrakenって？ 一言で言えば、GitをGUIベースで扱えるようになるツールです。 他のGitをGUIベースで使えるツールとしたら、AtlassianのSourceTreeが有名所です。 アイコンがどうみても、Githubのoctocatを意識しているとしか思えない… GitKrakenは
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※この記事は 今年イチ！お勧めしたいテクニック by ゆめみ feat.やめ太郎 Advent Calendar 2019年12月10日（10日目)の記事です。 初めましての方は、はじめまして ご存知の方は、そうだよ。ヒズミさんだよ。 縁とノリと勢いで、10日目を担当します。 僕は、俗物なので、ハマーンミュラーの椅子はきっと無理です（typoじゃないです） epic1:悲劇は突然に 自分が何やったかわかっとんのか・・・( 'ω')👉 わﾞかﾞっﾞとﾞんﾞのﾞかﾞあﾞあﾞあﾞ！？ ( ‘ᾥ’ )👉👉👉 上キー押せよ・・・( 'ω'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
