タグ

Gitとpracticeに関するkiyo_hikoのブックマーク (5)

  • Gitで git rm を使わずにファイルを削除した場合のプラクティス | youria blog

    Gitで追跡しているファイルを削除する場合、通常git rmを使用します。しかし統合開発環境やターミナル、エクスプローラなどで直接ファイルを削除することが多々あるでしょう。その際に [kyo@localhost ~]# git add . を行なっても削除されたファイルは # Changes not staged for commit: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # deleted: example.xml # となりstageされません。既に存在しないファイルに対して [kyo@localhost ~]# git rm exam

    Gitで git rm を使わずにファイルを削除した場合のプラクティス | youria blog
  • gitでタグ名に日付を含めているのはダサい - アジャイルSEの憂鬱

    この記事は私の考えるタグの使い方なので、もし間違っている事や反論のある方は ぜひコメントやブログを書いてください。読みます! タグを打つ意味 そもそも、なぜgitでタグを打つのか? これは下記のような理由だと思う。 sha1でコミュニケーションするのは一般的に難しい*1 コミットとは別にデプロイなどのイベントをリポジトリ内で扱うため そもそも、gitのタグとは gitのタグはタグオブジェクトという形でgitのリポジトリ内に保存されます。*2 タグオブジェクトには下記の情報が含まれます。 タグを作成した日時 タグ作成者 タグを作成した理由 タグを付けたコミットのsha1 日付つきのタグとは タグの名前に日付情報がつけられたものです。 $ git tag -m "bump tag" 1.0.0-`date "+%Y%m%d_%H%M%S"` $ git tag -l 1.0.0-2014060

    gitでタグ名に日付を含めているのはダサい - アジャイルSEの憂鬱
  • ローカルリポジトリのmasterブランチは別に無くても良い? - Qiita

    喧嘩を売るつもりはございません。 理由 Gitでブランチを作るのを忘れてmasterにコミットしてしまったときの対処法というQiita記事のコメント欄で ローカルのmasterブランチは別に持たなくても良い(むしろローカルにmasterがあるから表題のミスが起こる。) というコメントがあり、確かにな〜と共感したのが始まり。 masterで作業していることに気づかず、プッシュするときに「あぁ…」となる人も多いはず。 こういう悲しみが生まれること無く、皆が幸せになれるのではないでしょうか? とりあえずmasterブランチを消そう git branch -D masterで削除。さよなら。 git fetchしましょう git pullを主に使用している人にはあまり馴染みのないコマンド(私もつい最近知った)。 git fetchの理解からgit mergeとpullの役割 ここに非常にわかりやす

    ローカルリポジトリのmasterブランチは別に無くても良い? - Qiita
    kiyo_hiko
    kiyo_hiko 2016/03/07
    これからはlocalのmasterなしでやりたい
  • gitを社内LANで運用しようと考えていますが、どんな方法がおすすめですか?…

    gitを社内LANで運用しようと考えていますが、どんな方法がおすすめですか? 目的はソースコードのバージョン管理ではなく、各部門のdocx,xlsx等のドキュメントのバージョン管理です。 仕事柄、各部門(多数)のマニュアルの変更が頻繁にあります。またこれらのマニュアルは監査等で第三者機関からチェックされるので、きちんと管理されるべきですが、現状きちんと管理されているとはいえません。 そこでバージョン管理システムの導入を考えています。 かといって私はまだgitに関する全体像を把握できていないため、このような場合にどんな環境構築を採用すべきかなどがよくわからない状態です。 求められる条件は下記のような感じだと思います。 ・クライアント環境はWindows7 ・gitサーバはWindows7あたりで(予備機が余っているので) ・社内のイントラネット環境 ・誰にでもできるようにGUI操作でクローン

  • Gitのベストプラクティクスっぽいもの - Sexually Knowing

    tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう

    Gitのベストプラクティクスっぽいもの - Sexually Knowing
  • 1