git clone 時に秘密鍵を指定する - Qiitagit の支援が弱くて変なやり方しかない。 => GIT_SSH_COMMAND または git -c core.sshCommand が使えます。 .ssh/config をいじる .ssh/config を１瞬いじって元に戻す、みたいな
Gitのdiffコマンドにある--exit-codeオプション - Hail2u
npmコマンドでよく書くパターンにGitで固定のファイルをステージしてコミットするというようなものがある。なんらかの処理を行うメインコマンドのpostコマンドでよくやる。まれにその固定のファイルが更新されないこともあり、その時コミットしてしまうとcommitサブコマンドが正常に(終了コード0で)終了しない。これを避けるためにはステージされることで更新があったかどうかをチェックする必要があることになる。それはdiffサブコマンドの--exit-codeオプションを使うとうまく書くことができる。 例えば更新されているかもしれないfooというファイルをステージして、更新があった場合にのみコミットしたい、とすると以下のようにコマンドをつなげれば良い。 $ git add foo && git diff --cached --exit-code --quiet || git commit --mes
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
Using Version Control Hooks — flake8 6.0.0 documentation
Using Version Control Hooks¶ Usage with the pre-commit git hooks framework¶ Flake8 can be included as a hook for pre-commit. The easiest way to get started is to add this configuration to your .pre-commit-config.yaml: - repo: https://github.com/pycqa/flake8 rev: '' # pick a git hash / tag to point to hooks: - id: flake8 See the pre-commit docs for how to customize this configuration. Checked-in py
GitHub リポジトリに git push したら Permission が denied - Qiita
よく知られていることかもしれませんが，自分への備忘録として書いておきます． GitHub (アカウント hoge) でリポジトリ ("abc") 作成: hoge/abc GitHub で以下のように提示されるとおり echo "# abc" >> README.md git init git add README.md git commit -m "first commit" git remote add origin https://github.com/hobe/abc.git git push -u origin master git push すると $ git push origin master remote: Permission to hoge/abc.git denied to fuga. fatal: unable to access 'https://github.
git stash で、作業中の変更をいったん横に退けておく ｜ Tips Note by TAM
git には、作業途中の変更をいったん横に退けておける git stash という便利な機能があります。この git stash 機能について、コマンドラインと SourceTree での操作方法を紹介します。 どんなときに便利なの 1. 割り込み作業が発生したとき なにかの作業中、急ぎで別のブランチを操作したり、サーバから pull しなきゃいけない割り込み作業が発生したりします。やりかけている変更がコミットできる状態なら、コミットしてブランチ移動なり pull なりすれば良いのですが、 まだ中途半端な状態なので、コミットはしたくない。 でも今の修正内容は捨てたくない。一時的に取っておいて、あとで戻してきたい。 そんなときに git stagh が便利です。git stash を使えば、 途中状態の変更を、stash 機能で横に退ける 作業ディレクトリは、きれいな(変更のない)状態になる
gitのコミットログの内容を修正する - Qiita
これでコメントの内容を修正して、:wqで保存して終了すれば書き換えられます。 直前以外のコミットログを修正する 例) 過去3つ分のコミットログを修正 1. 編集対象のコミットを選ぶ
Git での EB CLI の使用 - AWS Elastic Beanstalk
Elastic Beanstalk 環境を Git ブランチに関連付ける コードの各ブランチに異なる環境を関連付けることができます。ブランチをチェックアウトすると、変更は関連付けられた環境にデプロイされます。例えば、次のように入力すると、本番環境をメインラインブランチに関連付け、別の開発環境を開発ブランチに関連付けることができます。 ~/eb$ git checkout mainline ~/eb$ eb use prod ~/eb$ git checkout develop ~/eb$ eb use dev 変更のデプロイ デフォルトでは、EB CLI はコミット ID およびメッセージをそれぞれアプリケーションバージョンラベルと説明として使用して、最新のコミットを現在のブランチでデプロイします。コミットしない環境にデプロイする場合は、--staged を使用して、ステージング領域に追加
gitの改行コード自動変換でハマッた話（WindowsでもLFでチェックアウトする方法） - Qiita
わたくし、 gitの改行コード自動変換（Windows環境ならCRLFにする）というのが嫌いで リポジトリにコミットされてる改行コードのままクローンされるよう下記設定をいれてます。 core.autocrlf=false（改行コード変換しない） ある日、 とあるリポジトリをクローンしたところ 改行コードがCRLFになってる。。 てっきりCRLFでコミットされてしまってるんだなと思ったのですが、 実は下記ファイルが原因でした。 これはGitがテキストであると考えているすべてのファイルがリポジトリに>（LF）改行コードを正規化していることが保証されます。 引用（翻訳版）：http://git-scm.com/docs/gitattributes ということで、リポジトリ上は全てLFで問題なかったのです。 が、このファイルがコミットされていると、 core.autocrlfの設定を無視してCRL
phiary
phi I'm a Game Programmer and Frontend Engineer passionate about programming education. Math / C / C++ / C# / JavaScript / HTML5 / CSS3 / Python オレの Advent Calendar 2015 - Adventar の 12 日目です. git を使っていると空ディレクトリを管理したいってことよくあると思います. 一時(tmp)ファイル や ログ(log) ファイル用のディレクトリなんかがそうですね. 実は, git は空ディレクトリは add できない仕様みたいです. ですが, .gitignore を上手く使うことでそれっぽいことができるようになります. 今回はその方法を紹介したいと思います. 1. ".gitkeep" という空ファイルを配
リモートで消されたブランチが手元で残ってしまう件を解消する - Qiita
よそからcloneしてきたリポジトリでは、remotes/origin/xxxという名前でoriginのブランチが参照される。 だが、他の人がhogeブランチを削除してoriginにpushしても、既にそのブランチが手元にある人のローカルリポジトリからは普通にpullしても消えてくれない。 そういった既にリモートで削除されているブランチを消したい場合は、以下のどちらかの操作を実行すればちゃんと消えてくれる。 git fetchもしくはgit pullにpruneオプションをつける --pruneオプションをつけると、fetchやpullする際に自動的にリモートで削除されているリモートブランチを削除してくれる。
初心者向けWIPワークフロー&レビュー時の注意 - Qiita
# masterブランチに移動 git checkout master # masterブランチを最新にする git pull origin master # 新しい作業ブランチを作成 git checkout -b new_branch # 空コミットを作る git commit --allow-empty -m "[WIP] 今回開発する内容を書く" # push git push origin new_branch この後、Githubの画面に行ってpull requestを送ります。 2.タスクを洗い出す Githubのプルリクエストにタスクを積みましょう。 下記のようにコメントすればチェックリストが作れます。
git commit --allow-empty を使った WIP PR ワークフロー - Qiita
先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の（親コミットと差分がない）コミットを作成できるらしいですね。 僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。 WIP PR って何？ Work In Progress Pull Request の略です。 Github に Pull Request （以下、PR と表記）という機能があるのは皆さんご存知だと思います（知らない方はググってください）し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。 作業途中のトピックブラン
WIP PR ワークフローを実践する - \sqrt xx
WIP PR ワークフローとは 通常の開発では future ブランチを切り, commit を重ねていき, 最後に push し PR (pull request) する流れがある. しかしこれだと他の開発者に作業の状態がわかりにくい. WIP PR では PR に WIP (work in progress, 作業途中の状態) であることを明示し, [WIP] ${PR 名} で PR を出しておく. その後は定期的に push しておき, PR ページを見れば作業状態が一目で分かるようにする. 利点 他の開発者の作業状態が確認しやすい 大きい実装のとき, 実装中にレビューリクエストなどできる 実際の方法 しかし, GitHub では commit がない状態で PR を送ることはできない. commit を一度しないと PR できないというのは WIP PR ワークフローを実践する上
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS CodeCommit（プライベート Git リポジトリでのコードの保存）| AWS
git merge --squash でブランチでの変更を1コミットにまとめてマージ - Qiita
Override configured user for a single git commit
Google、「Cloud Source Repositories」正式公開。Gitベースのソースコード管理ツール、5ユーザー、50GBまで無料
GNU Mailman · GitLab
git merge のときに commit しない | Drowsy Dog's Diary
