.gitattributesで改行コードの扱いを制御する - Qiita
Gitで管理するファイルの改行コードの扱いは、どうしたらよいのでしょうか。どうルール化するのがよいのでしょうか。 なぜルールが必要か そもそもなぜルールが必要なのでしょうか。以下の例で考えます。 AさんはLinuxマシンでコーディングしており、LFで改行されたソースコードのファイルXをGitにコミットしました。 一方、BさんはWindowsマシンでコーディングしています。今、Aさんが書いたコードを編集したいとします。GitからファイルXをチェックアウトして編集するわけですが、このとき、Bさんが使っているエディタはファイルXの改行コードをCRLFに変換してしまいました。Bさんはそれに気づかずコードを編集し、保存し、コミットしました。 BさんはファイルXの中の数行だけを編集したつもりなのに、改行コードが変わったために、全行に差分が生じてしまいました。これではコードレビューもしにくいし、後日、g
サル先生のGit入門
ブランチ ブランチとは ブランチの運用 ブランチの切り替え ブランチの統合 トピックブランチと統合ブランチでの運用例 チュートリアル1 ブランチを使ってみよう！ 0. 前準備 1. ブランチを作成する 2. ブランチを切り替える 3. ブランチをマージする 4. ブランチを削除する 5. 並行で作業する 6. マージでの衝突を解決する 7. rebaseでマージする リモートリポジトリ pull fetch push タグ タグ チュートリアル2 タグを使ってみよう！ 0. 前準備 1. 軽量タグを追加する 2. 注釈付きタグを追加する 3. タグを削除する コミットの書き換え 直前のコミットを修正する 過去のコミットを打ち消す コミットを捨てる コミットを抜き取る コミットの履歴を書き換える ブランチ上のコミットを一つにまとめてマージする チュートリアル3 コミットを書き換えよう！ 1.
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Git リポジトリの内容を zip ファイルにする - Qiita
git clone したフォルダを単純に zip すると、.git フォルダが含まれてしまったり、普段は .gitignore などで無視しているファイルが含まれてしまったりします。 Git リポジトリの内容だけを取り出して zip ファイルにするには、git archive コマンドが便利です。 参考：GitHub だと、Git のタグをつけておくことで、git archive で生成したファイルと同様の zip ファイルが Release ページからダウンロードできます。 基本的な使い方 Git リポジトリの内容を zip ファイルにするには次のようにします。HEAD の部分は、タグ名、ブランチ名、コミットID、などが指定できます。
gitのコミット時間を変更する - Qiita
commit 176eca240a37e7bfa3292eb99a0712aca23c3052 Author: yamada_taro <yamada_taro@mail.com> Date: Fri Jul 29 19:00:38 2016 +0900 commit 176eca240a37e7bfa3292eb99a0712aca23c3052 Author: yamada_taro <yamada_taro@mail.com> AuthorDate: Fri Jul 29 19:00:38 2016 +0900 Commit: yamada_taro <yamada_taro@mail.com> CommitDate: Fri Jul 29 19:00:38 2016 +0900
git-worktree を使って時間のかかる処理を別の作業ディレクトリで行う - アジャイルSEの憂鬱
時間のかかる処理の実行中、別の作業を進められるようにする方法。備忘録。 時間のかかる処理の例 テストの実行中 デプロイの実行中 など。 git-worktree を使う 簡単に作業ディレクトリを増やせる。 $ cd ~/works/app $ git worktree add ~/works/app_deploy $ cd ~/works/app_deploy $ git status On branch app_deploy nothing to commit, working tree clean 新しく作成された app_deploy の作業ディレクトリでも普通のリポジトリと同じように作業ができる。 注意点 両方の作業ディレクトリで同じブランチを使えない 作業ディレクトリを2つに増やしても、同じブランチは使えません。 別名のブランチを作る必要があります。 リポジトリは共通 リポジトリ
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！ - Qiita
masterブランチでちょっとした変更をしたいんだけど、devブランチで作業しているから切り替えるのはめんどくさい。 そんな時はgit worktreeを使ってみてください。複数のブランチを切り替えずに操作できます。 ※git worktreeを使うにはGit 2.7.0以降が必要です。それ以前のバージョンだとgit worktree listがありません。 ブランチの追加 操作したいブランチはこんな風に持ってくることができます。 すると、作業ディレクトリ以下に指定したブランチの中身がリンクされます。 たとえば、git worktree add ./worktree-dev devとコマンドを打つと、./worktree-devディレクトリが作成され、その下にdevブランチの内容ができるわけです。 git worktreeは今いるブランチに影響を与えません。 つまり、作業中であっても操作し
Git 2.x シリーズの 6 つの素晴らしいフィーチャー | Atlassian Japan 公式ブログ | アトラシアン株式会社
私が Git リリース ノートをレビューしてからしばらく経ちましたが 、だからといって私が最新のノートを熱心に読んでおらず、毎日の作業に新たな優れモノを取り入れていなかった訳ではありません。自分の誕生日 (拍手！) と、先日の Bitbucket Server のリリースを祝うため、本日は私が Git 2.x シリーズ (2.6 まで) で気に入っているフィーチャーを全てご紹介します。どれか役に立つようなことがあれば、是非ご一報ください。 リベース前に変更内容をスタッシュ Git 2.6 では、rebase コマンドが皆さんから良い意味での注目を浴びました。以下にご紹介するのは、より興味深い新しいフラグの1つです : git rebase --autostash これからは、rebase 操作の開始時に未コミットの変更内容を一時的にスタッシュするか、操作を失敗させるかを指定できます。この行
初めてGitHubリポジトリにpushしたらrejectedエラーになったときの対応メモ - Qiita
% git push origin master To https://github.com/xxxx/xxxxx.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/xxxx/xxxxx.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes
What is git tag, How to create tags & How to checkout git remote tag(s)
Let's start by explaining what a tag in git is A tag is used to label and mark a specific commit in the history. It is usually used to mark release points (eg. v1.0, etc.). Although a tag may appear similar to a branch, a tag, however, does not change. It points directly to a specific commit in the history and will not change unless explicitly updated. You will not be able to checkout the tags if
git ls-remote --heads の --headsって何だ - Qiita
git ls-remote の機能とオプションの意味がわからなかったが、わかった。(たぶん git ls-remote リモートリポジトリのコミットIDを取得する git ls-remote --heads リモートリポジトリの各ブランチの先頭コミットのIDを取得してくるっぽい git ls-remoteを叩くと、 コミットID ref/heads/ブランチ名1 コミットID ref/heads/ブランチ名2 コミットID ref/tags/.... などと返ってくるが、 こんなかから、ref/heads/のみを取ってくるのが、--heads オプション refはリファレンスのこと。 リファレンスを、紐付け、ポインター、簡易的な指定方法などと解釈するとわかりやすいかも。 コミットは長ったらしいIDで表されるが、僕らは別の方法でそれを表現する。 それがリファレンス。 リファレンスにもいくつか
まだ git push origin するときに current branch 名を入力して消耗しているの? - Qiita
毎回 BRANCH_NAME を指定する作業をしていると、日に何回も push する時は、とても多くの時間がかかってしまうことがあるかもしれません。 あと、タイトルは単に消耗しているの?って言いたかっただけです。 git push origin HEAD 下記を実行することで、カレントブランチ (git st で確認)の内容を origin に対して push できます。 詳しく git document によると1 git push origin HEAD A handy way to push the current branch to the same name on the remote カレントブランチを同じ名前でリモートに対して push する便利な方法です。 とあります。 同様の stackoverflow 2によると If you want to push a differ
Git LFS で大きいサイズのバイナリファイルも Git で管理する 🚀 - Qiita
Git LFS （Git Large File Storage） とは、Git で大きいサイズのバイナリファイル（本稿では、ラージファイルと省略して呼びます）をバージョン管理するための仕組みです。 Git はその性質から、ラージファイルを扱うにはいくつかの問題をはらんでいて、Git LFS はその問題を解決するための機能を Git の拡張として提供するものです。 本稿では Git LFS の概要紹介として、どういった問題が存在していて、どのように解決されるか、一方でどういった問題が解決されないかまでを、まとめて紹介します。 Git のラージファイル管理における問題点 まず Git LFS の背景として、ラージファイル管理における問題点を、Git の特徴を抑えつつ紹介します。 バイナリファイルの管理に不向き Git は、ソースコード（テキストファイル）のバージョン管理に特化したツールです。
Git で変更を patch ファイルにする / patch コマンドで適用する - Qiita
上記の例は patch を作成した時の階層と同じ階層で適用する場合。 -p オプションとは -p オプションは、パッチを適用するディレクトリのことを示している。 git diff コマンドで作成した patch ファイルだと、diff で表示される、変更ファイルのパスが、リポジトリ直下になる。 そのため、同じ階層にいる状態で patch を適用するときは -p0 オプションを使えば良い。 -p オプション使用例 man patch に書かれている -p の使用例が大変わかり易いので、以下翻訳しつつ引用する。 -p数字 または --strip=数字 オプションで使用する 別ディレクトリに存在するファイルにパッチを当てたいときに有効である。 以下の様なファイルの場合 /u/howard/src/blurfl/blurfl.c -p0 パス指定を変更しない /u/howard/src/blurf
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
.gitattibutes seems to be ignored for 'sql' language · Issue #3666 · github-linguist/linguist
gitで特定ファイルを特定のcommitに戻す - Qiita
How do I git rebase the first commit?
How do I get the current branch name in Git?
Move all commits to another repository
Merge git repo into branch of another repo