book.impress.co.jp 宇賀神さん、横田さん、ご出版おめでとうございます！ 元同僚である宇賀神さん(@syobochim) から頂いたので、読んだ感想を書こうと思います。 感想 タイトルに いちばんやさしい 、表紙に はじめてでも、挫折しません。 と書かれているのですが、言葉の通り、 かな 〜〜〜りやさしく 書かれています。 目次は以下の通りで、Gitがどういったものなのか、なぜ必要なのかから始まり、Gitのインストール、基本的な操作、GitHubを使った共同作業のやりかたまで書かれています。私自身は普段からGitを利用しているため、サクサク読み進めて4時間ほどで読み終えました。Gitを初めて使うという人が操作しながら読み進めても、恐らく2日はかからないで開発に参加できるようになるかな、といったボリューム感です。 Chapter 1 Gitの基本を学ぼう Chapter 2
Shallow cloneとは Gitには、shallow cloneという便利な機能があります。Shallow cloneを行うことで、最新のコミット履歴のみを取得する代わりに高速にcloneを行うことができます。 古いコミット履歴を取得しないという特性から、これは長い歴史をもつGitリポジトリに対して特に効果があります。 例: ruby/rubyをcloneする例 $ git clone --depth 1 https://github.com/ruby/ruby Cloning into 'ruby'... remote: Enumerating objects: 9894, done. remote: Counting objects: 100% (9894/9894), done. remote: Compressing objects: 100% (8679/8679), do
Latest release: v0.8.8 (release notes) Released on May 28, 2019 macOS Binary (.tar.gz) Linux Binary (.tar.gz) Source Code (.tar.gz) After installation, you should be able to execute the gl command. Gitless is licensed under MIT installation instructions | installing via package manager | previous releases About Gitless is a Git-compatible version control system, that is easy to learn and use: Simp
B! 46 0 1 0 外部から直接アクセスできないサーバーなどに 踏み台サーバーを通して一発でsshを行う設定がありますが、 Gitのsshを使ったアクセスについても同じようなことが出来ます。 sshを使ったGitアクセス 多段ssh ssh -Wオプションは使えない? まとめ sshを使ったGitアクセス Gitではコマンドラインからサーバーにいくつかの方法でアクセスすることが出来ますが、 認証を要する接続では鍵認証を使ったsshの接続が一番良く使われています。 ~/.ssh/git_rsaの様な鍵を用意しておいて、 同時に作ったgit_rsa.pubをサーバー側に登録し 以下の様な設定を~/.ssh/configに加えます。 ~/.ssh/config 1 2 3 4 Host github.com HostName github.com User git IdentityFile
今ではなくてはならないものになったGitですが、コミットメッセージの書き方に悩んだことがあります。 案件によってルールが違うこともあります。GitHubで有名なリポジトリを見ていても、そのリポジトリの対象範囲や目的などによってルールも違うように感じます。 この記事ではコミットメッセージの役割や、日本語でWebサイトを制作する僕たちはどんなルールにするのが良さそうなのかを考えます。 各ツールによって「課題」「Issue」「チケット」と呼ばれるものは「課題」と表記しています。 また、TAMではプロジェクト管理ツールのBacklogを通してGitのバージョン管理機能を使用しているため、「Gitのコミットメッセージを考える」としていますが、Subversionのような別のバージョン管理システムでも同じように考えることができると思います。 前提となる背景 Gitを使う状況を決めておきましょう。すべて
git-bug is a bug tracker that: is fully embedded in git: you only need your git repository to have a bug tracker is distributed: use your normal git remote to collaborate, push and pull your bugs! works offline: in a plane or under the sea? Keep reading and writing bugs! prevents vendor lock-in: your usual service is down or went bad? You already have a full backup. is fast: listing bugs or openin
こんにちは、フロントエンドエンジニアの万谷です。 今回は複数サービスのWebフロントエンドを運用する際のリポジトリ構成についてお話します！ 特にmonorepoかmanyrepoか悩んでいる方の助けになれば幸いです。 なお、今回出てくるリポジトリは全てWeb開発をベースにしており、その点からnpmパッケージの話が出てきますので、そのあたりは適宜読み替えていただければと思います。 はじめに スペースマーケットでは、これまでreact-railsを使った時間貸しとそのホストダッシュボードを1リポジトリで管理してきました。 そんな中2017年9月に民泊スペースを取り扱う「SPACEMARKET STAY(以下STAY)」から脱react-rails化し、Node.js+React.jsの単体のフロントエンドリポジトリが生まれ、続けて2017年11月に法人向けの「SPACEMARKET BUSIN
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
