GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。 何がまずいのか 上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。 しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin maste
Conventional Commits A specification for adding human andmachine readable meaning to commit messages Conventional Commits 1.0.0 Summary The Conventional Commits specification is a lightweight convention ontop of commit messages.It provides an easy set of rules forcreating an explicit commit history; which makesit easier to write automated tools ontop of. This convention dovetails with SemVer
緊急新人エンジニア応援企画! ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb
Fork is getting better and better day after day and we are happy to share our results with you.
Note 別の Git ベースのホスティング サービスでホストされているプロジェクトがある場合、GitHub Importer ツールを使用して、プロジェクトをGitHub に自動的にインポートできます。 詳しくは、「GitHub Importer について」をご覧ください。 元のリポジトリをリポジトリの新しいコピー ("ミラー") にプッシュするには、GitHub.com で新しいリポジトリを作成する必要があります。__ これらの例では、exampleuser/new-repository または exampleuser/mirrored はミラーです。 リポジトリをミラーする [ターミナル][ターミナル][Git Bash] を開きます。 リポジトリのベアクローンを作成します。 git clone --bare https://github.com/EXAMPLE-USER/OLD-
Git Advent Calendar / Jun. 21日目の記事を書かせて頂きます。 今回の記事では、gitのfilter-branchを紹介します。 filter-branchとは これは、大量のコミットの書き換えを機械的に行うオプションです。 (filter-branch自体はシェルスクリプトで書かれています。) これを使うとレポジトリの歴史上からコミットされたファイルを完全に抹消することができます! 今回、ファイルを抹消するためにfilter-branchの--index-filterオプションを使います。 使うシチュエーション こんな怖いオプションどこで使うのかというと、例えば下記のようなシチュエーションが考えられます。 パスワードファイルを間違ってcommitしてしまった or やんごとなき事情により削除したい 巨大なファイルを間違ってcommitしてしまった 1コミットだけ
git add -u と git add -A と git add . オプションを付けることで、まとめて登録できる。 git add -u (git add --update) バージョン管理されていて、変更があったすべてのファイルがaddされる 変更されたファイル、削除されたファイルがaddされる バージョン管理されていないファイルはaddされない 新しく作られたファイルはaddされない git add -A (git add --all) 変更があったすべてのファイルがaddされる 変更されたファイル、削除されたファイル、新しく作られたファイル、すべてがaddされる git add . カレントディレクトリ以下の、変更があったすべてのファイルがaddされる カレントディレクトリ以下の、変更されたファイル、削除されたファイル、新しく作られたファイル、すべてがaddされる git ver
Edit Git project historyGit allows you to edit your project history. This is useful when you're working on a feature branch and want to cleanit up and makeit look the way you want before you shareit with others. For example, you can edit commit messages, squash together smaller commits related to the same functionality, or split a commit that contains unrelated changes into separate commits, ad
開発速度を落とさずにどう品質を担保したのか スマホ決済「PayPay」Androidアプリ開発の裏側提供:PayPay株式会社 2020年1月16日に開催された、ヤフー株式会社主催の「BonfireAndroid #6」。第6回のテーマは「Payアプリを支える技術」ということで、さまざまな決済系アプリの開発者が集まり、知見を共有しました。今回は、イベントに登壇したPayPay株式会社前原理来氏(所属は2020年1月現在)のセッション「PayPayAndroidアプリについて」の再講演の内容をお届けします。 ※本記事内容については2020年1月16日時点の情報になります。 開発速度を落とさず品質を担保前原理来氏(以下、前原):よろしくお願いします。 始めに自己紹介をしたいと思います。名前は前原理来と申します。現在PayPay株式会社のAndroid developerをやっております。2
Conventional Commits A specification for adding human andmachine readable meaning to commit messages Conventional Commits 1.0.0-beta.2 Summary As an open-source maintainer, squash feature branches onto master and write a standardized commit message while doing so. The commit message should be structured as follows: <type>[optional scope]: <description> [optional body] [optional footer] The commit
12:04:27 AM:Error checking out submodules: Submodule 'src/lib/project' (git@github.com:owner/project.git) registered for path 'src/lib/project' Cloning into '/opt/build/repo/src/lib/project'... Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. fatal: clone of 'git@github.com:owner/project.git'
最近 xyzzy の git のを色々試してみて気づいたのでちょっと色々試した事とかを書いてみる。git で ssh を使う時の解説ページがいくつもある。ただ何故かほぼ putty を使っている。個人的にも putty を使ってたので、putty で ssh を使う人がいるのは分かるんだけど、git の場合 git bash があるから別に絶対 putty って事もないはず・・・。しかしWindows だと何故かほぼ ssh を使う時 putty を使ってる説明になっている。もしかして putty じゃないと上手くいかないのかなとか色々思ったり。 なので putty を使わないで git forwindows で ssh を試してみた。適当にやったら普通に出来た。なんでwindows だと putty の説明になっているのか分からないが、説明で見た putty を使う方法より git
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く