< 最新 変更履歴 - Latest Changed History > 2019.06.05 - コマンド記事へ追加 『 Linuxコマンドを連続して使うには - @egawa_kun 』 このページをご覧くださった方は、資料探しで悩む"気疲れ"と"時間"を大幅に減らし、かなり効率的に早くGit/GitHubを学習できるでしょう。 背景 なぜ今更 Git/GitHub という感がありますが、まとめてみました。何故かというと、ググると確かに初心者向けのGitの使い方や設定方法などが掲載されたサイトは多くありますが、個人的に体系立ってイメージを掴める内容が少なく、探すのに苦労したため、その中から特に役立ったと感じたコンテンツをかなり厳選し、まとめてみました。下記の良質なコンテンツは、Git/GitHub習得に大いに役立つでしょう。 初心者〜 さらに初心者用の資料もレベル別に番号順で分けました
社内向けにterraformモジュールを共有したかった。 TerraformCloudは使わせて貰えなさそうだった。 gitでがんばることにした。 どうやってやるか git の submodule という機能を使うことにした。 システム全体を定義したgitリポジトリの中にモジュールgitリポジトリをネストする構成を作る。 submoduleを使うにあたって、昔は色々設定が必要だったみたいだけど、いまは1コマンドを実行するだけ。cloneと同じ感覚で使える。 リポジトリ内のディレクトリ構成 モジュールディレクトリ(リポジトリ) 以下の通り作成する。 この中でmodulesディレクトリを作ると使う時に深くなるので、いきなりモジュールが露出するようにする。 $ tree tfm-network/ . ├── README.md ├── vpc/ │ ├── main.tf │ ├── varia
この画像は本文とは関係ありません。 こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 みなさん、git submodule コマンドは好きですか?git submodule は特定の状況下では便利なコマンドです。 社内アンケートでも25%が怖いという結果に しかし、なぜか世間にはgit submodule が怖いという人が相当数いるようです。推測ですが、git submodule は動作モデルや使用手順が誤解されがちなところがあり、それで「怖い」と思われているのないでしょうか。git 本体でも昔そんなことがありましたよね。 この記事では git submodule の誤解を解き、適切な使い方を解説します。また、記事の最後にチートシートをつけます。 git submoduleはトモダチ!怖くないよ! git submodule って何? 誤解1 「プロジェクトが大きくなっ
最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。 梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。 $ git pull warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebas
今までサーバー内に入ってgit pullしてデプロイメントをしていたんだけれど、とても21世紀とは思えないのでcapistranoを導入しました。ついでにロードバランサーを設けてアプリケーションサーバー2台の構成にしてみたんですがssh-key周りが気になりました。 これまでサーバ内でssh-keygenして公開鍵をgithubのdeploy_keyに置いていたんだけどこの方法だとサーバ台数が増える度にgithub上の公開鍵の数も増えていくし管理もクソもあったもんではないと思いググっていたらどうやらssh-agentという方法があるらしい。 ssh-agentを使用すると、capistranoコマンドを叩く開発者のssh-keyを使ってデプロイをしてくれる。 まずcapistranoのコードは以下のようになる。 server '○○○.×××.○○.××', user: "hogehoge
はじめに こんにちは!nanapiデザイナーのyunicoです!「Git Advent Calendar 2014」の15日目を担当します(^o^) 今年はなんか色々GitGit言っていた年だったので、最後にアドベントカレンダーに参加しちゃいます!わいわい!去年からすると、まさか一年後にGitのアドベントカレンダーに参加しているとは思いもよりませんでした〜。感慨深いものです!よろしくお願いします<(_ _)> 前置きと今年やったことまとめ TechBlogでGitについて書いた nanapi勉強会でTL GithubKaigiでTL PatchworkTokyoでメンター< Gitが大好きになった♡というブログを書いたら色々ご縁があり、3回ほど登壇しました(╹◡╹) nanapi勉強会vol.2では「 GUIじゃなくてターミナルからコマンドでGit使うと便利!」という話、GithubK
通常、addしたファイルを取り消したい時は、git reset HEADでファイルを指定する。 しかし、addしたファイルを戻すつもりが間違って git reset --soft HEAD^をしてしまい、HEADが一つ前に戻ってしまった。 つまり、特に変更点も無いままHEADを一つ前に戻したため、過去の内容が自分のステージングに残ってしまったのである。 Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: app/assets/stylesheets/test.sass #最新(HEAD)のファイル modified: app/assets/stylesheets/hoge.sass #最新(HEAD)のファイル modified: app/assets/stylesheets/fuga
ツイッタフォローしてやで(ボソッ https://twitter.com/JotaroUT いろいろ使ってみたけどGitUp、やめられませんでした。 Macbookをスタバで開いてはプロジェクトをgitで管理する機会の多いであろう諸兄・諸姉のために、独断でイケてるなと思ったgitのGUIクライアントについて紹介したい。その名もGitUp。 GitUp : http://gitup.co/ GitUpとは GitUpはmacOS用に開発されたgitのGUIクライアントである。 公式ホームページに、 Work quickly, safely, and without headaches. とあるように、確かに使っている間は頭痛がしない気がする。大きな特徴としては、謳い文句の通り、 早い。 ざっくりした使い方 コミットを参照する。 ここでは、openFrameworks (https://op
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model(上記は翻訳記事)を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
人に見せたくないソースコードというのは星の数ほどあります。(例えばパスワードを含むサーバの設定ファイルをGitで管理している、とか) こういう時に非公開のGitサーバがあれば良いのですが、サービスとして提供されている物ではprivateリポジトリが作れなかったりしますし、そもそも他人が管理しているサーバなので100%の信用は出来ません。 もっと自由に使えて、信用できる、すなわち自分の管理しているサーバにインストール出来るOSSのGitサーバをいくつか比較してみます。 Gitサーバ、どれが良い? 世の中にはGitHubなんてものがありましてね……WebからGitをポチポチ出来る。 これが案外便利でして、Webだけでリポジトリが作成出来る。 前まではGitoliteとRedmineを組み合わせていたのですが、このWebからの……が出来なくて面倒になってしまい思ったほど使いこなせていません。 と
windows環境で git を使っていて、改行コードが意図しないものになってしまっていたことがあり、git for windows には改行コードの自動変換というものの存在に気づきました。 git のインストーラーのデフォルト設定では、この自動変換がONになっているので、備忘録のためにおさらい。 git for windows(msysgit) のインストール 最新版のダウンロード ⇒ git for windows インストールの詳細については以下を参照。 ⇒ 私家版 Git For Windowsのインストール手順 ⇒ WindowsにGitをインストールする手順について このインストーラーでデフォルト設定でインストールしていくと、改行コードの自動変換がONになっているので注意! (1) Select Components ⇒ デフォルトでOK (2) Adjusting your
綺麗にコミットしてますか?? はじめまして!Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何? Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう? $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ(master)にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
Git で特定のリモートブランチ (を追跡するローカルブランチ) を checkout してくるためには以下のような -b オプションを付けた git-checkout コマンドを使うと思っていました。 git checkout -b features/hoge origin/features/hoge しかしこれでは features/hoge を何度も入力しなくてはいけませんし、とてもめんどくさいのです。というわけで man git-checkout を眺めていたら --track (-t) というオプションを見つけました。 -t, --track When creating a new branch, set up "upstream" configuration. See "--track" in git-branch(1) for details. If no -b option
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く