背景 2021年8月13日に、GitHubでパスワード認証が廃止されました。 そのため、Personal access tokensを利用しないとSourceTreeから push/pull ができなくなります。 ※pushした場合下記のようなエラーが表示されます。 git --no-optional-locks -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags origin refs/heads/main:refs/heads/main Pushing to https://github.com/****/****
GitHub Actionsを使ってXServerなどレンタルサーバーに自動デプロイしよう🙌 公開日 : 2021.12.10 最終更新日 : 2023.08.28 コーディング こんにちは、AndHAコーディング部です。 前回の記事ではSourceTreeを使ってコミット間の差分ファイルを出力する方法を紹介しました。 SourceTreeを使ってコミット間の差分ファイルを出力してみよう🥳 | 【運用・改善が得意な仙台のホームページ制作会社】AndHA(アンドエイチエー) リモートリポジトリをGithubに指定している場合、Github Actionを利用しワークフローを自動化することが出来ます。 Actions | GitHub 今回はよく使われるであろうエックスサーバーに対し、GitHub Actionsを使った自動デプロイを紹介します。 ※Mac(macOS 12.0.1)環境で
This topic illustrates how to avoid adding unwanted files (or file changes) in a Git repo. There are several ways (global or local .gitignore, .git/exclude, git update-index --assume-unchanged, and git update-index --skip-tree), but keep in mind Git is managing content, which means: ignoring actually ignores a folder content (i.e. files). An empty folder would be ignored by default, since it canno
[概要] GitHubのアカウントを作成したので、自身のMacBook Proからssh接続できるように公開鍵設定を行う。 公開鍵とは 公開鍵と秘密鍵の2つを用意して、通信を行う。 公開鍵は、暗号化するためだけに使うので、人にバレても通信の中身がバレることはない。 復号化するには、秘密鍵でしかできない。 * 公開鍵:暗号化するのに使用(中身がバレても影響は、ほぼなし) * 秘密鍵:復号するのに使用(中身がバレるとかなりやばいので、絶対外部に漏らしてはいけない) 参考サイト お前らのSSH Keysの作り方は間違っている Generating SSH keys [事前準備] GitHubのアカウントは作っておくこと。 [作業内容] 鍵作成 セキュリティを考えて、暗号化強度を強く暗号化強度を4096にして作成しています。 お前らのSSH Keysの作り方は間違っていると公式ドキュメントに乗っ取
GitHubのHelpに記述されているSSH Keysの作成方法が僕の知っている作成方法と 微妙に異なっていたので、書いてみました。 以下の参考にしています。 Generating SSH keys - User Documentation SSH Keysの確認 既存のSSH Keysの確認をする必要があるので、以下を実行 デフォルトでのSSH Keysの名前は以下のうちのどれか id_dsa.pub id_ecdsa.pub id_ed25519.pub id_rsa.pub 現在使用している鍵の暗号強度の確認 以下のコマンドにて鍵長が2048以上かつ暗号化方式がRSA、或いはECDSAやEd25519であればOK $ ssh-keygen -l -f ~/.ssh/id_rsa.pub 4096 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
追記:たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記2(2011/11/07):commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ | ├─ 一人で使ってるよ | | | ├─ 手元に変更を取り戻したいよ(1)(そうだね、add忘れだね派) | |
「Git」使ってますか? 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
こんにちは、中川です。 Gitを使い始めてから、Subversionを使う機会がめっきり減ったこの頃です。 Gitだとローカルだけで簡単に使い始められるのもいいですが、気軽につくれるbranchや、mergeのしやすさがたまりませんね。 インストール直後の状態でも普通に利用できますが、 ちょっとした設定でさらに使いやすくなる方法をご紹介したいと思います。 ※今回ご紹介する内容はいずれも私のMacBook上での動作確認となり、Windows環境は考慮していませんがご容赦ください。 ■ユーザー名とE-mailアドレスの設定 まずは、最初にユーザ名と、メールアドレスを設定してしまいましょう。 $ git config --global user.name "yoshiki" $ git config --global user.email "yoshiki@example.com"
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います: ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github(や噂のgitosis)に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く