イケてると思う dotfiles の管理方法 - KMC活動ブログ
イケてると思う dotfiles の管理方法 この記事は、今年もやります！KMCアドベントカレンダー！！ - KMC活動ブログの21日目の記事です。 昨日の20日目の記事はReturn Value Optimization (RVO)の話 【KMCアドベントカレンダー20日目】 - KMC活動ブログでした。 KMC5回生の wacky です。今日は dotfiles の管理方法についての話をします。 dotfiles を管理していないと 何らかの UNIX を長いこと使っていると、ホームディレクトリには自分の書いた .zshrc や .tmux.conf などの設定ファイルがたくさん転がっていると思います。そして、長いこと UNIX を使っている人であれば、自分が単一のサーバにしかログインしない、というのは稀でしょう。当然、自分のログインするサーバ全てのホームディレクトリには .zshrc
[ポエム][社内実習向けメモ書き]git rebase道場 - Qiita
非常に個人的なことですが、最近チーム内でrebaseの必要性が増しています。 なのでチーム内講習のためのプロットとしてここに説明することをまとめます。 主目的はチーム内での説明なので、記述にはチーム固有の事情やチームメンバーへの説明を前提としたものなどが一部あります。 なんのためのrebase rebaseをする理由・メリットはいろいろありますがうちのチームに限定すれば目的はほぼ一つです。 その目的はpull requestによるレビューをしやすくすること。 pull requestによるレビューはその性質上レビューによる指摘点を追加のコミットで行うことが多いですが、 この追加コミットは本来それまでにレビューしてもらったコミットへ含めるべきものであることが多いです。 例えば 適切でない変数名 よりベターなロジック記述の仕方 コメント中の誤字・脱字修正 などはすべてそれまでに見てもらったコミ
![[ポエム][社内実習向けメモ書き]git rebase道場 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/1d71730057b7c17d011fdd68747c4fd6479ff2d8/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgzJTlEJUUzJTgyJUE4JUUzJTgzJUEwJTVEJTVCJUU3JUE0JUJFJUU1JTg2JTg1JUU1JUFFJTlGJUU3JUJGJTkyJUU1JTkwJTkxJUUzJTgxJTkxJUUzJTgzJUExJUUzJTgzJUEyJUU2JTlCJUI4JUUzJTgxJThEJTVEZ2l0JTIwcmViYXNlJUU5JTgxJTkzJUU1JUEwJUI0JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz00OThlYmVmOWRjM2Y0NzQ5ODc2YTRjOGNmYzlmNmJiZQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBiaWd3aGVlbCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YWQ1MGU3YjRiOWRjOTFkMjI0ZjM4NTBkZTI2NTY3Zjg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Ddd357bf3c54fc2a3f1a8ac471dbd2f96)
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
Git - 最初のGitの構成
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
SubversionからGitへの移行でチーム影響を最小限にする - Qiita
この記事は株式会社リクルートテクノロジーズ Advent Calendar 2014の15日目の記事です。 Git移行は面倒？ 管理の煩わしさや並行開発の難しさという点から、ソースコード管理システムをSubversionからGitへ移行したいということはよくあると思います。 1つのリポジトリに関わっているエンジニアが5名程度のチームであれば、エンジニア同士で相談してサクッと移行できるかもしれません。 しかし実際には1つのプロダクトに5名以上のエンジニアがいて、並行して小さな変更の開発と大きな変更の開発を同時に行っている場合も多いのではないでしょうか。 例えば以下の図のように、短期間でリリースできる修正と、長期間かかる修正とで複数の開発チームが並行して動いている場合です。 このような場合はどこかでGit移行のタイミングをつくらなければならず、開発への影響を考えるとすぐには移行できないという状
Git入門：Git初学習者のための効率的な学習方法を考えてみた
本記事は，Git Advent Calendar 2014の13日目に投稿させて頂いた記事です． モチベーション 自分を成長させながらいかに効率的に技術を伝承するかが自分の中で課題になっており模索中なこの頃．試しに，社内でGitを使ったことのないエンジニアに1週間(合計7時間)で開発に必要なGitの知識を講義したので，その時に使用した教材や効率的な学習方法を初心者向けに共有する． 背景 一昔前はイケてるエンジニアはGitを使ってプログラムを管理してるみたいな感じだったが，今となってはGitはエンジニアにとって必要不可欠なツールになった．Gitがあるからコードの2重管理はなくなり，Gitがあるから継続的インテグレーションや継続的デリバリーが活きる，Gitがあるから変更に対してコメントを残せる．Gitが無いと開発が成り立たなくなって来ているのだ．特に，Githubのヒット以降，その流れは加速し
Linux ユーザーのための Git と Github 入門
原文はこちらです。 ※この記事は「チュートリアル」からの転載です。 Git は、Subversion、CVS、Mercurial などのバージョン管理システムから移行するのに最適な分散管理システムです。複数の開発者が同時に 1 つのプロジェクトに貢献していて修正量が膨大な時に有効な道具です。無料の Github を使って git 入門をしましょう。 git は、他のバージョン管理システムとは考え方が異なります。昔の RCS はファイルの変更履歴を取得しており、その内容は、コンフィギュレーション ファイルを見るとわかるようになっていました。Git は、もっとファイル システムのスナップショットに似た発想でできています。すべてのコミットや状態は、完全なスナップショットの形で格納され、従来の差分ファイルは存在しません。Git はスナップショット間の変更のみを記録し、変更がないファイルはリンクする
最新のGitで2014年を振り返る、ver2.0-ver2.2 までの注目すべき変更点 - Qiita
はい、2014年も終わるということで。最新版の2.2を含んだ2.0 ~ 2.2で追加された注目機能をいくつか紹介したいと思います。なんといっても今年はメジャーバージョンアップのあった年ですからね。 2.0:git push のデフォルトオプションの変更 これは2.0の有名な変更点ですね。matching から simple に変更されました。ちょっとわかりにくい部分だと思うので詳しく説明します。 ※ちなみに自分はそのどちらでもない nothing を利用しています。 matching 今までのデフォルト、ローカルとリモートのブランチ名が同一であればすべてがpush対象 というものです。昔からgit使っている人は、「そのブランチpushしたかった訳じゃないんだよ！」という苦い思い出がある方もいるのではないでしょうかｗ upstream simpleを説明するためには、これを説明したほうがいい
Gitの中身を見てみよう！vol.1 – 配管（Plumbing）と磁器（Porcelain）(Advent Calendar 9日目)
Gitの中身を見てみよう！vol.1 – 配管（Plumbing）と磁器（Porcelain）(Advent Calendar 9日目) こんにちは。アドベントカレンダー9日目を担当する佐藤（ま）です。 アライドでは「大佐」と呼ばれております。 今回から git-scm.com をみながら Git (.git) の中身をみていってみようと思います。（まぁ他にもいろいろ記事はありますが書きたかったので気にせず垂れ流していこうと思います。）現在の Document には、v1 と v2 がありますが、v2 は途中まで日本語化されていて、日本語で見たい方はこちらに参考サイトがあります。（もちろん英語のままでもだいじょうぶですが） そもそも Git には大きく配管（Plumbing）コマンドと磁器（Porcelain）コマンドがあり、普段良く使うコマンドは、ユーザフレンドリーなコマンドとして、磁器
Gitの便利な-pオプション四兄弟 - エンジニアをリングする
この記事はGit Advent Calendar 2014の6日目の記事です！ （更新がお昼になってしまいました、ごめんなさい＞＜） みなさん！ Gitの-pオプション使ってますか？ 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します！ 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね！ 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
ドリコムの開発を支えるGitリポジトリ - gussan
はじめに これは ドリコム Advent Calendar 2014 の5日目です。 4日目は、@ka_nipan さんによる ドリコムを支えるデータ分析基盤 です。 自己紹介 @gussan ドリコム歴は10年になります。 アーキテクチャ設計、ミドルウェア・ライブラリ及び社内ツールの開発運用等を担当しています。 本日の話 2年前の12月、メインのソースコードリポジトリをSubversionからGitLabへ移行しました。 本日はGitLabへの移行と運用の話をします。 GitLabに決めた理由 選択肢としてはGitLab, GH:E, Stash等がありました。 メインの機能はどれも十分な機能を有していましたが、 GitLabを選んだ主な理由としては以下の3つです。 継続的にメンテナンス・リリースがなされている 社内にある技術で運用可能である(Rails, MySQL, Redis) も
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
Git 作業における commit と push の頻度について - Qiita
注意 この記事は、2014年に投稿されたものです。 時代は変わっても運用におけるベースは大きくは変わっていませんが、投稿としては古い内容ですのでご注意下さい。 未だにストックなど多くいただきますので注意事項として、追記させていだきます。 以下本文です。 はい、今更かもしれませんが。俺としてはGitを扱う上で結構重要だと思っている commitやpushの頻度 について書きたいと思います。はじめに断っておきますが技術的なテクとかの話ではないです。ほとんどが 言われてみれば当たり前じゃん 程度の内容だと思って下さい。 ですが、flowとか運用方法 とか gitを使いこなすちょっとしたテク なんかより重要だと思っているのは俺だけでしょうか...？ どの単位でコミットしたりプッシュしていますか？ みなさん、どのような単位でコミットしたりするようにしていますか？未だに 適当にやってる みたいな人がい
How to use git-ftp
最近「寺子屋」と称して個人レッスンというか、数名規模の私塾みたいなことをやっているこもりです。こんにちは。 寺子屋については年が明けてからあらためてお知らせするとして、寺子屋の参加者の皆さんの間などでよく「Gitは使ってるんだけど、アップロード先がFTPしかだめで…。どうにかなりませんかね？」みたいな質問を受けることがあります。もったいないですね。手元は効率化できてるのに、最後の最後がそれじゃ。 アップロード先がFTP（とかSFTP）しか使えない場合は、「dploy.io」とか「Deploy」みたいにGitHubとかBitBucket、自分のリモートのリポジトリからデプロイだけやってくれるサービスを使ったり、むしろその辺も一緒くたになった「Beanstalk」みたいなのを使うと簡単なのですが、いかんせんそれなりにお金はかかります（その辺の話はここに書いてます）。 dploy.io – Co
初心者がプルリクまでに覚えるべきたった 9つの厳選 Gitコマンド - akiyoko blog
この投稿は 「Git Advent Calendar 2014 - Qiita」 の 2日目の記事です。 2年前の 「Git Advent Calendar 2012 - Qiita」 では、「Gitコマンド総選挙」と題して、本当に使える Git コマンドのベストテン発表というネタを書いたのですが、今振り返ってみても、Git コマンドって、よく使うものから普段あまり使わないものまで様々なコマンドが取り揃えられていて至れり尽くせり感がある一方で、Git 初心者が覚えるにはぶっちゃけ 数が多過ぎて辛い ですよね。 そこで今回は、Git 初心者がプルリクできる ようになるまでに覚えるべきコマンドを絞りに絞って、9つだけ紹介したいと思います（9つでも多いよ！というツッコミは受け付けません！）。 【コマンド その１】 git clone 【コマンド その２】 git log 【コマンド その３】 g
Jenkins/GitLab でデプロイツールを作る | iret.media
こんにちは、cloudpack の 田村です。 【お題】下記条件を満たしたデプロイツールを作成せよ インスタンスの増減に対応 ロールバックが可能 既存のデプロイツール(rsync)と融合 複数システムで使用 「SVN+Capistrano」のデプロイツールは実績があるものの下記課題があるため作り直す。 バージョン管理でconflictすると面倒くさい デプロイ実行履歴がログからしか分からない デプロイしたコンテンツの差分がコマンドからしか分からない 世間的にお手製のツールは信頼性が低い バージョン管理でconflictすると面倒くさい問題 →コマンド実行するサーバを絞る デプロイ実行履歴がログからしか分からない問題 →Jenkinsで見やすく デプロイしたコンテンツの差分がコマンドからしか分からない問題 →GitLabで見やすく 世間的にお手製のツールは信頼性が低い問題 →オープンソースを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - takanabe/introduction-to-git: https://github.com/Shinpeim/introduction-to-gitに各章で利用するレポジトリを追加したものです。
ブランチの構成を保ったままrebaseする - Qiita
［初心者向け］こんなときどうする⁉︎ GitのTips31選！ - Qiita
8号购彩安全检测...