（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク

GitHubのレポジトリページにはREADME.mdの内容が表示されますが、その中に画像を表示したい場合どうするのがよいでしょうか？ GitHub上にその画像をアップロードして参照できれば、ローカルや他のWebサイトで画像ファイルを管理する必要がなくなります。今回はGitHubのWikiページを利用する手順をメモします。 手順1 GitHubにレポジトリを作成します通常の手順でレポジトリを作ります。 ここでは yukisovというユーザ名で、web-sindan-crawler(.git)という名前のレポジトリを作ったとします。 手順2 このレポジトリに対するWikiレポジトリをローカルにcloneしますGitHubのWikiページは1つのレポジトリになっています。元のレポジトリ名の末尾を”.git”から”.wiki”に変えた文字列がこちらのレポジトリ名になります。 Wikiレポジトリをロ

GitLab Flow prevents the overhead of releasing, tagging, and merging to streamline development. Git simplifies branching and merging, leading software development teams to move away from other source control tools, like SVN, and adopt a workflow to simplify development. Organizations moving to Git from other version control systems may have difficulty identifying an effective workflow. GitLab Flow

git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G

ローカルブランチで開発して、むやみにマージコミットを作りたくないので毎回rebase -> mergeとやってた 毎回やるの面倒だなーと思ってたそんなとき、git pull --rebaseを見つけたんだっていうメモ pullした時の挙動が fetch -> mergeから fetch -> rebaseになるらしい いつもだとこうやってた (git stash save / popを使えばもう少し短くはなる・・・かな) (my-topic)$ git commit -am "my commit" (my-topic)$ git checkout master (master)$ git pull (master)$ git checkout my-topic (my-topic)$ git rebase master (my-topic)$ git checkout master (ma

GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe

はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは

プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する：Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）（1/2 ページ） 数回にわたってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。最終回は、GitHubが採用している、git-flowよりシンプルな構成のブランチ管理フローについてです。5つの運用ルールや開発の流れを図を交えて解説します。 本連載「Gitブランチを使いこなすgit-flow／GitHub Flow入門」では、これまでgit-flowについて解説してきました。git-flowはプロダクトを厳格にリリースすることを念頭にフローが考えられていますが、プロジェクトによっては、冗長過ぎると感じることもあるかもしれません。本連載の最終回となる今回は、git-flowに比べシンプルなブ

Gitを使ってはいるものの、しっかり理解できていないので分かりやすそうな記事などを集めました。多分同じような感覚の人は少なからずいると思うので参考になれば幸いです。 記事 【Git入門者向け】イメージで理解するGitコマンド事始め | きのこる庭 「工場」に見立てて、git init, git add, git commit, git status, git log, git branch, git checkout, git merge, git clone, git pull, git push, git fetchを解説されています。 絵がかわいくてわかりやすい。 git入門 (全22回) - プログラミングならドットインストール 説明不要、みんな大好きドットインストールの「git入門」（全22回）です。 イラストでわかる！git入門の入門 : アシアルブログ アシアルブログより「イ

いよいよ24日目の記事です。IntelliJ界のそうそうたるメンバーが寄稿される中、トリ前にも関わらず完全ステマ記事でお送りしております。 1.Tasks機能とは Tasks機能は主にチケット駆動の開発（TiDD）をサポートすることを念頭に作られた機能だと思いますが、うまく使えばTiDDな人もそうではない人もとても便利な機能です。 メジャーどころのTracやRedmineをはじめ様々なサービスに対応しており、主要なサービスは全て網羅しています。 今回はチーム開発に限らず個人の開発でも使うことの多いGitHubのIssuesと連携した例で説明します。GitHubのリポジトリに紐付いて標準で使える機能のわりに実際はあまり使われていないようにも感じますがIntelliJのTasks機能と連携することで個人の開発でもチケット駆動で便利に開発を進められますのでこれを機会にIssuesとTasks機能

About line endings Every time you press return on your keyboard you insert an invisible character called a line ending. Different operating systems handle line endings differently. When you're collaborating on projects with Git and GitHub, Git might produce unexpected results if, for example, you're working on a Windows machine, and your collaborator has made a change in macOS. You can configure G

ようこそ、サル先生のGit入門へ。 Gitをつかってバージョン管理ができるようになるために一緒に勉強していきましょう！ コースは4つ。Git初心者の方は「入門編」からどうぞ。Gitを使った事がある方は「発展編」がおすすめです。さらに「プルリクエスト編」では、コードレビューする文化をチームに根付かせましょう。 「あれ？何だっけ…？」という時は「逆引きGit」で調べて見てくださいね。