docs.github.com › repositories › automatically-generated-release-notes 自動生成リリース ノートは、GitHub リリースのリリース ノートを手作業で記述する代わりに、自動的に生成する機能です。 自動生成リリース ノートを使うと、リリースの ...
はじめに 自分がコミットメッセージを書くときに考えていることを書きます。 ただし、絶対にこの書き方をずっと続けるというわけでありません。日が経つにつれ、「そういえばこんなことも思ってた」「こういうのいいなあ」「これないわー」といった心境の変化があると予想するので、その時その時で手を入れていくつもりでいます(入れないかもしれません)。なので生煮えです。たぶんずっと生煮えです。それにかこつけて文章の文体もざっくりしています。 あと、あくまでもオレオレなので他の人の書き方をどうこうする意図はありません。うっかり参考になったらいいなあぐらいです。 最初に概念的な話をしてから後半で実際の書き方に入ります。 なお、全体的に git を使う想定で書いていますが、それ以外でも大体同じだと思います。 コミットメッセージには何を書くのか そのコミットでリポジトリに入れた差分が何をしているのか、なぜそうしている
Gitit使ってたんじゃなかったのかよ、という話なのだが、Gititは単体でディレクトリ以下にホストできない((Virtual)Host必須)とか、いろいろ遭遇したので、別のものを使ってみた。 使ってみたのは、Githubの(?)Wiki engine「Gollum」 http://github.com/github/gollum Ruby, Sinatraのお馴染みの構成。今のところRuby 1.8でも動く優しい仕様。 画面はこんな感じ。 gemで入れる方法もあるが、細かい事情によりちょいちょいいじる必要があるため、git cloneしてbundlerで拾ってくる方法を取る(bundlerは例えばUbuntu 12.04ならapt-get install ruby-bundlerで入る。) bundleコマンドが使える状態になったら、bundleコマンドを叩く前に、libxsltの開発パ
Wikiというものはとても便利なんだけど、 大量の文章を書くにはWebブラウザのインターフェースはまだまだ辛い オフラインで使えない(文章書くのは電車が一番) 複数の文章を再構成したり、一括で検索したり、置換したりは、Webだとやっぱりきびしい と言った欠点がある。 とは言え、誰でも気軽に編集できるWikiの魅力も捨てがたい。 そこで、「Wikiではあるんだけど、ローカルでも自分の好きなエディタで簡単に編集できるツールないかなー」と探してみたら、 Gitit というWikiを発見した。 ここ数日、結構な量のドキュメントをGititで書いてみて、わりと満足しているのだけど、検索してもGititの日本語の情報があまり出てこないので紹介してみる。 Gititの特徴 コンテンツをGitのレポジトリに保存する。 そのGItレポジトリをcloneして好きなようにいじってからcommit/pushすれば
ウィキページは、GitHub 上で直接、あるいはコマンドラインを使ってローカルで追加および編集できます。
この記事では、detached HEAD がどういう状態なのかを git の内部構造から読み解きます。 あなたは、この2つのコマンドがどう違うか答えられるでしょうか? 問い: 下の 2 つのコマンドは同じでしょうか?違うでしょうか? A: git checkout <ブランチ名> B: git checkout <ブランチの指すSHA1> 正解は、違う です。 もし、答えに詰まってしまった場合は、ぜひこの記事を読んでみてください。 この解説の中で、下の2つのコマンドがどう違うのかが見えてきます。 (ちょっとだけ宣伝: 学生向けに git challenge というイベントを開いています。いくつか git にまつわる問題を公開しているので、興味がある方はチャレンジしてみてください!: http://alpha.mixi.co.jp/entry/2015/11/24/083300 ) deta
この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ? Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる(知らない間に容量の大きいファイルがコミットされている可能性がある) 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実
2015年11月15日、ミクシィ渋谷オフィスで git challengeという学生向け技術イベントの第1回を開催しました。#mixi_git この git challenge とは、問題がおきている Git リポジトリを、次のようなお題に沿って解決していく競技です。 うまく merge してください バグが埋め込まれた場所を特定してください push できない原因を特定してください ...… 第1回の当日は、このような問題が18問出題され、4時間の競技時間でどこまで解けるかを競いました。ここで出題された問題の難易度は、以下の4段階に設定されています。 EASY: 調べなくても解ける NORMAL: 調べれば解ける HARD: 調べた上で考えれば解ける VERY HARD: 考え尽くした上で最善の手を選び続ければ解ける この記事では、このうち実際に出題された問題を 2問 (EASY, NO
「ふたつのプロジェクトはそれぞれ別のものとして管理したい。だけど、一方を他方の一部としても使いたい」Git – サブモジュールの冒頭にこうありました。まさにこれがしたいと思っていたのでちょっと手を動かしてみました。今まで避けていたので。。 サブモジュールとは サブモジュールとは主な管理対象(管理対象A)に別のgit管理対象(管理対象B)を追加することです。ただし、管理対象Bの中身までは管理しません。あくまでも、管理対象Bの特定のコミットを記録するだけです。 サブモジュールの追加 $ git submodule add git://github.com/chneukirchen/rack.git rack これを行うと、.gitsubmodulesと、rackがAの管理対象に追加される。 $ cat .gitmodules [submodule "rack"] path = rack url
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(!) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか?」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか?これつけると何が変わるんですか?」と質問がきたのです。 作業ブランチで git pull --rebase origin master
先日、皆さまにお願いした CreateJS のドキュメント翻訳では GitHub を利用しています。GitHub を使うのは初めてという方もいるかもしれませんので、いまさらながら簡単な使い方をご紹介します。 一般的な (といっても GitHub の使い方が指定されているわけではないですが) GitHub を利用した共同開発には以下の 2 種類があるようです。 共有リポジトリ リポジトリ (しばしば "repo" と呼ばれます) は、GitHub が、プロジェクトに関連するファイルをまとめて保管する単位です。CreateJS 翻訳プロジェクトも CreateJS/localization という名前のリポジトリを持っています。 これをチーム内で共有して、作業目的ごとにブランチ (Branch) と呼ばれるコピーを作り、適当なタイミングでブランチに対して行われた更新をオリジナル (Master
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
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request(プルリクエスト)機能を使ったことはありますか? GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork(コピー)してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く