Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか? トーバルズ:俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた(データベースは別だが)。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。「誰が変更を行えるか」といった政治問題があるが、B
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
Using Git To use Git on the command line, you will need to download, install, and configure Git on your computer. You can also install GitHub CLI to use GitHub from the command line. For more information, see About GitHub CLI. If you want to work with Git locally, but do not want to use the command line, you can download and install the GitHub Desktop client. For more information, see About GitHub
gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く