| Jan | FEB | Mar |
| 17 | ||
| 2015 | 2016 | 2017 |
COLLECTED BY
Collection: Live Web Proxy Crawls
bleikamp
●
New Features
It's hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues and Pull Requests to projects, helping contributors add the right details at the start of a thread. This is the first of many improvements to Issues and Pull Requests that we're working on based on feedback from the community.
To add an Issue template to a repository create a file called 
ISSUE_TEMPLATE in the root directory. A file extension is optional, but Markdown files (.md) are supported. Markdown support makes it easy to add things like headings, links, @-mentions, and task lists to your templates.
Pull Request templates follows the same pattern: add a file called PULL_REQUEST_TEMPLATE to the root directory of your repository.
If you're worried about the added clutter in the root directory of your project, we also added support for a .github/ folder. You can put CONTRIBUTING.md, ISSUE_TEMPLATE.md, and PULL_REQUEST_TEMPLATE.md files in .github/ and everything will work as expected.
Check out the documentation for additional information on the feature.
bfire
●
General
Posters featuring some extraordinary Octocat moments are now available in 8.5"x11", 18"x24", and 24"x36" sizes*. Check them out in the GitHub Shop
*Frames not included
spraints
●
New Features
If you have source code in Subversion, Mercurial, Team Foundation Server, or another Git repository, you can now quickly and easily move that code to GitHub with the GitHub Importer. It will move your code and then notify you (via email or in your browser) when your newly populated GitHub repository is ready for action.
Access the GitHub Importer directly from https://import.github.com, or use the import feature to migrate your code when you create a new repository on GitHub.com. Your repository will join over 400,000 that have used this feature to move to GitHub!
For more on migrating your source code, see "Importing your project to GitHub" in GitHub Help.
mcolyer
●
Enterprise
We are excited to announce the release of GitHub Enterprise 2.5. With this release, we’re introducing features and updates that will help development teams build software at scale with a focus on scalability, security, and management of GitHub Enterprise for development teams of any size.
It's important that your GitHub Enterprise instance can support the way you work without skipping a beat, even if your team is 10,000 strong and growing exponentially. In this release, we're introducing a better way to add new users to large installations, more ways to collaborate safely, and other tools and updates that will help support your team as it gets bigger.
You'll also find a round of updates from a clean and simple design refresh to added support for Subversion, and more. Ready to upgrade? Download GitHub Enterprise 2.5.
Clustering was specifically designed for very large installations but requires some additional administrative resources. Check out the documentation to see how it works or contact your GitHub account manager to discuss scaling options.
git fetch for large amounts of data at almost the same time can cause a substantial CPU and RAM load on our fileservers. With GitHub Enterprise 2.5, we have improved our resilience to the degraded performance that can happen with "thundering herds."
yourfrienderin
●
General
To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.
Judy Gichoya is a medical doctor specializing in radiology, but she’s also an experienced programmer who is accelerating the growth of OpenMRS. With a mission to improve healthcare delivery in resource-constrained environments, OpenMRS is coordinating a global community to create a user-driven, open source medical record system platform that helps ease the work of health care providers. We asked Judy to share the story of how she became a developer, and what she’s learned from her work.
Erin: How long have you been developing software?
Judy: In 2001 I was enrolled at a local college in Nairobi to learn accounting when a family doctor noted that it would be more helpful for me to learn technology-related courses. I dropped off accounting and used the money that I had to enroll into IMIS, which taught technology and management concepts. I was required to work on a project in either Pascal or Visual Basic, and that's how I started programming. The challenge with being a student at this point was that we did not have enough teachers who understood programming, so most of the work that I did was self-taught by following tutorials on the Internet.
In 2003 I joined medical school and subsequently kept programming. I needed some money for school fees and joined a local company where in the evening after school I assembled their desktops. I assembled close to 10 computers every evening and hence got a good feel of the range of hardware available. I continued to learn more on programming, focusing on Java at that point. Around 2007 when I was doing my clinical rotations, the number of patients we treated with HIV-AIDS overwhelmed me, and I started wondering how the data for the care would be organized. A local nonprofit organization called AMPATH was starting to explore the use of OpenMRS, an open-source medical record system to help manage the patients and that’s how I got involved.
Erin: What programming languages do you use?
Judy: I started off using Java, but that can be a difficult language to learn in a developing country as it’s hard to find good teachers and mentors. I moved to using Python, Angular JS and various HTML5 technologies, and I wish I had made this move earlier. I am learning Node JS and tinkering with machine learning for some data analysis that I want to do in radiology.
Erin: Who did you look up to in your early days of software development?
Judy: A developer called Ben Wolfe, who was working on OpenMRS in the US, visited Kenya and provided local training to interested people. I found him very inspiring and knowledgeable. Doctors who write code have always surrounded me, and so it was a natural fit for me once I graduated as a medical doctor to continue writing code. I have interacted with many physicians who continue to do that both in the U.S. and worldwide. We all know diversity issues are a big problem, and I cannot say that I had any woman to look up to or work with when I started out.
Erin: Tell us about your journey into the world of software development
Judy: The very first time I saw a computer was in high school. We received a donation of 10 computers running Windows 3.1 for a computer lab that was used by more than 300 students. The school was looking for some volunteers to learn computers, and I jumped on the opportunity. This provided for guaranteed time using the computers, but my Agriculture teacher was very disappointed and thought it was a big mistake. We shared one teacher across the whole province, which meant several schools relied on him to teach a few days every month.
We were falling behind, so I started to study ahead of everyone else to help the 10 students who were going to seat a final examination in computers in order to graduate from high school. This experience sufficiently enabled me to be self driven in personalized learning, and taught me how to maximize use of available resources.
I had close to US$200 saved after graduation (actually from selling chicken). I bought a second-hand computer and took it home. We did not have electricity in my village home and I had to hide it from my dad who would not approve. I set up my computer in my uncle's house would go there and use it and then go back home.
When it finally came time to do programming, I modified a ‘hello world’ application to be ‘hello Judy’.
Erin: What resources did you have available when you first got into software development?
Judy: In 2002 while pursuing IMIS certification, Strathmore University had several computer labs that I could use, furnished with Internet. I made friends along the way who were interested in programming and so we had a good support group that could help each other.
When I started working at OpenMRS, their community was the biggest resource for helping me get started with Java programming. They were available on IRC and Google groups and once I learned how to use the Wiki to search previously-asked questions and ‘how to’ pages, things got a little better. Despite the experience that most open-source products are poorly documented, the large and vibrant OpenMRS community contributed a lot to my learning.
Erin: What have you learned as a developer?
Most of my work has been around medical record systems, and I can say that good computing saves lives. What has happened over the last few years is how remarkably easy it's become to develop software. And therefore the developer needs to be integrated within an ecosystem that's trying to tackle a problem whether it's business or for impact, and this is the only way I think to be relevant.
There have been lots of changes of perception about developers. Initially there was a myth that developers were weirdos, but now you know developers have become celebrities. Moreover there is lots of hype for looking for the next Google or the next Facebook and I think it's easy for other people to get caught up in the circus.
Erin: Is there any advice you’d give someone just getting into software development or open source?
Judy: Looking back on my experience, I would say stay passionate about what you care about and be persistent. Open source is not easy as you know, your questions can get answered two weeks later, or sometimes never answered, and so persistence is key. For those who are worried about income or business, there is a lot of opportunity in open source.
If you were starting out specifically in a limited resource setting, I would encourage you to learn languages that take a shorter time to become proficient in, and where you have available resources to make you successful.
Erin: Can you share some background on OpenMRS and how it’s changing global healthcare?
Judy: Around 2007, a group of 4 physicians working in global health in Kenya and Rwanda came together at the Medinfo San Francisco conference during break in a café to figure out a solution to scale up providing care in their countries. On napkins, they brainstormed the first data model that would lead to OpenMRS. Three developers initially worked on the project, but since day one, there was a strong desire to open source the project that led to a community of friends growing around OpenMRS.
Our experience is that people wanted tools to use that were local to their problems, and OpenMRS provided a starting point for them to tackle their specific problems. We had some academicians who had grants that were looking at health technology adoption and assessment in various countries. They never recommended OpenMRS, but the local initiatives picked up OpenMRS as the tool to use to get started. This led to several national implementations of OpenMRS including Rwanda, Kenya, Vietnam, Uganda, and Mozambique with more countries increasingly adopting OpenMRS to provide health care.
Erin: Tell us a bit about the community that is contributing to OpenMRS. How has it changed over the years? What are some urgent needs you have?
Judy: What started off as three developers working on OpenMRS full-time has resulted into this large community. Our community is organized around implementers, people who do not necessarily have development expertise but use our software, and developers who actively write code for OpenMRS. We have developers from all over the world as we are in use in over 42 countries (https://atlas.openmrs.org/).
One thing we have not been able to do well has been to track forked off code contributions. Every month we have a surprise article or new development /use case of OpenMRS that we were not aware of. I guess this can be considered a success in the open source community. But it would be good to convince people who have forked code to contribute back to the community.
Running our diversity statistics was rather embarrassing since this is an area we lag behind in. We have organized developer levels that people can work towards and we had no /dev/5 developers who were female. We need more people working on OpenMRS, and are working towards a certification program powered by open source learning. We still are looking for funding to support our MOOC launch. Most importantly, our mission is that information is care. Most of the areas where we work have very limited resources, and we only tackle one end of the big global health problem by providing software. We need resources and partners to help us accelerate tackling the health problem in limited resource settings.
Erin: Where do you see the future headed for open source software in healthcare?
Judy: As we grow older and people live longer, caring for patients is increasingly more complex. In developing countries, open source technologies support leapfrogging through the health divide to take care of the high burden of communicable and noncommunicable diseases. For developed countries, the health care data is locked into vendor systems and doctors cannot get evidence by quickly searching the data. For example, I am using OpenMRS to run a disease registry to track outcomes of patients that receive treatment with Yttirum 90 for advanced liver cancer in the US. Before introducing this project, a solution had been sought for years and required a huge capital cost. I see open source playing a big role in these fields to provide such flexibility
Learn more about Judy and her work on her website, or get in touch on Twitter.
mastahyeti
●
Engineering
Despite the best efforts of its writers, software has vulnerabilities, and GitHub is no exception. Finding, fixing, and learning from past bugs is a critical part of keeping our users and their data safe on the Internet. Two years ago, we launched the GitHub Security Bug Bounty and it's been an incredible success. By rewarding the talented and dedicated researchers in the security industry, we discover and fix security vulnerabilities before they can be exploited.
Of7,050 submissions in the past two years, 1,772 warranted further review, helping us to identify and fix vulnerabilities spanning all of the OWASP top 10 vulnerability classifications. 58unique researchers earned a cumulative $95,300 for the 102 medium to high risk vulnerabilities they reported. This chart shows the breakdown of payouts by severity and OWASP classification:
| A1 | A2 | A3 | A4 | A5 | A6 | A7 | A8 | A9 | A10 | A0 | Sum | |
| Low | 4 | 5 | 11.5 | 1 | 8 | 11 | 5 | 7 | 3 | 3.5 | 1 | 60 |
| Medium | 2 | 1 | 12 | 0 | 1 | 1 | 5 | 1 | 0 | 3 | 0 | 26 |
| High | 2 | 2 | 3.5 | 0 | 2 | 1 | 0 | 0.5 | 0 | 0 | 2 | 13 |
| Critical | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 3 |
| Sum | 11 | 8 | 27 | 1 | 11 | 13 | 10 | 8.5 | 4 | 6.5 | 3 | 102 |
jssjr
●
Engineering
Last week GitHub was unavailable for two hours and six minutes. We understand how much you rely on GitHub and consider the availability of our service one of the core features we offer. Over the last eight years we have made considerable progress towards ensuring that you can depend on GitHub to be there for you and for developers worldwide, but a week ago we failed to maintain the level of uptime you rightfully expect. We are deeply sorry for this, and would like to share with you the events that took place and the steps we’re taking to ensure you're able to access GitHub.
benbalter
●
New Features
GitHub Pages is now running the latest major version of Jekyll, Jekyll 3.0, and with it, many of the complexities associated with publishing have been further simplified, meaning it's now easier and faster to publish beautiful sites for you and your projects.
kramdown in your site's configuration (or removing it entirely) over the course of the next three months.
{% highlight %} Liquid tag, forcing you to leave a pure-Markdown experience. With the kramdown and Rouge as the new defaults, syntax highlighting on GitHub Pages should work like you'd expect it to work anywhere else on GitHub, with native support for backtick-style fenced code blocks right within the Markdown.
--profile to the buildorserve command, Jekyll will analyze your site's build time, so you can see exactly where things can be sped up, ensuring you spend more time authoring content, and less time waiting for your site to build.
relative_permalinks: true to your site's configuration. Going forward, regardless of your site's configuration, if you add the permalink directive to a page's YAML front matter, the path should be relative to the site's root directory, not the page's parent.
Starting May 1st, 2016, GitHub Pages will no longer support Textile. If you are currently using Textile (Redcloth) to author your Jekyll site, you'll need to convert your site to use Markdown instead.
The changes introduced today promise to make GitHub Pages a faster, more intuitive experience for new and power users alike. For more information on upgrading, see Jekyll's 3.0 upgrade guide, and if you have any questions about Jekyll 3.0, the upgrade process, or just GitHub Pages in general, please get in touch with us.
Happy (simplified) publishing!
jaw6
●
General
Eventually, any interesting software project will come to depend on another project, library, or framework. Git provides submodules to help with this. Submodules allow you to include or embed one or more repositories as a sub-folder inside another repository.
For many projects, submodules aren't the best answer (more on this below), and even at their best, working with submodules can be tricky, but let's start by looking at a straight-forward example.
y-shaped stick and a rubber-band.
flickr photo shared by young@art under a Creative Commons (BY) license
At the same time, in another repository, you've got another project called Rock—it's just a generic rock library, but you think it'd be perfect for Slingshot.
You can add rock as a submodule of slingshot. In the slingshot repository:
git submodule add https://github.com/<user>/rock rock
rock folder inside slingshot, but if you were to peek inside that folder, depending on your version of Git, you might see ... nothing.
Newer versions of Git will do this automatically, but older versions will require you to explicitly tell Git to download the contents of rock:
git submodule update --init --recursive
rock folder in the slingshot repository with all the content from the rock repository.
On GitHub, the rock folder icon will have a little indicator showing that it is a submodule:
And clicking on the rock folder will take you over to the rock repository.
That's it! You've embedded the rock repository inside the slingshot repository. You can interact with all the content from rock as if it were a folder inside slingshot (because it is).
On the command-line, Git commands issued from slingshot (or any of the other folders, rubber-band and y-shaped-stick) will operate on the "parent repository", slingshot, but commands you issue from the rock folder will operate on just the rock repository:
cd ~/projects/slingshot
git log # log shows commits from Project Slingshot
cd ~/projects/slingshot/rubber-band
git log # still commits from Project Slingshot
cd ~/projects/slingshot/rock
git log # commits from Rock
git clone to download the contents of the slingshot repository. At this point, if you were to peek inside the rock folder, you'd see ... nothing.
Again, Git expects us to explicitly ask it to download the submodule's content. You can use git submodule update --init --recursive here as well, but if you're cloning slingshot for the first time, you can use a modified clone command to ensure you download everything, including any submodules:
git clone --recursive <project url>
rubber-band. Let's take the rubber-band you built for slingshot, split it out into a stand-alone repository, and then embed it into both projects via submodules.
You can take everything from the Project Slingshot's rubber-band folder and extract it into a new repository and even maintain the commit history.
Let's begin by extracting the contents of the rubber-band folder out of slingshot. You can use git filter-branch to do this, leaving you with just the commits related to rubber-band. The git filter-branch command will rewrite our repository's history, making it look as if the rubber-band folder had been it's own repository all along. For more information on git filter-branch, see this article.
The first step is to make a copy of slingshot to work on—the end-goal is for rubber-band to stand as its own repository, so leave slingshot as is. You can use cpwith -r to recursively copy the entire slingshot folder to a new folder rubber-band.
cd ..
cp -r slingshot rubber-band
rubber-band is just another slingshot, but now, from the rubber-band repository, run git filter-branch:
cd rubber-band
pwd # (double check before proceeding!)
git filter-branch --subdirectory-filter rubber-band -- --all
rubber-band, which is a repository that sort of resembles Project Slingshot, but it only has the files and commit history from the rubber-band folder.
Since you copied this from slingshot, the new repository will still have any remote tracking branches you setup when it was slingshot. You don't want to push rubber-band back onto slingshot. You want to push this to a new repository.
Create a new repository for rubber-band on GitHub, then update the remote for rubber-band. Assuming you were calling the remote origin, you could:
git remote set-url origin https://github.com/<user>/rubber-band
git push.
Now that you've separated rubber-band into its own repository, you need to delete the old rubber-band folder from the slingshot repository:
git rm -r rubber-band
git commit -m "Remove rubber-band (preparing for submodule)"
slingshot to use rubber-band as a submodule:
git submodule add https://github.com/<user>/rubber-band rubber-band
git commit -m "rubber-band submodule"
rock, we now have a repository-in-a-repository. Three repositories, in fact: the "parent" repository slingshot, plus the two "sub" repositories, rock and rubber-band.
In addition, if we dive back into slingshot's history, we'll see the commits we originally made into rubber-band back when it was a folder—deleting the folder didn't erase any of the history. This can sometimes be a little confusing—since the rubber-band "child" repository has a copied-and-modified version of those old slingshot commits, it can sometimes feel like you're having déja vu.
Unfortunately, any collaborator who pulls slingshot at this point will have an empty rubber-band folder. You might want to remind your collaborators to run this command to ensure they have all the submodule's content:
git submodule update --init --recursive
rubber-band submodule to magic roll-back can. Luckily, all you need to do that is to follow the same procedure you used earlier when you added rocktoslingshot, in "Adding a submodule."
cd ~/projects/roll-back-can
git submodule add https://github.com/<user>/rubber-band rubber-band
git commit -m "rubber-band submodule"
git submodule update --init --recursive
git submodule update and git clone --recursive to ensure they get everything—this includes any automated deployment or testing service that might be involved in the project! We recommend you use something like our "Scripts to Rule Them All" to ensure that all collaborators and services have access to the same repository content everywhere.
●Submodules require you to carefully balance consistency and convenience. The setup used here strongly prefers consistency, at the cost of a little convenience. It's generally best to have a project's submodules locked to a specific SHA, so all collaborators receive the same content. But this setup also makes it difficult for developers in the "parent" repository to contribute changes back to the submodule repository.
●Remember that collaborators won't automatically see updates to submodules—if you update a submodule, you may need to remind your colleagues to run git submodule update or they will likely see odd behavior.
●Managing dynamic, rapidly evolving or heavily co-dependent repositories with submodules can quickly become frustrating. This post was focused on simple, relatively static parent-child repository relationships. A future follow-up post will detail some strategies to help manage more complex submodule workflows.
git filter-branch
kelseyschimm
●
Conferences
Mark your calendars. GitHub has a fresh lineup of events for 2016 – including two new European conferences, GitHub Satellite and CodeConf Copenhagen.
samlambert
●
Engineering
On Thursday, January 28, 2016 at 00:23am UTC, we experienced a severe service outage that impacted GitHub.com. We know that any disruption in our service can impact your development workflow, and are truly sorry for the outage. While our engineers are investigating the full scope of the incident, I wanted to quickly share an update on the situation with you.
A brief power disruption at our primary data center caused a cascading failure that impacted several services critical to GitHub.com's operation. While we worked to recover service, GitHub.com was unavailable for two hours and six minutes. Service was fully restored at 02:29am UTC. Last night we completed the final procedure to fully restore our power infrastructure.
Millions of people and businesses depend on GitHub. We know that our community feels the effects of our site going down deeply. We’re actively taking measures to improve our resilience and response time, and will share details from these investigations.
aaronshekey
●
New Features
You’ll notice there’s a new Markdown text-formatting toolbar on all the comment fields throughout GitHub. While you've always been able to use Markdown to format your text with links, headers, italics, and lists, the new toolbar allows you to do so without learning Markdown syntax.
The toolbar includes a limited set of tools that gets out of the way of experts, but helps those new to GitHub to write just as clearly, and expressively as anyone else. Neat.
In addition to standard Markdown formatting, the toolbar also includes GitHub-specific features. @mentions bring additional users or teams into the conversation, issue and pull request links allow you to cross-reference related discussions, and task lists track outstanding tasks. They’re now available to you with a single click.
mhagger
●
General
If your New Year's resolution was to update to a new version of Git, we've got good news. The Git community has just released Git 2.7.0, and we'd like to share some of its highlights with you.
git bisect
git bisect is an awesomely powerful tool for figuring out how a bug got into your project. Just in case you're unfamiliar with it, we'll take this opportunity to give you a short introduction. If you already know about git bisect, feel free to skip the following section.
git bisect
master branch, the hyperdrive isrunning backwards:
$ git checkout master $ ./test_hyperdrive FAILURE: destination is getting farther away"That's funny," you think to yourself, "I know it worked in version 4.2." You double-check:
$ git checkout v4.2 $ ./test_hyperdrive SUCCESS!The question is, how did it break? Some change between version 4.2 and
master must have introduced a bug.
At this point you could open your debugger or start adding print statements to the hyperdrive module. But that's a lot of work. Luckily, there's an easier way to discover where the bug was introduced: git bisect.
You start by telling git bisect a good and a bad version:
$ git bisect start $ git bisect good v4.2 $ git bisect bad master Bisecting: 2 revisions left to test after this (roughly 1 step) [8cc2d9b4f02ccc208bd9f6d6b01ac6ed57fbb606] Take advantage of available wormholesAs soon as you do so,
git bisect chooses a revision roughly midway between the known-good and the known-bad revisions. Your job is to test this version then tell Git the result of your test:
$ ./test_hyperdrive SUCCESS! $ git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [f97f670fb5303ea0097e4475ec8fcf3e2c7dde85] Hyperdrive: bypass the compressorYou continue like this, each time halving the gap between the newest known-good and the oldest known-bad revisions:
$ ./test_hyperdrive SUCCESS! $ git bisect good Bisecting: 0 revisions left to test after this (roughly 0 steps) [e0cbfe825a0285e58c59cefb9b78abff2ae0c369] Implement hyperdrive parity inverter $ ./test_hyperdrive FAILURE: destination is getting farther away $ git bisect bad e0cbfe825a0285e58c59cefb9b78abff2ae0c369 is the first bad commit commit e0cbfe825a0285e58c59cefb9b78abff2ae0c369 Author: Some Developer <me@example.com> Date: Thu Dec 31 14:05:09 2015 +0100 Implement hyperdrive parity inverter :100644 100644 a9562e3d7cea826ed52072e9b104bc9f7e870cf9 da2bc4f6d15943dcf4872641fae08d79d7696512 A hyperdrive/parity.cCongratulations! You now know that commit
e0cbfe8 introduced the bug. Often, viewing the changes made by that commit makes it obvious what the mistake was and how to fix it. If not, at least you've dramatically narrowed down the amount of code that you have to debug.
When you're done, type git bisect reset to end the bisection session.
git bisect: not just for regressions anymore
git bisect is most often used to find software regressions, it should be clear that the same approach can find any change that was introduced into the software; for example,
●When did a certain feature slow down?
●When did the size of the images directory grow beyond 5 MB?
●When was a particular bug fixed?
git bisect could always locate such changes. But regardless of what kind of change you were looking for, you always had to type good to mark revisions before the change and bad to mark revisions after the change. This could be very confusing, especially if you wanted to find the commit that fixed a bug1.
To better support such uses, git bisect now allows you to use different terms in place of good and bad. With no extra setup, you can now use the more neutral terms old and new to represent "the old state of affairs" and "the new state of affairs":
$ git bisect start $ git bisect old v4.2 $ git bisect new masterYou can even invent your own terms. Just specify them when you start the bisection:
$ git bisect start --term-old yucky --term-new yummy $ git bisect yucky v4.2 $ git bisect yummy master[source]
--recurse-submodules
--recurse-submodules option; for example,
$ git push --recurse-submodules=on-demand origin
Now there is a new configuration option that you can use to save the extra typing (and the embarrassment of pushing incomplete work):
$ git config push.recurseSubmodules on-demand
If you'd rather have Git just warn you about potential problems, then use
$ git config push.recurseSubmodules check
You can override this configuration setting by typing --no-recurse-submodules on the command line. [source]
worktree improvements
git worktree command that was introduced in Git 2.5.0? It allows you to create multiple working copies that are connected to a single local Git repository.
In Git 2.7.0, git worktree continues to get better:
●With the new git worktree list command, you can list the worktrees linked to the current repository and the branch checked out in each one. [source]
●
git bisect can now run in any worktree, or even in two worktrees simultaneously. [source]
●You can now clone from a linked worktree. [source]
●Submodules support for worktrees is improving. [source]
git p4
git p4 is a bridge between Git and Perforce. It can fetch commits from Perforce into Git, and push commits from Git to a Perforce server. It allows you to use Git locally, even if you ultimately have to push your changes to a Perforce server. (There are similar tools to bridge between Git and Subversion, Mercurial, Bazaar, TFS, and others.)
git p4 now has support for storing large files in Git LFS ("Git Large File Storage"). This allows you to store large files from Perforce (e.g., media files) outside of your Git repository to avoid bloating the repository on disk. (Note that this feature doesn't yet support git p4 submit.) [source]
git branch, for listing branches; git tag, for listing tags; and git for-each-ref, for listing references of any kind. But these commands, despite their overlapping functionality, had differing capabilities and options.
Now, thanks to the work of Google Summer of Code student Karthik Nayak, these commands now have a more uniform interface, and have also gained some features along the way. Now all three commands support the following options:
●
--points-at <object>: list any references that point at the specified object
●
--merged [<commit>]: only list references that have been merged into commit (HEAD by default) :
●
--no-merged [<commit>]: only list references that have not been merged into commit (HEAD by default) :
●
--contains [<commit>]: only list references that contain the specified commit (HEAD by default)
They have also gained new formatting and sorting options. [source] [source]
git stash show now supports two configuration settings, stash.showPatch and stash.showDiff, that select how it should display stash entries by default. [source]
git blame now works correctly with the --first-parent option, and also when --reverse and --first-parent are used together. [source] [source]
The appearance of gitk on high-DPI monitors has been improved. [source]
Security fixes:
●Avoid integer overflow when computing diffs. [source]
●Limit submodule recursive fetches to safe protocols. [source]
We recommend that everybody upgrade to a version of Git with these fixes, namely Git 2.3.10+, 2.4.10+, 2.5.4+, 2.6.1+, or of course 2.7.0+.
git bisect shouldn't care whether the change you are looking for was from badtogood or from goodtobad. But in fact, if the first two commits that you mark are not direct ancestor/descendant of each other, git bisect has to examine some common ancestors of those commits. In that case, the logic is different depending on the direction of the transaction that you are looking for.
mattcantstop
●
General
If you're writing code, a repository is an obvious place to manage your work. But what about when the team's primary deliverable is not software? At GitHub, the Professional Services team helps customers get set up with GitHub Enterprise and trains people how to use Git and GitHub. We use GitHub extensively to efficiently and transparently communicate, schedule and prioritize. We hope how we use GitHub will help your team use the platform for more than just code.
Our README provides a clear path forward for teams who want to utilize our services by listing our offerings and showing who to reach out to if help is needed. We provide specific team handles for people to mention us with GitHub's @mention feature. By mentioning a specific team they can reach the subset of the team they need.
This way, different team members can respond to their respective team handles. Some teams at GitHub rotate who is responsible for checking their team's mentions on a weekly basis. This lets some team members have stretches without distraction while the team is still responsive to GitHubbers outside of their team. We have streamlined many processes to utilize @mentions with GitHub's notifications instead of relying solely on email correspondence.
In our README, we also have linked Markdown files that document our services. We have files that document how we work, including everything from checklist-formatted Markdown files for onboarding new team members to guides on how to configure LDAP for our customers on GitHub Enterprise. Our team repository provides ample information for people to do their jobs.
retrospective.md in a /engagements folder in the repository to open the Pull Request. We then use the top comment of our Pull Request to track any bugs, follow-up tasks for after the engagement, and leave notes for sales to take over. We add comments to the Pull Request for each day's notes to keep everyone on the team in the loop.
When we complete the engagement we write our retrospective. Many different teams at GitHub know about this folder and check in on customer feedback by visiting this /engagements folder and reviewing the retrospective files. We use Pull Request comments to add final details like our expenses and mention the teams needed to close out any outstanding tasks. The process lets us have a great historical document of our conversations instead of the details getting lost in people's email.
We often have lengthy discussions about which path to chose, and because we're a diverse team, we hear many different approaches. Our internal focus is to get to a point where we can move forward with an option to test, and refine the path forward as we get more information about what works best.
johndbritton
●
General
We love the Ruby programming language for its natural, human-focused design philosophy and think you will too. That's why we teamed up with Udacity to bring you three new Ruby Nanodegrees, starting with Beginning Ruby.
Beginning Ruby is open for enrollment now, with Ruby on Rails and Senior Ruby on Rails becoming available in 2016.
In each of the Nanodegree programs you will learn from Udacity's expert instructors, with supplemental interviews and content from GitHub Ruby instructors Jesse Toth and John Britton.
With a commitment of 10-15 hours per week, students complete a Nanodegree in an average of 4-9 months, at a cost of $200 per month with 50% returned upon graduation in some cases.
Partnering with Udacity to create the Ruby Nanodegree series is a step to help close the talent gap and empower aspiring developers to gain new skills.
Previous 12345… 4243Next
●Status
●API
●Training
●Shop
●Blog
●About
●Pricing
●© 2016 GitHub, Inc.
●Terms
●Privacy
●Security
●Contact
●Help
Something went wrong with that request. Please try again.
You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.