Understanding the Git Workflow

If you don’t understand the motivation behind Git’s design, you’re in for a world of hurt. With enough flags you can force Git to act the way you think it should instead of the way it wants to. But that’s like using a screwdriver like a hammer; it gets the job done, but it’s done poorly, takes longer, and damages the screwdriver. Consider how a common Git workflow falls apart. Create a branch off Master Work Merge it back to Master when done Most of the time this behaves as you expect because Master changed since you branched. Unfortunately, your feature branch contained checkpoint commits, frequent commits that back up your work but captures the code in an unstable state. So you add a new rule: “When you merge in your feature branch, use –no-ff to force a new commit.” Then one day you discover a critical bug in production, and you need to track down when it was introduced. You narrow the bug to a single file. Rethinking Revision Control Revision control exists for two reasons. The Workflow

A successful Git branching model » nvie.com Note of reflection (March 5, 2020)This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.This is not the class of software that I had in mind when I wrote the blog post 10 years ago. Why git? For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. The main branches ¶ develop

GitSvnComparison Note: This page is currently a work in progress. It started out as a private email to someone who currently uses Subversion. I decided to make it available and try to extend it further. I'll remove this comment when the page is improved. :) -- Shawn Pearce See the discussion page for further comments Although this page is hosted on a Git-specific Wiki it tries to provide a fair and unbiased comparison of Git and Subversion to help prospective users of both tools better evaluate their choices. Git is much faster than Subversion Subversion allows you to check out just a subtree of a repository; Git requires you to clone the entire repository (including history) and create a working copy that mirrors at least a subset of the items under version control. Distributed Nature Git was designed from the ground up as a distributed version control system. In a centralized VCS like Subversion only the central repository has the complete history. Access Control Branch Handling Consequently Git:

Why You Should Switch from Subversion to Git You may have heard some hubbub over distributed version control systems recently. You may dismiss it as the next hot thing, the newest flavor of kool-aid currently quenching the collective thirst of the bandwagon jumpers. You, however, have been using Subversion quite happily for some time now. It has treated you pretty well, you know it just fine and you are comfortable with it – I mean, it’s just version control, right? You may want to give it a second look. Now, this isn’t really a how-to on Git – I won’t be going over a lot of specific commands or get you up and running. The Advantages of Being Distributed Git is a distributed version control system. Now, this gives you a couple of immediate advantages. The other implicit advantage of this model is that your workflow does not have a single point of failure. The final advantage I’ll cover of distributed systems are the incredible workflows that are now available to you. Lightweight Branches: Frictionless Context Switching In Closing…

EGit Primary Links EGit About This Project EGit is an Eclipse Team provider for the Git version control system. The EGit project is implementing Eclipse tooling on top of the JGit Java implementation of Git. Committers Andrey Loskutov Benjamin Muskalla (Tasktop) Chris Aniszczyk (Twitter) Christian Halstrick (SAP) Dani Megert (IBM) Dariusz Luksza (CollabNet) Gunnar Wagenknecht (Ageto) Jens Baumgart (SAP) Kevin Sawicki (GitHub) Konrad Kügler Laurent Goubet (Obeo) Mathias Kinzler (SAP) Matthias Sohn (SAP) Mik Kersten (Tasktop) Mykola Nikishov Remy Suen (IBM) Robin Rosenberg (Dewire) Robin Stocker Shawn Pearce (Google) Stefan Lay (SAP) Tomasz Zarna (Tasktop)