タグ

関連タグで絞り込む (2)

タグの絞り込みを解除

gitとqiitaに関するstibbarのブックマーク (8)

  • Git 2つのリモートリポジトリを同期する - Qiita

    2つのGitリモートリモートリポジトリをできるだけ手間なく同期する方法を紹介します。 検証背景 番用の環境にもリモートリポジトリを作成する必要があった 開発用のリモートリポジトリとヒストリレベルでも同期させる必要があった 開発用と番用の環境は物理的に異なるネットワークにあった 直接は繋がらない 中継用のPC(ローカルリポジトリ)を使ってコマンドだけでマージできないか。。。 処理イメージ このやり方で同期できました。 初回のみ ①~②は初回のみ実行すればOKです。 ①番用リポジトリのclone

    Git 2つのリモートリポジトリを同期する - Qiita
  • これだけ知っておけば幸せになれるGitコマンドたち - Qiita

    この記事なんやねん これだけ知っておけば現場での開発では困らないだろうGitコマンドをつらつらと載せていきます。 マニアックなコマンドは載せないので、内容的には初級者向けです。 add、commitなどの超基的なコマンドはリッチテキストエディタならGUIから操作できるので省略してます。 用語解説 この記事で使う用語解説もついでに載せておきます。 因みに、サルでもわかるGit入門が入門チュートリアルとしてはオススメなので完全にGit触るのが初めてならこちらも確認してください。 リモートリポジトリ Gitは分散型バージョン管理システムなのでリモートリポジトリとローカルリポジトリが存在します。リモートリポジトリは複数人で作業する時に使う共有リポジトリで、例えばGitHub上で作った自分のリポジトリなどのことです。 ローカルリポジトリ 自分専用のリポジトリです。ローカル環境にあるのでオフラインで

    これだけ知っておけば幸せになれるGitコマンドたち - Qiita
  • git diffの全オプション一覧 - Qiita

    GitのサイトにはPro Git 2nd ed. Editionというが全文無償公開されていて、日語訳も公開されています。 なのでGitの使い方についてはこのを読めば概ね事足ります。 ちなみに最新版はGitHubにあります。 それはいいのですが、なにげに意外なことにリファレンスは日語訳が、というか英語以外の言語がないみたいです。 以下は、諸事情でgit diff --break-rewritesについて知りたかったのだけど日語解説が一件たりとも存在しなかったので調べたついでに全オプションについて軽く調べてみたメモです。 マニュアルのバージョンは2.20.0。 git diff SYNOPSIS 書式。 基的にgit diff、オプション、対象コミット、--、対象ファイル名の順に書く。 git diff [<options>] [<commit>] [--] [<path>…​]

    git diffの全オプション一覧 - Qiita
  • git log を1行表示にする+日付を表示する - Qiita

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

    git log を1行表示にする+日付を表示する - Qiita
  • Git-flowって何? - Qiita

    git-flowとは、プラグイン(ツール)のことです。。 Vincent Driessen氏がブログに書いた"A successful Git branching model" というブランチモデルの導入を簡単にする git プラグインである。 参考資料: ・ http://hm-solution.jp/lifehack/post2475.html ・ http://d.hatena.ne.jp/Yamashiro0217/20120903/1346640190 Git-flowイメージと各ブランチの役割 master: プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。 develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。 feature branches: 機能の追加。

    Git-flowって何? - Qiita
  • .keepファイルは何のために存在するの? - Qiita

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

    .keepファイルは何のために存在するの? - Qiita
  • .gitattributesで改行コードの扱いを制御する - Qiita

    Gitで管理するファイルの改行コードの扱いは、どうしたらよいのでしょうか。どうルール化するのがよいのでしょうか。 なぜルールが必要か そもそもなぜルールが必要なのでしょうか。以下の例で考えます。 AさんはLinuxマシンでコーディングしており、LFで改行されたソースコードのファイルXをGitにコミットしました。 一方、BさんはWindowsマシンでコーディングしています。今、Aさんが書いたコードを編集したいとします。GitからファイルXをチェックアウトして編集するわけですが、このとき、Bさんが使っているエディタはファイルXの改行コードをCRLFに変換してしまいました。Bさんはそれに気づかずコードを編集し、保存し、コミットしました。 BさんはファイルXの中の数行だけを編集したつもりなのに、改行コードが変わったために、全行に差分が生じてしまいました。これではコードレビューもしにくいし、後日、g

    .gitattributesで改行コードの扱いを制御する - Qiita
  • git bisect で問題箇所を特定する - Qiita

    以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか?」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない(good)状態と問題がある(bad)状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします(例えばソースからのビルド処理もテストスクリプトに含めま

    git bisect で問題箇所を特定する - Qiita
  • 1