You can connect to GitHub using the Secure Shell Protocol (SSH), which provides a secure channel over an unsecured network.
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
チーフエンジニアの @hsbt です。 今日はペパボでの日報と日報支援ツール furik について紹介します。 日報とは 日報とは、企業をはじめとする組織で様々な用途に使用されます。日々の作業の結果や記録として使われたり、チームのメンバーが考えていることや、その日その日の気分を知ることでコミュニケーションを取るための材料として使われたりします。 上記に述べた日報の使われ方は、主に自分以外の他者が参照するための用途ですが、@hsbt は日報を書きながら、何が原因で質の低い仕事をしたのか、明日良い結果を出すにはどうすればいいのか、というその日の仕事の質のふりかえりを行っています。 GitHub と日報 ペパボでは、GitHub と GitHub Enterprise を使用しています。開発者は pull request によるコードのアウトプットだけではなく、issue を用いた設計の議論、p
9/18(土) 15:30~ GitとGitHubを体験しながら身につける勉強会(名古屋) : ATND 行ってきました。 なんかいろいろと話すことになったんですけど、あの場で言いそびれたこととか、もっとこう説明してればよかったなぁ、って部分の補足も兼ねたエントリです。 長文注意。 ショートカット git add の話 git add -p/git reset -p の話 リビジョン番号がない話 ブランチの話 git-completion の話、__git_ps1 の話 コミットの指定の話 reset の話 rebase と merge の話 公開したものの rebase の話 stash の話 TortoiseGit、HG、SVNのはなし 全体を通して git add の話 Git と SVN では、add に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中
はじめに RubyのコミッターでもありRailsなどの多くのOSSで活躍されているMarc-André Lafortune さんのブログに面白い記事があったので筆を取りました. (許可は取りましたヨ) Why I Won't Squash My Commits *注釈 [...] で記された文章は原文には存在しない私の注釈であるので留意されたいです. 翻訳に至らない所があれば編集リクエスト待ってます. 要約 PR,feature単位でcommitをまとめるかどうかでRailsのプロジェクト上などで揉めた. それぞれのcommitは独立してるいるはずだからまとめる必要はない 仮にどうしてもまとめたいなら自分でやるべきだし人にその考え方を押し付けるな (まあ実際は皆いい人だから理解してくれるけど) この方は徹底してcommitを最小の変更単位で分けて、 それぞれが独立してテストを通るように心が
[Git][GitHub]Pull Request を送る手順、あるいは GPUImage for Android に PullRequest を送った話 | DevAchieve を書く際に色々調べていたら 以前導入した hub コマンドで Pull Request を送る方法があったのでまとめてみました。 hub: github/hub 導入記事: HomeBrew を zsh で使えるようにする。ついでに hub コマンドも。 参考記事: GitHubユーザーのためのhubコマンド - Qiita Pull Request したいリポジトリをクローンhub clone octocat/Spoon-Knife Cloning into 'Spoon-Knife'... remote: Reusing existing pack: 10, done. remote: Total 10 (
手が滑って `test-2` なんて情けない名前のブランチを GitHub に `push` してしまった. とりあえず,ローカルの `test-2` ブランチは, $ git branch -D test-2 で消えた.あとは GitHub の `test-2` ブランチを消すだけだ. GitHub でブランチを削除するボタンを探してみたのだが,... 見つからない.どうしよう. git push でリモートのブランチを更新 ======================================== `git push` はリモートリポジトリに変更を反映させるときによく使うコマンドだ. 通常は, $ git push だけでコマンドを実行するが,これは, $ git push プッシュ先リポジトリ ローカルのブランチ名:リモートのブランチ名 を省略した形だ.`git push` と
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
すでにgithubにリポジトリがあってローカルと関連付けられていることが前提 ローカルリポジトリにブランチを追加 $ git branch new_branch_name #ブランチを作る $ git branch #確認 * master new_branch_name githubにpush $ git push origin new_branch_name #githubのリポジトリにpush Enter passphrase for key '(ssh鍵のパス)': Total 0 (delta 0), reused 0 (delta 0) To git@github.com:user/repo.git * [new branch] new_branch_name -> new_branch_name git push origin new_branch_name ↑ ここがわから
気づくと1週間経っている恐怖(´ω`) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム(現在は3人)で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
Merge pull requests into the upstream branch, choose merge methods, and meet repository requirements like reviews or status checks. About pull request merges Merge a pull request when the proposed changes are ready and any repository requirements are satisfied. You can't merge a draft pull request. Repository rules or branch protection may require reviews, status checks, or an up-to-date branch be
Pull requests are proposals to merge code changes into a project. A pull request is GitHub's foundational collaboration feature, letting you discuss and review changes before merging them. This helps teams work together, catch issues early, and maintain code quality. View your pull requests Working with pull requests The Conversation tab of a pull request displays a description of the changes, a t
初めてやったので忘れてもいいようにメモ。 先日のZenraプラグインのためにフォークしたTermtterですが、Pull Requestするの忘れてるうちに何回かコミットされてるのと、別のプラグインを作ってみようかと思うところで、整理しておこうかというわけです。 参照:Fork a repo - GitHub Help % git remote add jugyo git://github.com/jugyo/termtter.git % git fetch % git merge jugyo/master こんだけ。簡単だね。pullでもいいみたいだしrebaseでもいいのかな?そういえばPro Gitまだ読み途中だったっけ…
A fork is a new repository that shares code and visibility settings with the original upstream repository. About forks A fork is a new repository that shares code and visibility settings with the original “upstream” repository. Forks are often used to iterate on ideas or changes before they are proposed back to the upstream repository, such as in open source projects or when a user does not have w
GitHubにはissueっていう、tracでいうticketと同じような懸案リストを登録し管理する機能があります。 今回は、このissueとファイル修正時のコミットを関連付けして、さらにハイレベルなタスク管理として利用しちゃうためのテクニックを紹介します。 issueとコミットをリンクさせる issueには以下のような感じでプロジェクトごとに固有のidが表示されています。 このIDを覚えておいて、gitでコミットする際にコミットメッセージにIDを含めてあげましょう。 $ git commi -m "#3 fixed" #3の部分がissueのIDです。#をわすれないこと。 コミットが完了すると該当するissueに以下のように自動的にコメントが追加されます。 コメントには、修正内容の差分を表示するページへのリンクも自動的に貼ってくれます。 修正内容のページでは差分を色分け表示してくれるので
/* * Copyright (C) 2014 NS Solutions Corporation * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く