PUBLIC MARKS from Spone with tag git

Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review. You can use Danger to codify your teams norms. Leaving humans to think about harder problems. She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language. Over time, as rules are adhered to, the message is amended to reflect the current state of the code review.

GitFlow is probably the most popular Git branching model in use today. It seems to be everywhere. It certainly is everywhere for me personally - practically every project at my current job uses it, and often it's the clients themselves who have chosen it. I remember reading the original GitFlow article back when it first came out. I was deeply unimpressed - I thought it was a weird, over-engineered solution to a non-existent problem. I couldn't see a single benefit of using such a heavy approach. I quickly dismissed the article and continued to use Git the way I always did (I'll describe that way later in the article). Now, after having some hands-on experience with GitFlow, and based on my observations of others using (or, should I say more precisely, trying to use) it, that initial, intuitive dislike has grown into a well-founded, experienced distaste. In this article I want to explain precisely the reasons for that distaste, and present an alternative way of branching which is superior, at least in my opinion, to GitFlow in every way.

Version management with git makes branching and merging much easier than older versioning systems such as SVN. This allows a wide variety of branching strategies and workflows. Almost all of these are an improvement over the methods used before git. But many organizations end up with a workflow that is not clearly defined, overly complex or not integrated with issue tracking systems. Therefore we propose the GitLab flow as clearly defined set of best practices. It combines feature driven development and feature branches with issue tracking.

juste un petit guide pour bien démarrer avec git. no deep shit ;)

This page gives brief, visual reference for the most common commands in git. Once you know a bit about how git works, this site may solidify your understanding.

In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

Welcome to the Git version control system! Here we will briefly introduce you to Git usage based on your current Subversion knowledge. You will need the latest Git installed; There is also a potentially useful tutorial in the Git documentation.

Bugs Everywhere is a “distributed bugtracker”, designed to complement distributed revision control systems. By using distributed revision control as a backend for bug state, we gain several convenient features: * Bugs and code that live on branches are tracked together—when a branch is merged, both the code changes and bug changes that the branch contains are merged alongside each other. We no longer have to be confused about whether a fix that is applied to the development branch but not yet present in the production branch means that our bug is “fixed”. * Users can fully modify bug state while offline, unlike with many centralized bugtrackers. * When a user checks out your source code, she gets the current bug state for free. * We can still provide access to a friendly web interface for users—in this model, a web interface becomes just another client that merges with the main repository.