あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
B! 32 0 0 0 まだ余りGitで複雑な事をしてないこともあって曖昧なまま 使ってる点が多くて駄目ですが、 新しく作ったブランチをリモートに送る際に ちょっと勘違いしてた事があったのでその辺のまとめ。 リモートにブランチを送る pullしてみる リモートとの接続を調べる pullにも登録する pushするときに登録する リモートにブランチを送る 新しいブランチを送るには1 $ git push <remote repository> <branch> でリモートレポジトリに遅れてGitHubとかならウェブから見れば新しい ブランチが確認できます。 $ git clone [email protected]:rcmdnk/sentaku.git ... $ git branch -a * master remotes/origin/HEAD -> origin/master remot
ヘルスケア事業部の濱田です。チームで楽しく開発してますか? コードベースの置き場として絶大な支持を集める GitHub。コードを管理するだけでなく、issue を使って様々な議論や報告を行い、その結果をスムーズに製品に反映させることができます。エンジニアだけでなく他の職種のメンバも巻き込んで GitHub で議論ができたら、開発はもっと活発になるでしょう。 一方、 GitHub にはちょっと敷居が高い、敬遠したくなるような雰囲気を感じる人も多いようです。 本記事では、様々な職種のメンバが GitHub を気持ちよく使い始めてもらうにはどうすればよいか、という観点から気をつけるべきことを紹介します。 GitHub は非エンジニアにとっては怖い場所? エンジニアは GitHub が大好きです。自分たちの作ったコードがあり、ドキュメントがあり、仲間がおり、コードレビューを通じて自分の新たに作った
Git Advent Calendar / Jun. 6/12 担当@T_Hashです。 明日も仕事でだるいのですが、怠惰はプログラマの美徳といいます。というわけで僕が日々の仕事で怠惰にgitを使うための設定を共有したいと思います。 zsh ↓を参考にした設定を.zshrcに記述して、右プロンプトにブランチ名とステータスを表示させています。コマンドを叩かずに状態が見えて非常に便利です。 git のブランチ名 と作業状態 を zsh の右プロンプトに表示+ status に応じて色もつけてみた 緑だとクリーンな状態、赤だと未コミットの変更があります。「緑が正常な状態、緑に戻って来たら一段落してコーヒー飲もう」とか考えながら作業をしてます。 あと、zshはgitのコマンドも補完してくれるので地味に重宝します。 gst: git status git statusは常に叩くクセを付けた方がいいと
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Gitではbranch -aでリモート・リポジトリーも一覧できる。この一覧には既にリモートでは消されたリモート・リポジトリーも表示される。この一覧を更新するにはfetch --pruneを使うわけだが、いちいちそうするのは面倒くさい。どうやらfetch.pruneをtrueにするとデフォルトで--pruneを付けてfetch(及びpull)を実行してくれるようだ。 $ git config --global fetch.prune true $ git fetch From https://github.com/hail2u/example x [deleted] (none) -> origin/deleted-branch グローバルに設定して良い場合はこれで常に--prune付きでfetchとpullが実行されるようになる。この設定はプロジェクト・ローカルで特定のリモートに対してのみ
vimgrepとQuickfix知らないVimmerはちょっとこっち来い - http://qiita.com/items/0c1aff03949cb1b8fe6b こんな記事が上がっていたので、勝手に応用編を書いてみる。 まあ、以前LT等で話したことをQiitaに書き移してるだけですが。 QuickFixの拡張 QFixGrepというプラグインがあります。 これを入れていると、以下のような事が出来ます。 QuickFixバッファで選択した検索対象をプレビューして確認できる QuickFixの表示を更に絞り込んで検索 QuickFixの表示をファイル名、更新時間、内容でソートする 他にもいくつか機能がありますし、Windowsで利用するのに便利な解説などもあります。 また、以前自分のブログなどで書きましたが、qfreplaceというプラグインがあります。 QuickFixで出力されている各
空ブランチ Gitではコミットやブランチを作成する場合、必ず親を指定する必要があります。今までの歴史を全て辿れるようにするためです。 空ブランチを作成すると、今までの歴史とは全く別の新たな歴史を、同じリポジトリ内で開始することができます。 作成方法1: Github pagesの場合 Github pages ではプロジェクトサイトを作成する際にはプロジェクトのリポジトリ内で空ブランチを作成します。 空ブランチを使う理由はわかりませんが、プロジェクト本体には影響させず、リポジトリ内に同梱させるためにこの手法を採用したのだと思います。 # HEADをnew_branchに切り替える。 git symbolic-ref HEAD refs/heads/new_branch # symbolic-refを直接変更した場合はインデックスとワーキングツリーが残るので削除する rm .git/inde
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサ
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Stack Overflow for Teams is now called Stack Internal. Bring the best of human thought and AI automation together at your work. Try for free Learn more
Gitに限らず、バージョン管理システムで、コンパイルされたバイナリや、自動生成されたスクリプトを含めないというのは、プログラマの間では通念になっていると思います。それでは、デザインワークは? というとあまり扱いが統一されていません。 | コンパイル後のファイル | ソースファイル :--: | :--: | :--: ソースコード | 含めない | 含める デザインワーク | ? | ? デザインワークもコンパイルが当たり前に 従来、手作業でアプリケーションからエクスポートして、リポジトリに入れていましたが、現在その必要はほぼなくなりました。まだこの1,2年の話ですが、デザインワークでも「ソース」になる.sketchや.psdファイルから成果物を自動生成(コンパイル)するのが一般的になりつつあります。 面倒なスライスの切り出しといった作業は、もう過去の話です。一度ツールを設定してしまえば、
「Git 2.3.0」では、新たにサーバ上のレポジトリへ、直接変更をプッシュできるようになった。サーバ上における現行ブランチへの変更が、自動的に適用され、簡単にデプロイできるようになる。 ただし、この機能では変更履歴が保存される「.git」ディレクトリが作成されるとともに、変更の適用中は、ユーザーに対して変更前と変更後の混在するデータが提供される可能性があるため、利用にあたっては注意が必要となる。 さらに、リモートレポジトリをクローンする際に、すべてのデータをクローンせず、変更が行われたデータのみクローンすることを可能にしている。また、git pushコマンドのデフォルトの挙動を変更し、上流のブランチが指定されていない場合は、プッシュを行わないようにした。 シェル変数では、オプションを指定してSSH接続できるようにするGIT_SSH_COMMANDや、cronのジョブなどでGitを使用する
Hint: The following trick also works for OpenOffice, Powerpoint, Word documents (on several architectures and versions), Mathematica Notebooks and binaries like DLLs. Probably this works perfectly by default with TortoiseGit. So, you would like to check for modifications on a Word document that is version controlled with Git, right? Want to see it in a nice and convenient way like you can see on t
Stack Overflow for Teams is now called Stack Internal. Bring the best of human thought and AI automation together at your work. Try for free Learn more
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く