Windows環境でのgitまとめ(2016.1)
※ 本スライドの内容を解説した、電子書籍を販売中です。 <a>http://p.booklog.jp/book/86773</a> 「Git（ギット）」や「バージョン管理」という言葉は聞いたことはあっても、なんだか難しそうなイメージを持っているかも知れません。 特に、プログラマーやエンジニアのツールであって、デザイナー・マークアップエンジニア・ディレクターの方は「自分には無縁」と思っているのではないでしょうか。 しかし、Gitはプロジェクトに関わるすべての方が使えると、コミュニケーションツールとしての役割も果たし、非常にスムーズにプロジェクトを進行させることができます。 このイベントでは「ノンプログラマの方」を対象に、Gitのよく使う部分だけをピックアップしてわかりやすく紹介、今日から使えるテクニックや便利なポイントを紹介していきます。
サーバの/etcを自動的にGitとかにコミットとかプッシュしてくれるetckeeperを使う - Qiita
はじめに インフラを担当しています。 一人が管理できるホストには限りがあるなと思っていて、補助ツールがなければ10台ぐらいが精一杯かと思っています。 補助ツールを使うことで100台ぐらいまでは行けるんじゃないかと思っていて、そのためのツールを探していました。 普段のサーバ管理でやっていることを書いてみます。 チューニングなどでconfの調整 過去に他のホストで導入した設定の適用 バックアップと復元、移設 これらはetcを管理することで実現できそうですね。 過去にはSubversionを使って手作業で管理していましたが、この辺りを(半)自動化してくれるetckeeperというツールがあるということで試してみました。 インストールと初期設定 yumにもaptにもあります。 CentOSの場合にはepelを入れておきます。
git push -f を捨てよ、--force-with-leaseを使おう - ちぎっては投げるブログ
japan.blogs.atlassian.com そもそもforceで上書きするなという話もあるが、master/develop以外の作業ブランチでは、developにマージリクエストを出す前に、すでにpushしているコミットを綺麗にrebaseするためにpush forceすることはある。 最初から綺麗なコミット単位のみをpush出来ればいいのだが、翌日急に休んだときに誰かが引き継げるようにとか、ローカルのデータが吹っ飛ぶ可能性を考えてバックアップの意味でpushするとか、諸々の理由をつけて作業がきちんと完結していない状態でpushすることもある。もちろん、そんなことをするのは作業ブランチ限定で、developやmasterには仮コミットはpushしてはいけないし、あとで消す仮コミットであることがわかるようにコミットログを書いておくのが良いと思う。 そうしたわけで、push -fをする
git push `--force-with-lease`はいつも安全？ - Qiita
git push --force-with-leaseはgit push --forceと違って、他の人がpushしていたら良い感じにコケてくれるので安全、という話を聞き、さっそく使っています。 git push --force でなく git push --force-with-lease を使う - valid,invalid --force considered harmful; understanding git's --force-with-lease - Atlassian Developers ただ、ちょっとだけ注意しないとな、と思ったところがあるので書き残しておきます。 前提 git 2.6.4で確認 最後にfetchしたタイミングでの一致を保証する man git-pushを見るとこんな記述があります。 --force-with-lease alone, without
gitロググラフを綺麗にするちょっとした技【基本編】 - Qiita
gitログは綺麗に ロググラフがごちゃごちゃしていると、履歴を追う時に心が折れます git flowで開発をしていると、分岐するのは仕方が無い時もあるのですが、明らかに必要ないのに分岐させている人をよく見ます。 チリも積もると全く読めない（読みたくない）グラフになってしまうので、必要ない分岐はさせないに越したことはありません。 頻繁に分岐が発生するパターン チームで開発をしていると、「pushしようとしたら他の人が先にpushしていた」ということが頻繁に発生します。 まだgit経験が浅い人は、ここで分岐させてしまいます。 発生例 例えば、グラフがこの状態にあるとします。 commit2（f9b26f3）に対して、修正点をcommitして、pushしようとします。 (master)$ git add . (master)$ git commit -m 'commit 4' (master)$
新人さんにより良いコミットメッセージを書いてもらうための対話式スクリプト - Qiita
作ったもの コミット時に対話式で質問を表示させるものをつくりました。 ↓こんな感じ↓ 回答の内容をつなげたものがコミットメッセージになります。 質問リストは別のファイルで自由に設定できるので、 チーム内でコミットメッセージへ書いて欲しい内容をゆるく共有したい場合に。 How to use スクリプト本体はこちら #!/bin/sh set -e # core.editorに設定したいもの # merge,rebaseなどの時に起動する CORE_EDITOR=vi # commitじゃなかった場合(mergeとかrebaseとか)の場合はCORE_EDITORに渡す if [[ ! "$1" = *COMMIT_EDITMSG ]]; then $CORE_EDITOR $1 exit 0 fi CURRENT_DIR=$(cd $(dirname $0); pwd) MSGLIST_FI
Squash your commits | The GitHub Blog
ProductSquash your commitsGit’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the… Git’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the merge button on GitHub only created merge com
「Git 2.8.0」がリリース、submodulesの並列フェッチが可能に
「Git 2.8.0」では、新機能としてsubmodulesの並列フェッチが可能になる。submodulesは、他のレポジトリをレポジトリのサブディレクトリのように使える機能で、プロジェクトへのライブラリや外部の依存関係の統合に便利。しかし、多数のsubmodulesがある場合フェッチに時間がかかるが、今回の新機能により実行時間が短縮される。 また、.gitconfigでユーザー名とメールアドレスを指定している場合、.gitconfigの指定と異なるユーザー名やメールアドレスでコミットした際に、警告は表示されるものの、コミット自体は実行されてしまうが、「Git 2.8.0」では異なるユーザー名やメールアドレスでのコミットを禁止する設定が追加された。 さらに、今回のリリースではGit for Windowsプロジェクトにおける成果の還元によって、プラットフォームにまたがる新機能の追加を行いや
[Git] 10分で使いはじめるTig（コミット操作を早くする） - Qiita
はじめに 私は普段 Tig（てぃぐ）を使っているのですが、どうも Tig の知名度は意外と低いようです。そして噂に聞いて使い始めても、とっつきづらいなどの理由でやめちゃう人も多いようです。 しかし、最初の壁さえ乗り越えてしまえば、Tigは便利なGitツールとして自身のツールボックスに加えられると思います。 実際に私の経験として、同僚に10分くらいで Tig のインストールから基本操作をレクチャーをしたところ 「Tigめっちゃ便利や・・・！」 という感想を頂いたこともあります。 概要 本記事では、Tigを使うモチベーションからインストール、まず覚えるべき「コミット操作」について書いています。 すなわち私が同僚にしたレクチャーの追体験です。 ターミナルにテーマを設定しているため、スクリーンショットがお使いの環境と異なる方が多いと思いますがご容赦ください モチベーション Gitのコミット操作（ス
![[Git] 10分で使いはじめるTig（コミット操作を早くする） - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/42982da11a850f206388076511af5a47577b13c2/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCR2l0JTVEJTIwMTAlRTUlODglODYlRTMlODElQTclRTQlQkQlQkYlRTMlODElODQlRTMlODElQUYlRTMlODElOTglRTMlODIlODElRTMlODIlOEJUaWclRUYlQkMlODglRTMlODIlQjMlRTMlODMlOUYlRTMlODMlODMlRTMlODMlODglRTYlOTMlOEQlRTQlQkQlOUMlRTMlODIlOTIlRTYlOTclQTklRTMlODElOEYlRTMlODElOTklRTMlODIlOEIlRUYlQkMlODkmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWIzMTY1MjBjNjE1MDU3MDBkYzMxM2I1NTc4NGQzNmMw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBZdXN1a2VIb3NvbnVtYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZWYzODk2N2FkZTQ2MzQzOGU3YTQzMDgxZmMxYmU3ZTg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D108e86eb2f5552a71bda3460d4b9952f)
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
Gitでファイルの実行権限を変更する - Qiita
WindowsとLinuxをまたがって、スクリプトファイルを編集する場合のTips。 Linux系の場合、ファイルシステム上でファイル実行権限を変更する(chmod）と、Gitが「ファイルが変更された」と認識する。 そのため通常の変更と同じく、git add 、git commitでファイルアクセス権をリポジトリに反映できる。 Windowsでアクセス権を変更したい場合は、下記のようなGitコマンドを使う。 実行権限を付与するとき $ git update-index --add --chmod=+x [filename] 実行権限を外すとき $ git update-index --add --chmod=-x [filename] なお、config設定で「ファイル権限設定を無視する」というオプションがあるため、注意。 $ git config -l |grep filemode
突撃となりのエイリアス(Zsh, Git編) - Misoca開発者ブログ
こんにちは。 もうすぐお花見の時期*1ですね。Misoca開発チームのtaiki-tです。 開発チームに聞いたところ、人によってエイリアスの設定に違いがあったので、比べてみました。 対象はZshとGitの設定です。 ちなみに、この間インターンの方の送別会と打ち上げ的なものがあって楽しかったです。 写真: 「commit -m '開発チームと愉快な仲間たちの巻'」 Zsh編 ls たかがls されどls。 lsのエイリアスにも様々なものがあります。 よく使うオプションと合わせてエイリアスにしているようです。 alias la='ls -a' # dot(.)で始まるディレクトリ、ファイルも表示 alias la='ls -al' # -a オプションと -l オプションの組み合わせ alias ll='ls -lav' alias ll='ls -l' # ファイルの詳細も表示 alias
git: 独りで使うgit入門 - type t (* void *)
この時期大学四年生は卒論の時期で、今まで論文やサーベイだったのが 自分で手を動かすフェイズになっていることでしょう。 その際にバックアップというのは重要になります。 例えば研究用のソースコードを改造していく途中でプログラムを壊してしまって 元に戻したい、別に実装を試してみたくなる場合というのはあると思います。 また壊しても元に戻せるという安心感があればガンガンプログラムを変えていくことができます。 証明や卒論のtexファイルも同様に管理できます。 その際に使えるgitというバージョン管理ソフトの使い方を紹介します。 gitのことはどこかで聞いたことがあるでしょうが、 特にこの記事では一人で使う場合に特化して、手っ取り早く卒研に使えるように説明を絞ります。 (gitは多くのプログラマが使っている道具なので、他の使い方は調べれば簡単にわかるでしょう) gitでできること 一人での作業で有用なと
git fetch の裏側では何が起こっているか - 詩と創作・思索のひろば
git fetch の裏側でどんな通信が行われてリモートリポジトリの内容が取得できるのか調べたのでまとめる。もともとは git の HTTP や SSH といったプロトコルでどのように実現されているか、というところに興味があった。Git v2.7.1 を基にしている。 事前準備 pack プロトコル pkt-line フォーマット Reference discovery Packfile negotiation Packfile の送受信 packfile への圧縮・packfile からの展開 各種トランスポートの実装 file トランスポート ssh トランスポート git トランスポート http(s) トランスポート まとめ 参考資料 事前準備 手を動かしてプロトコルを理解できるよう、gist の小さなリポジトリ を使う。適当なディレクトリ下に bare リポジトリとして clon
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git branch -aが驚くほど見やすくなる小技 - Qiita
https://qiita.com/yudaifuijta0121/items/72e3759d55c4997d8c0b
分散型バージョン管理システム「Git for Windows」v2.8.0が公開、1件の脆弱性を修正
クロスプラットフォーム対応の無償Gitクライアント「Axosoft GitKraken」が正式版に
シェル統合型「Git」クライアント「TortoiseGit」がv2.0.0に
Gitを一度はあきらめた人のためのわかりやすいスライド９選
