Skip to content

GitHub Campus Experts - Technology leadership at your school

The student developer community is thriving thanks to hardworking student leaders like Josh Simpson. They organize tech talks, write tutorials, plan meetups, teach workshops, host office hours, produce hackathons, and more.

To encourage more students to become stewards of their campus technology communities we've created the GitHub Campus Experts program.

GitHub Campus Experts Logo

Starting today, we're accepting Campus Expert applications from students. Successful applicants will receive training in public speaking, community leadership, technical writing, and software development from GitHub. As part of a network of technology leaders at universities around the world participants receive training and mentorship from GitHub employees, opportunities to participate in exclusive events, and support to help grow the local student developer community.

Becoming a Campus Expert is a great way to amplify your efforts as a student leader, get training and mentorship with the latest technologies, and gain experience relevant to a career in developer relations.

Learn more and apply to become a GitHub Campus Expert for your school.

Community Partners for CodeConf LA

Since we are only a few days away from CodeConf LA, we’re happy to announce our Community Partners for the next conference in our 2016 lineup.

Community Partners are chosen based on several criteria but the most important questions we ask ourselves when looking for partners are:

  1. Do they have an audience that can benefit from free tickets to our conference?
  2. Are they lowering the barriers for people from underrepresented backgrounds to enter the tech industry?
  3. Are they doing socially impactful work in the community where the conference will be held?

We’re aware that genuine diversity and inclusion doesn’t result from an “if you build it, they will come” mentality. We know that diversity breeds innovation and that bringing people together from disparate backgrounds will not only enrich the conference experience but also the experience of contributing to open source projects. For these reasons and more, we’ve chosen to reach out to the following organizations to help us with our local outreach efforts in Southern California. You can read a bit more about some of our Community Partners below.

communitypartner_blogimage


Operation Code

Veteran-founded and led, Operation Code is a 501(c)(3) tax-exempt nonprofit organization on a mission to get active military, citizen-soldiers, veterans, and their families coding and building software to change the world. They help the nation's finest and their families learn to code, network, and transition to careers while filling the nation's technical talent shortage.

"I served in the Marines as an Infantryman for 5 years and I would like to build something that will disrupt how folks in the military transition out into the civilian world." -Jameel Matin

Ticket Details: Scholarship recipients had to apply and meet two criteria: military service and strong interest in software development or open source. Finalists had to demonstrate open source contributions through GitHub and/or personal projects and a strong desire to join the industry as a software developer.


Sabio.la

Sabio is an inclusive and diverse community of exceptional software developers that are looking to improve their development skills. They work hard to encourage as many women and people of color to participate in an ever-growing community of software developers and have a proven track record of helping smart and motivated people get into tech roles throughout the country.

"The world is now flat, and all humans are connected via the awesome world wide web that is being created, modified, and improved on a daily basis. We must have diverse web developers to have an even better web." - Liliana Monge

Ticket Details: Scholarship recipients are active members of the Sabio developer community.

Upcoming events: Information Session on on July 13th


Rails Girls LA

Rails Girls helps make technology more approachable for women through technical workshops that aim to teach skills and provide a community for women to connect with technology and build cool things.

"We are different and yet we are the same. We want different things yet we want the same things. Our differences and similarities weigh the same." -Jen Diamond

Ticket Details: Scholarship recipients include women who coached at Rails Girls workshops and who are leaders in the Los Angeles programming community.

Upcoming events: LA Summer of Code: Open Source Pair & Mob Programming on June 28th, 2016


Rails Bridge San Diego

Railsbridge San Diego is a free, 1.5-day workshop set up to increase diversity in the tech community by teaching people Ruby and Rails. The Railsbridge workshop provides a space for newcomers from often under-represented groups in tech to learn, ask questions, and connect to the San Diego tech community.

"People making technology should accurately reflect the diversity of those using it!"
-Railsbridge motto

Ticket Details: We distributed scholarship codes to women from the Railsbridge San Diego community who have continued learning to code. Recipients attended a Rails and Javascript coding school and have remained active in the local tech community. They've joined and contributed to local Ruby and Javascript meetups as well as volunteered at other diversity in tech workshops.


Los Angeles Jenkins Area Meetup The Los Angeles Jenkins Area Meetup connects professionals in the pursuit of sharing practices, networking, open source, and exploring advanced topics such as build automation, virtualization, testing, and CI/CD.


Tech in Motion Tech in Motion is a national event series started with the goal of bringing local tech communities together to meet, learn, and innovate. Tech in Motion topics are broad in the hopes that people of all disciplines and skills sets can come and learn something new each time.

Upcoming Events: Open Source: Shaping the Future of Los Angeles

It's not too late to join us at CodeConf LA next week! Grab your tickets here and chat with these amazing Community Partners in person.

Meet Josh Simpson, student, developer, and hackathon advocate

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

jsdv

Josh Simpson, who is currently pursuing his computer science degree at King’s College in London, proves you don't need decades of programming experience to make an impact. When he’s not hacking away at school, Josh dedicates his time to helping others learn to code — mainly through his involvement in the KCL Tech Society and as a student advocate at HackCampus, which connects students to internship opportunities at startups in the UK. We talked to Josh about these two initiatives and learned more about his other passion: hackathons, and how they bring the tech community together.

Erin: Give us the basics. Who is Josh Simpson and what does he do?

Josh: At the moment I’m a 4th-year computer science student in London. For the past year and a half, I’ve been doing a lot of work with the hackathon community here. I also work with Hack Campus, which helps connect developers with companies and provides a better intern experience.

Erin: How long have you been developing software?

Josh: I’d love to say it has been for the entire time I’ve been doing my degree, but that’s not really true. I’ve really been investing in learning to code for about the past two years.

Erin: There are so many new avenues for learning to code, do you have thoughts about the advantages of going through a traditional program?

Josh: The biggest advantage at the moment is that I have four years of working within safety nets. As a student, you have so much to protect you from what could go wrong in the real world. If something did go horrifically wrong, I’ve got a backup system somewhere. Someone has the job to help me and make sure I don’t fail massively, which is a huge advantage to going the traditional route. But it’s definitely no longer mandatory. You don’t have to get a computer science degree to go into programming. I think it’s fantastic, the amount of people who are self-taught who’ve come out just as good if not so much better than a lot of the programmers who learn at university. It’s inspiring. People who have just sat there at home and thought, ‘I’m going to do this’, while working part-time or full-time jobs. They come home and spend a few hours in the evening every day for a few weeks, and they’ve actually picked up something which I’ve studied for four years to get the same level. So yeah, it’s impressive.

Erin: Were there people who you looked up to when you were getting into programming?

Josh: Yeah, definitely. There are some really fantastic people around the hackathon community. They are so focused on just teaching others. I really admire Joe Nash, who is the developer evangelist for Improbable. When I met him, he was doing a lot of work with MLH, and he brought me along to my first hackathon. It was through him that I actually started getting involved in the hackathon community. He helps me out with job interviews and tells me how I can better myself. He’s one of those people who will tell you what you’re doing is wrong, incessantly, but you argue with him for five minutes and then you go, “you’re right, you’re actually completely right about this.” Which is, I think, an incredible ability.

Erin: What sparked in your mind that development was something you wanted to do.

Josh: Four years ago I enrolled myself in a computer science course thinking that it was a lot lighter — I had no idea it was programming, essentially. I stuck with it for a couple of years, but I was doing my degree for the sake of doing my degree — I wasn’t doing anything on the side, I wasn’t helping myself. At the beginning of my third year, I realized I needed to find other like-minded people and engage with them. I found the KCL Tech Society and joined up with them, started going to workshops, figuring out how people teach, figuring out how they host all of these fantastic community events. Over the year, I got more and more involved, to the point where suddenly I was running workshops on Ruby on Rails. I taught a room full of people to go from zero to web application in two hours! That was the big moment where I thought, ‘hey, I’m pretty good at being a developer.’

I started building school projects and putting together hackathons. I built Dot to Dot with a friend at Hack the Planet. It teaches people how to use APIs and how to build their own. That involved 54 hours of no sleep before we actually started the hack, so the naming was a little bit off. It was a nice feeling that everyone seemed to actually enjoy using it.

Erin: Why should more people get involved with hackathons?

Josh: There’s a massive culture around learning, building, and sharing. People who have never coded before in their life can go to a hackathon and learn how to build a web application in 24 hours. And on the flip side of that, you have a community that is so invested in taking the time to teach other people — it’s 24 hours in a room filled with people who share the same interest of building stuff and teaching each other. There are very few places in the world and very few fields where you can find that same thing.

Erin People say ‘get involved with the community’ but it can be really hard to put yourself out there, especially if you’re shy or don’t have a lot of confidence in your code. Any advice for getting past that?

Josh: It’s…really difficult. One of the pieces of advice we give people who don’t have a lot of confidence in their code is to point to other people in the room, including myself — and this is the nice thing about hackathons — where we can say that we have no specific expertise, no singular experience that makes us better than anybody. We have an interesting idea, and one of us managed to draw together enough code to make it work, and this is the same stuff we do in our workshops. It’s the same as if you went through code academy — it’s just framed differently. It’s difficult to get involved until you realize that you’re just as good as everyone else was at some point. Some people have just had the experience to go ‘oh, I actually know how to apply this in this one specific way’.

Erin: And one might say that you could get that experience to apply your ideas by going to hackathons?

Josh: Yeah, haha, I would encourage people to just find a meetup locally. Find a bunch of people who are interested in something similar; it’s really helpful and they’ll teach you a bunch of stuff that you didn’t know beforehand, which lets you come back and say ‘I know this little bit’, and the cycle continues from there. A new person will come to the meetup and it’s your turn to say, ‘hey, did you know this beforehand?’

Erin: I’d love to talk about Hack Campus — What’s so cool about it?

Josh: We approach startups and advocate for students by encouraging them to hire interns. The startups pay a student’s wages for ten weeks - it’s £350 which is pretty good - and we sort out their accommodations right in the heart of London. So it takes away the issue of having to find and pay for a place to stay, removing a lot of stress out of that situation. And because you’re working at a startup that can’t just throw money away on them, interns are working on production code or getting their hands on something important fairly quickly.

Erin Can you tell me about some of the results of the program?

Josh: Sure. It’s growing very slowly — last summer was actually the first time we’ve run the program. We have a bunch of testimonials from the people who were involved last year. They mainly said it was a badass experience. We had people who said it was so valuable they would have done it for free — that they were pushing code by day 20. And that’s really cool, that students — students — are saying, yeah, I would’ve done that for free. We need to get better and more diverse backing to scale the program. The way it’s run now is as a single arm of Index Ventures, but the idea would be to scale that up so we can go to more places, and new startups, and bring in more students. This model doesn’t seem to exist in America, but I’d love to see something like this take hold there in the future.

Learn more about HackCampus.

The shape of open source

At its core, open source is about collaboration. Whether it's version control, licenses, or issue trackers—everything exists to support people working with each other. Open source embodies a model for people to work together, building something greater than they can create on their own.

Open source projects on GitHub come in all shapes and sizes, many are single-contributor 'solo' projects but others like Homebrew have upwards of 5000 contributors. What does open source look like at these different scales? Let's look at the last 30 days of public activity on GitHub broken down by some key activity types:

Repository activity as a function of contributor count

For projects with just one contributor, pushes (in red) represent the vast majority of all activity. Some issues are being reported but overall it's very much a solo endeavor. As the number of contributors increases however, the fraction of activity in conversational mediums increases rapidly. In fact, while the fraction of activity represented by people creating new pull requests and opening new issues remains relatively constant above ~100 total contributors, the level of activity in response to these events (issue comments, pull request review comments) continues to grow.

The changing shape of open source

By grouping projects by their contributor counts1, the first plot shows us how the shape of projects varies as the contributor pool grows. Rather than looking in aggregate, how does the shape of a single project vary over time, especially if it makes the transition from closed to open source?

A perfect example here is GitHub's own Atom, which saw its first commit by @defunkt in August 2011, but wasn't made open source until May 2014.

First Atom commit

Atom activity

An even more dramatic example of this can be seen in the activity around Roslyn, the .NET Compiler Platform which was made open source by Microsoft in 2014. You can see a steep uptick2 in activity as the project moved from closed to open source.

Roslyn

Some projects such as the popular JavaScript framework EmberJS are open source from the start but the story is largely the same—activity in open source projects is a rich mixture of commits, conversation, support, and review.

EmberJS

Open Source is a community effort

Clearly, open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes. Offering a place for people to report problems, ask questions, and suggest fixes or improvements are also a core part of any project's success.

Interested in joining the community? Check out our guide 'Contributing to Open Source' to learn more about how to find a good project. If open source is more than just code, what will your next contribution be?

1. A contributor is defined here as someone who has produced one of the listed content types (pushes, pull requests etc.)
2. So dramatic that even d3 can't keep the data within the chart :-)

Joining the White House in committing to tech inclusion

In May, we shared a report which measures our progress in the necessary work of diversifying our workforce. As we stated then, “we must create a company where anyone, regardless of what they look like or where they come from, can grow and thrive.” For GitHub to be the best version of itself, a diverse workforce is an imperative.

In the ongoing effort to make good on that promise, GitHub is joining our peers in the tech industry in signing the Tech Inclusion Pledge—an effort spearheaded by President Obama to “take action to make the technology workforce at each of our companies fully representative of the American people, as soon as possible.”

By signing this pledge, we are committing to:

  • Implementing and publishing company-specific goals to recruit, retain, and advance diverse technology talent, and operationalize concrete measures to create and sustain an inclusive culture
  • Annually publishing data and progress metrics on the diversity of our technology workforce across functional areas and seniority levels
  • Investing in partnerships to build a diverse pipeline of technology talent to increase our ability to recognize, develop and support talent from all backgrounds.

As an industry, we will only be able to build products that change the world when we have more of the world at the table, engaged in their creation. We encourage our friends in tech to join in on this important pledge.

Support LGBTQ organizations with the Pridetocat and Transtocat shirts

With the purchase of a Pridetocat or Transtocat shirt or tank top you will be assisting Transgender Law Center, TGI Justice Project, El/La Para TransLatinas, Trans Lifeline, and Alliance Health Project further their work. All proceeds from sales will be donated to these organizations that are helping educate, connect, and empower LGBTQ people.

Pridetocat Transtocat Shirts

These limited edition shirts and tank tops are available in the GitHub Shop until September 30th.

More info about the LGBTQ tech organizations that benefit from the purchase of this shirt:

Transgender Law Center

Transgender Law Center changes law, policy, and attitudes so that all people can live safely, authentically, and free from discrimination regardless of their gender identity or expression. We envision a future where gender self-determination and authentic expression are seen as basic rights and matters of common human dignity.

TGI Justice Project

TGI Justice Project is a group of transgender, gender variant, and intersex people—inside and outside of prisons, jails and detention centers—creating a united family in the struggle for survival and freedom. We work in collaboration with others to forge a culture of resistance and resilience to strengthen us for the fight against human rights abuses, imprisonment, police violence, racism, poverty, and societal pressures. We seek to create a world rooted in self-determination, freedom of expression, and gender justice.

El/La Para TransLatinas

El/La Para TransLatinas is an organization for transgender Latinas (TransLatinas) that works to build collective vision and action to promote our survival and improve our quality of life in the San Francisco Bay Area. We work to build a world where translatinas feel they deserve to protect, love, and develop themselves. By building this base, we support each other in protecting ourselves against violence, abuse, and illness.

Trans Lifeline

Trans Lifeline works to end transgender suicide and improve overall mental health of transgender people through education, advocacy, and direct service. We empower trans people to help one another, and to shape our collective efforts by drawing upon our wealth of individual experiences.

Alliance Health Project

The mission of the UCSF Alliance Health Project is to support the mental health and wellness of the lesbian, gay, bisexual, transgender, and queer (LGBTQ) and HIV-affected communities in constructing healthy and meaningful lives.

Meet Sara Chipps, founder of Jewelbots and Girl Develop It!

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

scimage

Given Sara Chipps’ experiences developing software over the past 15 years, it’s easy to understand why she’s so focused on helping people from underrepresented communities get involved in programming. From Girl Develop It! to Flatiron School to Jewelbots, Sara is all about meeting people where they are, and helping them find a path into engineering. We caught up with her to find out what she’s working on, and how it just might change the conversation around diversity in tech.

Erin: Okay, let’s cover the basics. How long have you been developing software and what programming languages do you use?

Sara: I’ve been developing software for the past 15 years, and have mostly focused on data and backend technologies. For the past four years, I’ve gotten more involved in hardware development. I’ve used C, C#, JavaScript, Ruby on Rails, some Python.

Erin: Who did you look up to in your early days?

Sara: When I was getting started, I didn’t work with another woman until five years into my career. Even then, it was one woman, and I didn’t work with another one for a really long time. My first mentors were men who were really invested in seeing more women in technology. People like Scott Hanselman, Rob Conery, Miguel DeIcaza, and John Galloway, who have all worked at Microsoft at some point. They were experienced developers who cared about the world of open source. Some time later I found out who Marissa Mayer was It was really exciting that she was an experienced and accomplished developer who also cared about fashion and other things I liked. She’s always been someone I tried to emulate.

Erin: Let’s go back a little further. Tell us about your journey into the world of software development.

Sara: My first computer was a Cention 386. I don’t even think it had Windows. I started coding to become part of the world of Bulletin Board Services (BBS), which were around before the Internet. There were also very limited resources available. There were books, Slashdot and Microsoft’s online resources and developer community. That was pretty much it. It wasn’t until several years into my career that I contributed to my first open source project. My mentors were working on a Twitter client written in Silverlight and I was so excited to get involved that I asked them for something small to work on. During that time I was doing contract work for Microsoft, British Telecom, Johnson and Johnson, and others. Contracting allowed me to spend the rest of my time working on Girl Develop It!

Erin: What advice you would give someone just getting into software development now?

Sara: Everyone learns differently and there are so many different learning styles. The good thing about having so many resources available is that you can find something that is adapted to your particular learning style. For example, some people learn through reading so online tutorials are great. Sometimes people learn by watching, so services where you can have developers on the other side of the screen working with you and coaching you are great. If you figure out what kind of learner you are, you can narrow down what resources will work for you.

Erin: Girl Develop It! Is a non-profit that provides affordable and judgement-free opportunities for women to get involved with software development. Can you share a little background on how it came about?

Sara: One day my friend and I were talking about how uncomfortable we often felt asking questions in our computer science classes. It sucked being the only women on those teams. We realized that a lot of women didn’t have a safe place to learn and ask questions. We really wanted to change that. We made Girl Develop it! as a place where people could go ask “stupid” questions.

Erin: Much of the tech world is still asking questions about how to get young women and girls interested in learning to code, but you’ve been providing answers -- With Girl Develop It!, as CTO of Flatiron School, and with Jewelbots. Are there areas where you’d like to see the conversation around women in tech evolve?

Sara: We need to see more diverse people in leadership. It’s not just about hiring more junior developers who are going to burn out. It’s promoting women who can hire other women. I’ve run two development teams of 10+ people and most of them were women. The reason for that is because I’m a woman and I know lots of women; you find people you know. People say they can’t find female developers, but I can. The only way to affect change is to promote women. It’s hard to find women with seniority. I’ve watched many of my peers drop out. They say that women are promoted on experience and men are promoted on potential. I say, find women with potential and give them the experience.

Erin: You’ve spent a lot of time with parents while building Jewelbots. What advice would you give parents who aren’t experienced with science or technology, but want to support their kids’ interest in programming or engineering?

Sara: Part of why we created Jewelbots is to help normalize programming. It’s not about finding the maker kids and giving them a new way to work, it’s about introducing all kids to programming. Right now there’s a class system that prevents kids from underrepresented backgrounds getting into technology. There are expensive private schools with STEM curriculum, but some public schools don’t even have teachers qualified to teach it.

Also, I’d tell parents to let their kids play more video games. Minecraft is a huge entrance into programming. Minecraft, Code.org, FIRST robotics -- these are the most amazing things in the world.

Erin: Are there any misconceptions out there about software developers that you think need to be retired? Why do they no longer apply?

Sara: Can we stop talking about the whole nerdy thing? As soon as building software became a lucrative job all kinds of people started going for it. It definitely used to attract one kind of person, but now it’s more mainstream. Developers aren’t nerds. They have all kinds of interests and backgrounds. When we reinforce that stereotype it just alienates people that don’t see themselves fitting into that group.

Erin: You interact with software developers of all ages, from all different backgrounds. What are some of the characteristics you see that are common amongst the developers who you find inspiring?

Sara: To be a developer you really need to love to learn because you’re going to be learning your entire career. None of us are doing any of the things we learned in school on a regular basis. It becomes irrelevant so quickly. Of course, that doesn’t suit some people and they burn out. They can’t deal with learning one more new programming language.

This hunger to learn is something I see with developers of all different backgrounds and ages. When we were doing Girl Develop It! There were women in my classes who were in their sixties and they would make study groups because they were so excited to be learning and to be a part of something.

Erin: Anything else you’d like to share? Sara: I’ve really been loving Reshma Saujani’s Ted Talk lately. It’s all about teaching women to be brave.

Get more details on Girl Develop It! or Jewelbots.

Pin repositories to your GitHub profile

You can now showcase the repositories that best represent your work on your GitHub profile. Using the "Pinned repositories" list, you can pin any public repository you have contributed to. Once you have chosen up to five repositories, you can then drag-and-drop to place them in whatever order you like.

Choose your pinned repositories

Reordering pinned repositories

If you don't customize your pinned repositories, we'll continue to show your most popular repositories. Learn more in our help guide.

Together with our new profile bios, pinned repositories allow you to create a GitHub profile that's the best representation of you and your work. We can't wait to see what you pin.

GitHub Security Update: Reused password attack

What happened?

On Tuesday evening PST, we became aware of unauthorized attempts to access a large number of GitHub.com accounts. This appears to be the result of an attacker using lists of email addresses and passwords from other online services that have been compromised in the past, and trying them on GitHub accounts. We immediately began investigating, and found that the attacker had been able to log in to a number of GitHub accounts.

GitHub has not been hacked or compromised.

What information was involved?

For affected accounts, usernames and passwords are involved. Additionally, for some accounts, other personal information including listings of accessible repositories and organizations may have been exposed.

What we are doing:

In order to protect your data we’ve reset passwords on all affected accounts. We are in the process of sending individual notifications to affected users.

What you can do:

If your account was impacted, we are in the process of contacting you directly with information about how to reset your password and restore access to your account.

We encourage all users to practice good password hygiene and enable two-factor authentication to protect your account.

These attacks often evolve, and we’re continuing to investigate and monitor for new attack vectors. Please keep an eye on our blog and on Twitter for pertinent updates, or contact Support if you have any questions.

“Open source everything you can:” Advice from open source experts at CodeConf LA

On June 27-29, join us at the Avalon Theater in Los Angeles for CodeConf 2016, where experts in open source systems will take the stage to share projects, practices, and programs with you.

In anticipation of this year’s event, we’ve asked several of our speakers how and why they contribute to open source, their creative processes, and how to drive change within an organization. Check out their responses below for some inspiration, and make sure to grab a ticket while they last.

Nadia Eghbal
Q: How do you see the open source industry and/or community evolving over the next few years?

“As open source hits the mainstream, we'll see deeper interest in the human side of things, with a focus on collaboration, improving workflows, and diverse skill sets like documentation and design.”

John Feminella
Q: What advice would you give to leaders who have been put in charge of driving open innovation at their companies?

“One of my favorite philosophical thought puzzles is the ship of ‘Theseus’. If you keep replacing different parts of a ship until everything is different than the original, at what point is it a new ship? A related but more relevant question for businesses is: how do you know you're making your ship better?

Innovation needs to be paired with a way of measuring or understanding the improvement that occurred. Otherwise it's probably only going to improve things by serendipity. And it can't be done in isolation: it needs to come from continuous improvement at all levels of the organization: engineering, functional business units, information security, IT operations, project management, testing, and so on.”

Anjuan Simmons
Q: Why do you contribute to free and open source software?

“I contribute to free and open source software because I believe in the principles of the original movement that sought to distribute publicly available source code under a license. Namely, that the most stable, secure, and flexible software can only come from a diverse community of developers and that the best practices of software development can only be distilled and distributed through the open collaboration of this community. Free and open source software is the best way to truly optimize software development.”

Cedric Williams
Q: What advice would you give to leaders who have been put in charge of driving open innovation at their companies?

“Create a pull request culture. Mentorship is driven by empathy, learning, and a need to share knowledge. Foster that in your organization.”

Emily Xie
Q: How does working with open source shape your ideas about what you like to create?

“The transparency of open source is amazing. With access to the underlying code, you are empowered with both the ability to understand how a given piece of open source software operates and to contribute back. Not only that but the learning opportunities are incredible; you can examine how a repository evolves over time in response to user feedback and gain exposure to the various coding techniques and styles of your peers—which of course inspires and informs what you yourself create with code.”

Mike McQuaid
Q: What advice would you give to leaders who have been put in charge of driving open innovation at their company?

“Open source everything you can. Ask what you can’t open source rather than the opposite. Start development in the open rather than open-sourcing large existing projects.”

About CodeConf LA

CodeConf LA is an annual three-day event dedicated to the open source community. This year’s conference is packed with sessions and celebrations focused on systems engineering projects, practices, and programs in the open source community. We'll explore topics ranging from systems programming practices to operating applications at scale across more than 30 sessions, lightning talks, and workshops.

For more information on workshops and for the complete CodeConf LA schedule, check out codeconf.com or stay tuned on Twitter.

Git 2.9 has been released

The open source Git project has just released Git 2.9.0, with a variety of features and bug fixes. Here's our look at some of the most interesting new features:

Faster and more flexible submodules

In the last release, we showed you how to use the --jobs=<N> option to fetch submodules in parallel, which can be a real time saver.

$ git fetch --recurse-submodules --jobs=4

Now you can also use the --jobs option when cloning or updating submodules:

$ git clone --recurse-submodules --jobs=4 ...
$ git submodule update --jobs=4 ...

If you always want submodules to be processed in parallel, you can set the submodule.fetchJobs config option. [source]

There are also some new conveniences for specifying how you want your submodule clones and fetches to behave. Git will now pass command-line configuration options down to submodules commands. So if you need to set a one-off variable for all of your submodule fetches, you can do so with git -c http.proxy=... clone --recursive. In the last release we mentioned how Git LFS can use -c config to speed up the initial checkout. Now it can apply the same trick to cloning submodules. Similarly, you can pass --shallow-submodules to git clone to have it make shallow clones of all of your submodules. [source, source, source]

Beautiful diffs

If you've used Git, you've probably looked at a lot of diffs. Most of the time the diff shows exactly what you did: changed some lines, added some new ones, or took some away. But because Git generates the diff only from seeing the "before" and "after" states of your files, sometimes the way it shows the changes can be pretty confusing. For example, look at this diff that adds a new loop to an existing function:

diff --git a/foo.rb b/foo.rb
index 64bb579..a2b5573 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,10 @@ module Foo
   def finalize(values)

     values.each do |v|
+      v.prepare
+    end
+
+    values.each do |v|
       v.finalize
     end
 end

The author probably didn't write the loop as two out-of-order halves. But because the outer lines of the old and new loops are the same, it's equally valid to attribute the lines either way (it's tempting to say that the problem can be solved by always starting the added lines at the top, but that only fixes this case; you'd have the opposite problem if the new loop were added after the old).

In 2.9, Git's diff engine learned a new heuristic: it tries to keep hunk boundaries at blank lines, shifting the hunk "up" whenever the bottom of the hunk matches the bottom of the preceding context, until we hit a blank line. The result shows what the author actually wrote in this case:

diff --git a/foo.rb b/foo.rb
index 64bb579..a2b5573 100644
--- a/foo.rb
+++ b/foo.rb
@@ -2,6 +2,10 @@ module Foo

   def finalize(values)

+    values.each do |v|
+      v.prepare
+    end
+
     values.each do |v|
       v.finalize
     end

Ah, much better. This new heuristic is still experimental, and may change in the future, or even become the default. For now, you can enable it with the --compaction-heuristic option on the command line, or by setting diff.compactionHeuristic in your git config. [source, source]

But maybe the minutae of diff hunk alignment isn't your thing (it's OK, we all have our niche interests). Let's talk about colors.

You probably already know that Git can colorize its diff output, and you can even customize the colors yourself. But there are also scripts that will filter Git's output and change it even further. For instance, there's a diff-highlight script that will put an extra emphasis on the changed part of a line:

diff --git a/foo.rb b/foo.rb
index bff273..9741ad8 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,6 +1,6 @@
 module Foo

   def output
-    puts "hello, world!"
+    puts "goodbye, world!"
   end
 end

There are a few ways to make use of this script, but the simplest is to configure Git to filter your diffs whenever it's showing them in a pager:

$ git config pager.log 'diff-highlight | less'
$ git config pager.show 'diff-highlight | less'
$ git config pager.diff 'diff-highlight | less'

That covers almost everything, but there's one spot missing: diffs shown by the interactive patch-staging tool (you are using interactive staging, right?). In Git 2.9, you can now ask it to filter the diffs it shows through any script you like:

$ git config interactive.diffFilter diff-highlight

Phew, with that set you can avoid the horror of ever seeing an unhighlighted diff again. [source]

And if you really want to go nuts, check out the diff-so-fancy project, which plugs in in the same way. These diffs are so fancy, you'll pop your monocle.

Testing all the commits with rebase -x

If you're a neat freak when it comes to commit history, you may have used Git's interactive rebase. It's great for fixing commit messages, or squashing, splitting, or reordering commits. But at it's heart, interactive rebase is really just a recipe of instructions to follow: pick this commit, then squash that one, now edit the message on this one, and so on.

What many people don't know is that you can insert any command you like into the instruction sheet, and Git will run it at the appropriate time, stopping the run only if the command fails. This makes it perfect for testing each commit in a series. The rebase stops at the first buggy commit, allowing you to fix it, re-run the tests, and amend the commit before continuing. If your project does commit-by-commit review, polishing your commits like this (rather than lumping on bug fixes at the end) is a great way to be kind to your reviewers. Rather than complain about your bugs in the early commits only to find them fixed later on, they get to see more directly the changes you propose, in a logical flow that builds towards the final goal.

Of course, writing out exec make test for each commit in your instruction sheet gets pretty tedious. That's why git rebase supports a -x option to add it for each commit, and as of this release, -x implies -i. And because rebase already defaults to your @{upstream} tracking branch, testing a full branch is as easy as:

$ git rebase -x 'make test'
Executing: make test
  Result: OK
Executing: make test
  Result: FAIL
make: *** [test] Error 2
Execution failed: make test
You can fix the problem, and then run

        git rebase --continue

Oh no, a bug! We can fix it up and continue on our way:

$ hack hack hack
$ make test
  Result: OK
$ git commit -a --amend
$ git rebase --continue
Executing: make test
  Result: OK
Successfully rebased and updated refs/heads/your-branch.

And now our perfect result is ready to be shared. [source]

Git Tidbits (Gitbits? Tidgits?)

  • The git describe command gives a human-readable (but still uniquely identifiable) name to commits. In its --contains mode, it finds a tag that contains a given commit, which makes the names it generates a good shorthand for "about when did this commit get released?". Older versions of Git looked for the topologically "closest" tag, but this could sometimes produce counter-intuitive results when newer tags had been merged in. Git 2.9 has a new heuristic that is much easier to explain: pick the oldest tag that contains the commit, and describe the path between them in the shortest way possible. [source]

  • If you're a fan of ASCII art (and let's be honest; who isn't?), you'll be pleased to know that git log will now expand tabs in commit messages to account for its 4-space indentation. That turns messy and broken alignment like this:

    $ git log
    commit 8d7fca1d690ff2ffb678dc00fbca1954df5e5b90
    Author: Mu-An Chiou <muan@users.noreply.github.com>
    Date:   Mon Sep 23 09:21:03 2013 +0900
    
             _____
             ╲    ╲
             │    │
             │    │                      ___________________________
             └─#──┘    ########           /                           |
               ##     ##~ ~ ~ ##       /                           |
             #####    ##########     <   My circuits are frazzled!  |
             #####    ##########       \                      |
              ###  #######╱╱#######     \___________________________|
               |  / ####╱╱ HUBOT ##\               .
            \/  ##╱╱########### \                   .
                ╱╱############   |                 .
                 #############  ###
                 #############  ####
                    ######      ####
                     ###     XX
                      ##
                      #
    

    into this:

    $ git log
    commit 8d7fca1d690ff2ffb678dc00fbca1954df5e5b90
    Author: Mu-An Chiou <muan@users.noreply.github.com>
    Date:   Mon Sep 23 09:21:03 2013 +0900
    
             _____
             ╲    ╲
             │    │
             │    │                      ___________________________
             └─#──┘    ########         /                           |
               ##     ##~ ~ ~ ##       /                            |
             #####    ##########     <   I have expanded your tabs! |
             #####    ##########       \                            |
              ###  #######╱╱#######     \___________________________|
               |  / ####╱╱ HUBOT ##\                .
                \/  ##╱╱########### \               .
                    ╱╱############   |              .
                     #############  ###
                     #############  ####
                        ######      ####
                         ###         XX
                          ##
                          #
    

    Oh, and you can use it for serious things like tables and diagrams, too. [source]

  • Rename detection is now enabled by default for diffs. You may have heard that Git doesn't record renames. It's true! Git infers on the fly when a file has been renamed by looking for similarities between the contents of the old and new files. This feature, which has existed since the early days of Git, is now enabled by default. [source]

  • You can now specify a custom path for hooks. Git calls hook scripts to allow you to implement custom policy or actions when certain events occur. These hook scripts are found inside the .git directory of each repository, making them a pain to manage if you have a standard set of hooks for all of your repositories. Now you can store the hooks in one place and point all of the repositories at them with the new core.hooksPath config. [source]

  • The git-p4 tool can now map p4 users to Git identities, as well as record p4 job information in the commit messages. Thanks to git-p4 and other tools, you don't have to forego the joy of using Git as a client, even if the project you're working on uses Perforce (or SVN, or Hg, or CVS, or...). [source, source]

The rest of the iceberg

That's just a sampling of the changes in Git 2.9. Check out the the full release notes for the complete list.

CodeConf LA: the full lineup of sessions and workshops is now available

CodeConf LA June 27-29

From Rust and Raft to data and design, the full schedule for CodeConf LA is now live on codeconf.com. In addition to the main event, we are hosting hands-on, 90-minute workshops led by experts in InnerSource, Neo4j, and Git. Admission is included in your CodeConf LA pass, but space is limited—RSVP to save yourself a seat. If you don't have a ticket yet, pick one up today, and sign up for the workshop(s) of your choice.

Workshop topics

Transitioning to Innersource
June 27th 10:30-12:00pm, lead by Cedric Williams, PayPal
InnerSource applies the lessons learned from large-scale distributed open source projects to proprietary engineering. Benefits include increased delivery velocity, smoother collaboration, and higher-quality development.

This workshop examines the factors that keep software teams from collaborating effectively, explores the model of development used for Apache Software Foundation projects, and discusses ways to bridge the two approaches. You’ll learn practical guidelines and business justifications for building InnerSource practices in your organization, as well as some antipatterns to watch out for.

Experience with developing software in larger and/or older organizations and is recommended.

Demolitions and Dalí: Web Dev and Data in a Graph Database
June 27th 1:15-2:45pm, lead by Nick Doiron, The Asia Foundation
Neo4j is a NoSQL graph database based on links between records. This workshop uses Python code samples to walk through two real-world examples of linked data, including designing a graph database from scratch, for art and artists at the Museum of Modern Art, and analyzing demolition data by processing road network data from OpenStreetMap.

Dissecting Git’s Guts
June 27th 3:00-4:30pm, lead by Emily Xie, Recurse Center
How does Git work? We’ll use Git’s plumbing commands to dissect the underlying structures that constitute Git and discuss how it is essentially structured as a Merkle DAG.

In doing so, we’ll solidify our conceptual understanding of Git, exploring questions such as: How does Git store our information? What is at the heart of a branch? What is actually happening when you do a Git checkout? Or a reset? Why is data (almost) never lost in Git?

Details

Each workshop is 90-minutes long and will take place on June 27th, the day before CodeConf begins, at the W Hollywood’s rooftop Loft. Your CodeConf LA ticket grants you access to any of these sessions.

About CodeConf LA

CodeConf LA is an annual three-day event dedicated to the open source community. This year’s conference is packed with sessions and celebrations focused on systems engineering projects, practices, and programs in the open source community. We'll explore topics ranging from systems programming practices to operating applications at scale across more than 30 sessions, lightning talks, and workshops.

For more information on workshops and for the complete CodeConf LA schedule, check out codeconf.com or stay tuned on Twitter.

HTTPS for GitHub Pages

Millions of people rely on GitHub Pages to host their websites and millions more visit these websites every day. To better protect traffic to GitHub Pages sites, as well as to encourage the broader adoption of HTTPS across the internet, GitHub Pages now officially1 supports HTTPS for all <username>.github.io sites. HTTPS provides a layer of encryption that prevents others from snooping on or tampering with traffic to your Pages site.

You can now visit *.github.io sites using HTTPS and configure HTTPS enforcement for your site. With HTTPS enforcement enabled, any HTTP requests to your github.io site will be transparently redirected to HTTPS.

GitHub Pages HTTPS

Starting next Wednesday (June 15, 2016, 12pm PDT), HTTPS enforcement will be required for all new GitHub Pages sites. To enable HTTPS enforcement for your existing *.github.io site, visit the settings page for your site's repository. Check out the Pages HTTPS documentation for more information.

1 You have been able to request Pages sites over HTTPS for some time, but we refrained from officially supporting it because the traffic from our CDN to our servers wasn't encrypted until now.

Celebrate Pride with GitHub

Celebrate Pride with GitHub

Pride month is here, and we have a few LGBTQ-focused festivities lined up to celebrate. This year, we're hosting our annual Pride party, releasing brand new Pridetocat t-shirts, and marching in the San Francisco Pride Parade.

T-shirts

This year's special edition Pridetocat and Transtocat shirts will hit the OctoShop on June 20. With 400 sold, last year's tees raised more than $10,000 in proceeds donated to Lesbians Who Tech, Maven, and Trans*H4CK. We hope you'll enjoy the new shirts just as much and help us support grassroots LGBTQ organizations working in the Bay Area.

Party

Date: Monday, June 20
Time: 5:30pm-9:00pm
Location: GitHub HQ

Celebrate Pride with us at GitHub HQ. Meet up with old friends, make new ones, and learn about some of the great things happening in the LGBTQ community at our annual Pride Party. You can swing by to purchase a Pridetocat t-shirt, learn about the ways GitHub is being used to benefit the LGBTQ community, and hear from a few speakers to be announced later this month.

This event is open to all LGBTQ-identified folks and allies. Register to join in.

Patchwork

Date: Wednesday, June 22
Time: 7:00pm-10:00pm
Location: GitHub HQ

Learn Git and GitHub at a special LGBTQ edition of Patchwork. No coding experience is needed to participate in this free, hands-on workshop with support and talks from GitHubbers and special guests from the LGBTQ community. Everyone is welcome to join.

Register now or take a moment to learn more about our Patchwork events.

March

Date: Sunday, June 26
Time: 10:30am-end
Location: Downtown San Francisco

This all culminates in the annual San Francisco Pride Parade on Sunday, June 26. This year, we are so excited to march in the Pride Parade along with our friends at Salesforce to support our LGBTQ Hubbers and to celebrate San Francisco's diverse community. We hope to see you all there!

Improvements to Notification Emails

We've rolled out several changes to our email notifications. Now you have more ways to filter your email notifications and each email will contain more information about why you received it.

Updates to the footer

image 2016-05-26 at 2 15 55 pm

The footer of every email now indicates why you've received a specific correspondence. It contains the same subscription reasons that are available on GitHub.com—for example, whether you or your team were directly mentioned.

If you no longer want to follow a thread, you can mute any new conversations directly from the email. (Note that this will only work for email clients configured to receive HTML emails).

Notification reason as the CC email address

image 2016-05-26 at 2 13 45 pm

In addition, the same notification reasons exist as a CC email address. This should help with labelling and filtering emails you receive for services like GMail and iCloud that don't support filtering by our X-GitHub-Reason header.

Our Help documentation provides a full list of the subscription reasons.


We hope these changes enhance your email notification experience!

Something went wrong with that request. Please try again.