Gerrit Git Review with Jenkins CI Server Last week, I published a piece on Gerrit and Jenkins about how I saw the future of distributed development teams. It got a fair number of views and positive comments (both off- and on-line) so I followed through with my promise to record a demo of using all the systems together. This uses Gerrit, combined with Jenkins CI and the Gerrit Trigger Plugin. Gerrit Git Review with Jenkins CI Server from Alex Blewitt on Vimeo. Instead of the turn-of-the-century approach to attaching Git patches to Bugzilla, Eclipse needs to get off the wait-and-see bandwaggon and jump onto Gerrit. Although I didn't explicitly make mention of it in the video, the other advantage of using Gerrit to store code reviews is that anyone can pull down the code review in-situ in the repository at any time. Oh, and if you're wondering, the graphical countdown timer is Naughty Step, an app I wrote so that my kids would know how long they have to go when they were naughty, hence the name.
StGIT Wiki: StGIT Tutorial Introduction StGIT is a Python application that provides functionality similar to quilt (i.e. pushing/popping patches to/from a stack) using GIT instead of 'diff' and 'patch'. StGIT stores its patches in a GIT repository as normal GIT commit objects. StGIT is not an SCM interface on top of GIT. StGIT is available for download at . This tutorial assumes you are already familiar with GIT. Basic Operation Help For a full list of StGIT commands: stg --help For help on individual subcommands: stg <cmd> (-h | --help) Repository initialisation In stand-alone mode, StGIT is used in conjunction with a GIT repository that is already initialised (using 'git-init-db'). Any branch in a GIT repository may be managed by StGIT. To initialise an existing GIT branch to be managed by StGIT, cd into the top of your GIT repository, check out the branch you'd like to manage with StGIT, and type: stg init You can switch between GIT branches with: stg branch [<branch name>] stg clean stg status
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
Set Up Git If you've found yourself on this page, we're assuming you're brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. Download and Install Git At the heart of GitHub is an open source version control system (VCS) called Git*. *If you don't already know what Git is, take a crash course. Download and install the latest version of Git. Use the default options for each step. Warning: Do not use PuTTY if you are given the option. Set Up Git Now that you have Git installed, it's time to configure your settings. Now that you have Git installed, it's time to configure your settings. Now that you have Git installed, it's time to configure your settings. Now that you have Git installed, it's time to configure your settings. Need a quick lesson about TerminalTerminalGit Bashthe command line? Code blocks like those on this page are part of a scripting language called Bash. was installed with Git called Git Bash. Input Email
Git User’s Manual (for version 1.5.3 or newer) This chapter covers internal details of the git implementation which probably only git developers need to understand. It is not always easy for new developers to find their way through Git’s source code. This section gives you a little guidance to show where to start. A good place to start is with the contents of the initial commit, with: $ git checkout e83c5163 The initial revision lays the foundation for almost everything git has today, but is small enough to read in one sitting. Note that terminology has changed since that revision. Also, we do not call it "cache" any more, but rather "index"; however, the file is still called cache.h. If you grasp the ideas in that initial commit, you should check out a more recent version and skim cache.h, object.h and commit.h. In the early days, Git (in the tradition of UNIX) was a bunch of programs which were extremely simple, and which you used in scripts, piping the output of one into another. Next step: get familiar with the object naming. Voila.
Get Started with Git If you’re a designer or developer, you’ve probably heard about Git, and you might know that it has become immensely popular, especially among the open source community. Though it may seem cryptic at first, this version control system could change the way you work with text, whether you’re writing code, or a novel. Article Continues Below This article covers why version control is important, how to install the Git version control system, and how to get started with your first repository. Why do I need version control? While it may be obvious that large development teams should have sophisticated code-management systems to track releases and bugs, and to avoid stepping on each others’ toes, it might not be immediately clear why individuals would need version control—especially designers or writers. But take a look at a site like Wikipedia, which is built around collaborative user content editing. With Git, though, you can do much more. No more circus file naming#section2 It’s working!
stashing your changes committed 10 Jan 2009 Stashing is a great way to pause what you’re currently working on and come back to it later. For example, if you working on that awesome, brand new feature but someone just found a bug that you need to fix. git add . Or add individual files to the index, your pick. git stash And boom! git stash apply You can also do multiple layers of stashes, so make sure to use git stash list To check out all of your current ones. git stash apply stash@{1} You can also easily apply the top stash on the stack by using (Thanks jamesgolick!) git stash pop A note with this command, it deletes that stash for good, while apply does not. git stash drop <id> Or delete all of the stored stashes with: git stash clear
Git Book - Distributed Workflows Unlike Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects. In centralized systems, every developer is a node working more or less equally on a central hub. In Git, however, every developer is potentially both a node and a hub — that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to. This opens a vast range of workflow possibilities for your project and/or your team, so I’ll cover a few common paradigms that take advantage of this flexibility. I’ll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each. Centralized Workflow In centralized systems, there is generally a single collaboration model—the centralized workflow. Figure 5-1. Integration-Manager Workflow Figure 5-2. Figure 5-3.
Basic Branching and Merging Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps: Do work on a web site.Create a branch for a new story you’re working on.Do some work in that branch. At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following: Switch to your production branch.Create a branch to add the hotfix.After it’s tested, merge the hotfix branch, and push to production.Switch back to your original story and continue working. Basic Branching First, let’s say you’re working on your project and have a couple of commits already. You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. $ git checkout -b iss53 Switched to a new branch "iss53" This is shorthand for: $ git branch iss53 $ git checkout iss53 You work on your web site and do some commits. $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' Basic Merging Note
Fast Version Control System Documentation Reference Reference Manual The official and comprehensive man pages that are included in the Git package itself. Quick reference guides: GitHub Cheat Sheet | Visual Git Cheat Sheet Book Pro Git The entire Pro Git book written by Scott Chacon and Ben Straub is available to read online for free. Videos See all videos → External Links The External Links section is a curated, ever-evolving collection of tutorials, books, videos, and other Git resources.
ignoring files committed 19 Jan 2009 We don’t need Git to version everything in our projects, be it compiled source, files with passwords, or temporary files that editors love to create. Usually keeping stuff out of your VCS’ hands is a task that is hard to manage and annoying to set up. Not with Git! Using the .gitignore file along with some other options, we’re going to learn how to set up per-project and per-user ignores. The easiest and simplest way is to create a .gitignore file in your project’s root directory. Here’s a basic .gitignore: $ cat .gitignore # Can ignore specific files .DS_Store # Use wildcards as well *~ *.swp # Can also ignore all directories and files in a directory. tmp/**/* Of course, this could get a lot more complex. Two things to keep in mind with ignoring files: First, if a file is already being tracked by Git, adding the file to .gitignore won’t stop Git from tracking it. git config --global core.excludesfile ~/.gitignore
3 Reasons to Switch to Git from Subversion « markmcb Dozens of articles outline the detailed technical reasons Git is better than Subversion, but if you’re like me, you don’t necessarily care about minor speed differences, the elegance of back-end algorithms, or all of the hardcore features that you may only ever use once. You want to see clear, major differences in your day-to-day interaction with software before you switch to something new. After several weeks of trials, Git seems to offer major improvements over Subversion. These are my reasons for jumping on the Git bandwagon. Let’s start with a few assumptions for the scenarios we’ll walk through: you’re one of many developers for a projectall changes going into production must first be peer-reviewedyou all use simple GUI text editors like TextMate or an equivalentyou have 4 features that you’re working that are due soon Let’s get to work. Endless, Easy, Non-File-System-Based, Local Branches Note the key advantages Git offered in each step: Stashing Temporary Work Conclusion