タグ

gitに関するn2sのブックマーク (1,303)

  • Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社

    Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ

    Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
    n2s
    n2s 2016/01/07
  • 「Git 2.7」リリース、多数の機能強化などが行われる | OSDN Magazine

    オープンソースの分散バージョン管理ソフトウェアGit開発チームは1月4日、最新版となる「Git 2.7」を公開した。複数の異なるディレクトリにローカルブランチを作成できるコマンド「worktree」に関連した強化など、多数の機能が加わっている。 Git 2.7は2015年9月に公開されたGit 2.6に続く最新版で、性能、開発、ユーザーインターフェイス(UI)、ワークフローなど多くの改善が行われている。 2.5で導入された「git worktree」コマンドで、新たにリポジトリのワークツリーを表示する「list」サブコマンドが追加された。また「git bisect」コマンドはworktreeごとに独立して実行できるよう変更されている。さらにgit bisectで利用されている「good」と「bad」という単語は状況によっては混乱を招くとして、新たに「old」や「new」という用語が導入され

    「Git 2.7」リリース、多数の機能強化などが行われる | OSDN Magazine
    n2s
    n2s 2016/01/06
  • SVNを捨ててGitを使うべき5つの理由 - Qiita

    まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している(Git Lover)と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう? 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです(たぶん)。 それが今で

    SVNを捨ててGitを使うべき5つの理由 - Qiita
    n2s
    n2s 2016/01/05
    SVNとかCVSとか中央集権型を使い続けたい人の気持ちも分かるよ。一回のcommit毎に紙文書に何個ものハンコを押して了承を求めるようなガチガチの管理統制文化が、手元で気軽にcommitできるGitにぶち壊されちゃうんだから。
  • https://qiita.com/falloutkids/items/08b3b7a2dfdc4c9eeaa3

    n2s
    n2s 2016/01/04
  • gitでrename&modifyしたファイルのログを追跡できるようにしたい場合 - Qiita

    この記事のサマリ gitでバージョン管理しているファイルをリネームしたい場合に、リネーム前のログもたどれるようにしておきたい場合は、 ①「git mv」でリネームして「git commit」でコミットを発行 ②その後、対象ファイルを修正してコミット といった手順を取ると ③「git log --follow」でリネーム前のログも辿れるというお話です。 注意:①と②を同時にやってしまうと、どうもうまくログをたどれないらしいというお話も含みます。 シチュエーション git管理して、すでにコミットログが溜まってそれなりに歴史のあるファイルがあったとします。 そのファイルをある時、ファイル名の変更と内容の修正が必要に迫られたようなシーンを想定しています。歴史のあるファイルなので、特に昔のログは追いかけるようにしておきたいですよね。 具体的な例では、 railsの勉強とgitの勉強のために、サンプル

    gitでrename&modifyしたファイルのログを追跡できるようにしたい場合 - Qiita
    n2s
    n2s 2016/01/04
    git log --follow
  • 気付いたら.gitignoreはgiboで自動生成する時代になっていた - Qiita

    $ gibo --version gibo 1.0.4 by Simon Whitaker <sw@netcetera.org> https://github.com/simonwhitaker/gibo $ gibo java ### https://raw.github.com/github/gitignore/8c9b77cb5c85f6464c0bb31abdf4cfcfdf6833bb/java.gitignore *.class # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.ear # virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml hs_err_pid*

    気付いたら.gitignoreはgiboで自動生成する時代になっていた - Qiita
    n2s
    n2s 2016/01/04
    …愛子?(爆)
  • はじめてのGit

    Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev

    はじめてのGit
    n2s
    n2s 2015/12/25
  • GitHub にパスワードとかセンシティブなファイルを push してしまったときの対処法 - Qiita

    .gitignore し忘れて他人に見えちゃマズいファイル(パスワードをベタ書きしたファイルや AWS_SECRET_ACCESS_KEY を書いたファイルとか)を git commit しちゃった!そんなときは すればすぐ何もなかったことにできます。 が!そこで気付かずに GitHub へ git push してしまった!こうなると容易に何もなかったことにはできません。 この記事では、こういうときに何もなかったことにする方法を紹介します。 そのデータを無効にする 特に Public Repository の場合はすでにそのデータが他人の目に触れていた…ということも十分ありえます。AWS_SECRET_ACCESS_KEY なんかは取得用のクローラが存在するとも聞きます。ので、まずは不正利用されても影響が出ないように、パスワードの書き換えやトークンの無効化を施しましょう。 (この時点でもう

    GitHub にパスワードとかセンシティブなファイルを push してしまったときの対処法 - Qiita
  • Gitで過去に削除してコミットしたファイルを復元する - Qiita

    いらないとおもって消したけどやっぱり必要だったっていうことがありましてね。 削除してコミットしたファイルを復元する方法 削除したファイルを見つける git logで削除前のコミットIDをメモ。 git diff HEAD <コミットID> --name-onlyで変更したファイルを確認して、ファイル名をメモ。

    Gitで過去に削除してコミットしたファイルを復元する - Qiita
    n2s
    n2s 2015/12/14
  • git-fastclone - Gitリポジトリのcloneを高速化

    Gitはリポジトリの情報をすべてローカルに持ってくるのでサイズが大きくなりがちです。その結果、clone処理が遅くなってイライラさせられることでしょう。さらに他のリポジトリと関連付いていて、そのデータまで持ってくると遅さが際立ちます。 そこで使ってみたいのがgit-fastcloneです。git-fastcloneはclone処理を高速化するソフトウェアで、特にrecursiveに対して効果を発揮します。 git-fastcloneの使い方 インストールはRubygemsで行います。 gem install git-fastclone 後はcloneの代わりにfastcloneを使うだけです。 git fastclone https://github.com/timekit-io/booking-js.git 例えば上記のリポジトリで実行しても、実は早くなりません。早くなるための条件があり

    git-fastclone - Gitリポジトリのcloneを高速化
    n2s
    n2s 2015/12/14
  • Gitリポジトリをメンテナンスして軽量化する - Qiita

    この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ? Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる(知らない間に容量の大きいファイルがコミットされている可能性がある) 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実

    Gitリポジトリをメンテナンスして軽量化する - Qiita
  • gitのmerge --no-ff のススメ - Qiita

    2015年も終わりになって、gitの基的な使い方の話に更なる需要があるとは思っていないのですが 日が私のAdventCalender担当日であることと、日偶然遭遇したトラブルの都合上、もしかしたらまだ需要が微レ存かもしれないと思い記事を書いていきたいと思います。 まとめ 皆しとくといい。 git のデフォルト設定はどうなっているか gitはデフォルトではmergeコマンドを使った際に、mergeコミットを発生させる必要がない場合mergeコミットを発生せずにmergeを行うfast-forwardでのmergeを行うようになっている。 --no-ffというオプションを付けることで意図的にfast-forwardを行わないコミットをすることが出来る。 どういうトラブルが起こるか 仮にmasterにtopicAブランチをmergeしたとする。 fast-forwardであるmergeの場

    gitのmerge --no-ff のススメ - Qiita
    n2s
    n2s 2015/12/08
  • "git log" で今日行った作業を表示&ファイル出力するときの注意 - Qiita

    $ git today ## 出力結果 - d9bed14 : first commit (2015-12-07 11:29:50 +0900) - 700eeed : second commit (2015-12-07 11:30:00 +0900) - 20ee988 : third commit (2015-12-07 11:30:06 +0900) - bc5d42d : forth commit (2015-12-07 12:04:56 +0900) ワンライナーでも書けるとは思いますが、見やすさ重視の為に、!f () { };fを使用してます。 コピペでなく手入力で追加する際は、スペースの位置( ()と{の間とか )に気をつけてください。 一部のoption、formatは好みがあると思うので、下記参考にしてカスタマイズしてもらえればと思います。 オプション等の解説 --rev

    "git log" で今日行った作業を表示&ファイル出力するときの注意 - Qiita
    n2s
    n2s 2015/12/07
  • Gitのブランチを移動するときの裏ワザ - Qiita

    Gitでは、簡単にブランチを切れるようになっていますが、その中身を知れば、より便利に移動できます。なお、この投稿は1分で実現できる有用な技術 Advent Calendar 2015の1記事として投稿しています。 Gitツリーの構造 ちょうどGitのアドベントカレンダーの投稿が参考になりますのでので、詳細についてはそこを参照させていただく形にします。 こちらで必要な程度に要約すれば、 コミットは、それ自体が過去のコミットとの関連情報を持っている 「ブランチ」と呼ばれるものも、自律的につながったコミットのある1箇所を指すポインタに過ぎない ということです。 微妙に面倒な切り替え→マージ よくある場面で、「Aブランチの後にBブランチが続いている状況で、BブランチをAブランチに追いつかせた上でチェックアウトしたい」というときがあります。素直にやれば、 git checkout b git mer

    Gitのブランチを移動するときの裏ワザ - Qiita
  • PullRequestベースの開発ではGit Rebase使った方がいい - Qiita

    岩手県立大学ソフトウェア情報学部 Advent Calendar 2015の4日目です。 @otukutunではなく、私が書いてみました。 1年早いですね。 今年はQiita全然かけませんでしたが、Advent Calendarで挽回していきたいと思います。 みなさん、Git Rebase使ってますか? 私は正直なんか怖いと思っていました。 ログが書き換わるとか、 Pushするときに強制的にしないといけないとか、 なんでそんなことしなきゃいけないの? と ずっと謎だったのですが、 最近、一緒に開発している方から教えてもらったので、 共有したいなと思います。 そもそも なんで Git Rebaseするのか? はじめに、Rebaseの意味とは、 Re Baseなので、 基点を変える ということです! なんでそんなことをするかと言いますと、 最新のコミットをPullRequestで送るためです!

    PullRequestベースの開発ではGit Rebase使った方がいい - Qiita
    n2s
    n2s 2015/12/05
  • 【GitHub】Pull Requestの手順 - Qiita

    Git勉強会(社内勉強会)でできなかった、Pull Requestについての説明です。 Pull Request の手順 単純にソースコードを取得したいならgit clone http://{対象のGitHubリポジトリ}で大丈夫です。もしコードの内容を修正したい場合はリポジトリをForkする必要があります。 対象のGitHubリポジトリをFork ローカルへclone(クローン) ローカルリポジトリで新規ブランチを作成 修正を加える(コミット) 作成したブランチをpush(プッシュ)する Pull RequestをGitHub上で作成 1. 対象のGitHubリポジトリをFork 対象のGitHubリポジトリをブラウザ上でアクセスします。 んで、そこにあるForkってボタンをクリック。 自分のアカウントに対象のリポジトリがForkされます。 Forkって何? 基的にはgit clone

    【GitHub】Pull Requestの手順 - Qiita
    n2s
    n2s 2015/12/03
  • レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog

    こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 稿は Git 以外の第三世代構成管理ツール(Hg、Bzr など)にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ

    レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
    n2s
    n2s 2015/11/30
  • Git入門(2) 怖くないリセット - Qiita

    この話のゴール 前回 と同様に、Gitを多少使ったことがある人向け git reset が何をリセットするのかを理解する git reset を安心して使えるようになる reflog と stash の関係に感銘を受ける ステージングエリア、作業ツリー Gitのcommit済みの履歴は.git/objectsに格納された commit オブジェクトで管理されていました。また、ステージングエリア(index)には git add で登録されたblobたちを参照するtreeが格納されているのを見ました。 commit直後の index には何が格納されているでしょうか? % git init Initialized empty Git repository in .git/ % echo aaa > aaa.txt % git add aaa.txt % git commit -m "init

    Git入門(2) 怖くないリセット - Qiita
    n2s
    n2s 2015/11/30
  • [Git] 一部のファイル、部分的な変更点のみgit stashする - Qiita

    # stashのリストを取得 $ git stash list stash@{0}: fix hoge stash@{1}: add fuga # 各stashの変更ファイルを表示 $ git stash show stash@{0} hoge.cpp | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)

    [Git] 一部のファイル、部分的な変更点のみgit stashする - Qiita
    n2s
    n2s 2015/11/16
  • SubGitでSubversionリポジトリからGitリポジトリに移行すると速い - @peccul is peccu

    巨大なSubversionリポジトリをGitに移行しようと思ったのですが、git-svnが遅かった。 SubGitというのを見つけて使ってみると速かった。 www.subgit.com Java1.7以降が必要。 雰囲気はこんな感じ。svnリポジトリからgitのbareリポジトリが吐き出される。 そのままGitBucketのリポジトリ置き場においても良い。 % ~/Downloads/subgit-3.0.0/bin/subgit configure /path/to/svn/repo SubGit version 3.0.0 ('Bobique') build #3320 Configuring writable Git mirror of remote Subversion repository: Subversion repository URL : /path/to/svn/rep

    SubGitでSubversionリポジトリからGitリポジトリに移行すると速い - @peccul is peccu
    n2s
    n2s 2015/11/10
    要Java