Java Bien! » Serverless Continuous Integration with Git. “Why use a continuous integration server?” That’s the question we ask at Algodeal. Having spent years preaching for each team to use a CI server, we installed and used Hudson since the very beginning of the project. However, it’s been months since anybody looked at the Hudson dashboard. Every commit breaks the build. And you now what? How did it happen? The key problem is the time wasted maintaining and Hudson server.
Why spend time maintaining a CI server when we could make sure the tests pass locally before pushing to the shared repository? Decision made: Small aware team + quick build = Bye Hudson! We’ve got a situation As time goes by, as tests are written, a build gets slower and slower. Arms race We don’t want to push broken code. Reduce the build duration Let’s do a root cause analysis instead of putting money and time on a build farm.
Here comes Git At Algodeal, we choose git a year ago. With git, it’s a piece of cake. What about the consistency? The ultimate private build? Yes. . #! Git Community Book. Pro Git Book. Chapter 4. Branch Wizardry. Chapter 4. Branch Wizardry Instant branching and merging are the most lethal of Git’s killer features. Problem: External factors inevitably necessitate context switching. A severe bug manifests in the released version without warning. The deadline for a certain feature is moved closer. A developer whose help you need for a key section of the project is about to leave. In all cases, you must abruptly drop what you are doing and focus on a completely different task.
Interrupting your train of thought can be detrimental to your productivity, and the more cumbersome it is to switch contexts, the greater the loss. But cloning still entails copying the whole working directory as well as the entire history up to the given point. Solution: Git has a better tool for these situations that is much faster and more space-efficient than cloning: git branch. With this magic word, the files in your directory suddenly shapeshift from one version to another. In some directory: and hey presto! $ git branch. Git: fetch and merge, don’t pull « Mark’s Blog. This is too long and rambling, but to steal a joke from Mark Twain Blaise Pascal I haven’t had time to make it shorter yet.
There is some discussion of this post on the git mailing list, but much of it is tangential to the points I’m trying to make here. One of the git tips that I find myself frequently passing on to people is: Don’t use git pull, use git fetch and then git merge. The problem with git pull is that it has all kinds of helpful magic that means you don’t really have to learn about the different types of branch in git. Mostly things Just Work, but when they don’t it’s often difficult to work out why. What seem like obvious bits of syntax for git pull may have rather surprising results, as even a cursory look through the manual page should convince you. The other problem is that by both fetching and merging in one command, your working directory is updated without giving you a chance to examine the changes you’ve just brought into your repository.
Branches Types of Branches … or: