This article outlines the scale of that codebase and details Google's custom-built monolithic source repository and the reasons the model was chosen. Google uses a homegrown version-control system to host one large codebase visible to, and used by, most of the software developers in the company. This centralized system is the foundation of many of Google's developer workflows. Here, we provide background on the systems and workflows that make feasible managing and working productively with such a large repository. We explain Google's "trunk-based development" strategy and the support systems that structure workflow and keep Google's codebase healthy, including software for static analysis, code cleanup, and streamlined code review.

GitHub is the go-to place to host your open source projects, that much is well known. A lot of companies also use their paid plans to get the ecosystem around GitHub for their own code. Why would you want to use anything else? We took the decision to move away from GitHub and in the end we benefitted hugely!

Acts as a proxy for incoming webhooks between your Git hosting provider and your continuous integration server.

When a Git commit webhook is received, the repository in question will be mirrored locally (or updated, if it already exists), and then the webhook will be passed on to your CI server, where it can start a build, using the up-to-date local mirror.

This tutorial demonstrates how to apply changes made to a project hosted in one git repository onto a completely separate project in a different git repository: essentially, merging changes between two totally separate git repositories. If you don't use git, this will likely not interest you much.

The Collective Code Construction Contract (C4) is an evolution of the github.com Fork + Pull Model, aimed at providing an optimal collaboration model for free software projects. This is revision 1 of the C4 specification.

Ashish Kumar presents how Google manages to keep the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5,000 developers accessing the same repository.

A command-line tool that helps you clean up Git branches that have been merged into master.

In this post, I'm going to take a look at some common scenarios where you might want to "undo" a change you've made and the best way to do it using Git.

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day - often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.

There are a number of advantages to deploying so regularly. If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs. Little issues can be introduced, but then they can be fixed and redeployed very quickly. Normally you would have to do a ‘hotfix’ or something outside of the normal process, but it’s simply part of our normal process - there is no difference in the GitHub flow between a hotfix and a very small feature.

The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history:

* Removing Crazy Big Files * Removing Passwords, Credentials & other Private data

1–10 (34)   Next >   Last >|