background preloader

Git Book - Basic Branching and Merging

Git Book - 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. At this stage, you’ll receive a call that another issue is critical and you need a hotfix. Revert back to your production branch. Basic Branching First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10). Figure 3-10. 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 Figure 3-11 illustrates the result. Figure 3-11. You work on your web site and do some commits. $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' Figure 3-12. Now you get the call that there is an issue with the web site, and you need to fix it immediately. Figure 3-14. Figure 3-15.

Intro to Distributed Version Control (Illustrated) | BetterExpla Traditional version control helps you backup, track and synchronize files. Distributed version control makes it easy to share changes. Done right, you can get the best of both worlds: simple merging and centralized releases. Distributed? Nothing — read a visual guide to version control if you want a quick refresher. Centralized VCS emerged from the 1970s, when programmers had thin clients and admired “big iron” mainframes (how can you not like a machine with a then-gluttonous 8 bits to a byte?). Centralized is simple, and what you’d first invent: a single place everyone can check in and check out. This model works for backup, undo and synchronization but isn’t great for merging and branching changes people make. Sure, merging is always “possible” in a centralized system, but it’s not easy: you often need to track the merge yourself to avoid making the same change twice. A Few Diagrams, Please Other tutorials have plenty of nitty-gritty text commands; here’s a visual look. Core Concepts

Nick Farina - Git Is Simpler Than You Think It was about one year ago that we switched to Git. Previously, we used Subversion, through the Mac app Versions, which (rightly) holds an Apple Design Award. I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet. But I pressed forward. It might as well have printed PC LOAD LETTER. “Not currently on any branch?!” Maintenance Required Git is not a Prius. By now we all know how to drive Git. Did you know the top result for “git tutorial” is this manpage on kernel.org? So instead let’s pull over, open the hood up, and poke around. The Basics We’ll run through some basic commands to make a repository for our examples: ~$ mkdir mysite ~$ cd mysite ~/mysite$ echo "<title>All About Cats</title>" > index.html ~/mysite$ git init ~/mysite$ git add index.html ~/mysite$ git commit -m "First commit, added a title." Now we have a git repository with one file and one commit, that is to say, one “version”. With me so far? The Repository

Deploying with Capistrano - Guides - GitHub This article explains how to deploy with Capistrano 2.x. If you are using Capistrano 3.x, please refer to the current Capistrano documentation instead. To prepare your project for Capistrano, go into the root directory of that project and run capify: cd my_projectcapify . Set up SSH keys To be able to deploy, your server needs to be able to access your repos. Settings Here are the 5 most notable Capistrano config options (found in deploy.rb): default_run_options[:pty] = true # Must be set for the password prompt # from git to work set :repository, "git@github.com:user/repo.git" # Your clone URL set :scm, "git" set :user, "deployer" # The server's user for deploys set :scm_passphrase, "p@ssw0rd" # The deploy user's password Agent Forwarding If you're using your own private keys for git, you want to tell Capistrano to use agent forwarding with this command. Want to know more? Set Branch You need to tell cap the branch to checkout during deployment: set :branch, "master" Remote Cache Shallow Clone

list remote branches committed 13 Feb 2009 Sometimes you may need to figure out what branches exist on a remote repository so you can pull them down and check them out, merge them into your local branches, etc. If you’re using GitHub or gitweb to host your repository it’s usually easy to determine the branch names, but if you need to get them in general or for scripts it’s not exactly clear. UPDATE: The comments have enlightened me quite a bit…there seems to always be more than one way to skin a cat using Git. The easiest way is just to use the git branch commands’ various options. $ git branch * master $ git branch -a * master origin/1-2-stable origin/2-0-stable origin/2-1-stable origin/2-2-stable origin/3-0-unstable origin/HEAD origin/master $ git branch -r origin/1-2-stable origin/2-0-stable origin/2-1-stable origin/2-2-stable origin/3-0-unstable origin/HEAD origin/master So, once you know the name of the branch it’s quite simple to check them out.

Welcome - Bazaar Version Control 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. 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. You can continue to use a centralized workflow, with one central server that everyone pushes to and pulls from. Lightweight Branches: Frictionless Context Switching Becoming a Code Artist

Blog - SVN: Merging a Branch into Trunk This is more for my benefit than anything else, but someone might find this useful. Recently at work, I have taken on more responsibilities. Part of that includes branch control over a few web sites I work on. The source control program I am using is SVN and the source code is stored on a server with SSH access. Check out a copy of trunk: svn co svn+ Check out a copy of the branch you are going to merge: svn co svn+ Change your current working directory to “myBranch” Find the revision “myBranch” began at: This should display back to you the changes that have been made back to the point the branch was cut. That is it. Updated: June 18th, 2008 Steps 2-4 can be replaced by a remote log lookup: svn log --stop-on-copy svn+ My thanks to Samuel Wright for bringing that to my attention :-) Cutting a branch is a lot easier than merging a branch. That’s all there is to it.

An asymmetry between git pull and push « Mark’s Blog Although git is an excellent system, which has certainly changed my way of working for the better, occasionally one comes across an inconsistency that seems bizarre. In case you don’t want to read the whole of this post, the one sentence summary would be, “By default, git push origin will update branches on the destination with one with the same name on the source, instead of using the association defined by git branch --track, which git pull origin would use — the config option push.default can change this behaviour.” However, for a more detailed explanation, read on… Suppose someone has told you that they’ve pushed a topic branch to GitHub that they’d like you to work on. git checkout -t github/new-feature2 … which will create a branch in your repository called new-feature2 based on github/new-feature2, and set various config options to associate your new-feature2 branch with github/new-feature2. git checkout -t -b add-menu github/new-feature2 $ git pull github 1. 2. 2. 4.

Git - Fast Version Control System Git - SVN Crash Course 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. This page is not maintained anymore! The up-to-date version of this tutorial is the GitSvnCrashCourse page at the Git wiki. The copy below might be better edited and nicer to read, but is likely to contain some advices and commands that may not match the current best practices anymore. How to Read Me In those small tables, at the left we always list the Git commands for the task, while at the right the corresponding Subversion commands you would use for the job are listed. Before running any command the first time, it's recommended that you at least quickly skim through its manual page. Things You Should Know There are couple important concepts it is good to know when starting with Git. Repositories. Commiting That's it. Browsing Merging Going Remote

workspace • Git Cheatsheet • NDP Software stash workspace index local repository upstream repository status Displays: <br>• paths that have differences between the index file and the current <code>HEAD</code> commit, <br>• paths that have differences between the workspace and the index file, and <br>• paths in the workspace that are not tracked by git. diff Displays the differences not added to the index. diff commit or branch View the changes you have in your workspace relative to the named <em>commit</em>. add file... or dir... Adds the current content of new or modified files to the index, thus staging that content for inclusion in the next commit. add -u Adds the current content of modified (NOT NEW) files to the index. rm file(s)... Remove a file from the workspace and the index. mv file(s)... Move file in the workspace and the index. commit -a -m 'msg' Commit all files changed since your last commit, except untracked files (ie. all files that are already listed in the index). checkout files(s)... or dir reset HEAD file(s)... reset --hard

Version Control with Subversion How to get Gitorious running on your own server « Erik On Rails This is everything I’ve figured out so far about how to get Gitorious up and running on your own server. It’s not everything yet, but it’s a lot of stuff. OK, so first you want to install the dependencies. I think this are all of them, assuming you’ve installed the basic rails stuff: apt-get install librmagick-ruby libonig-dev gem install mime-types oniguruma textpow chronic BlueCloth Then make a place for Gitorious and download the code: mkdir /path/for/gitorious; cd /path/for/gitorious git clone cd mainline It’s a good idea at this point to read the HACKING file for informational purposes. The next thing we need to do is create a git user. adduser git Once we’ve created a user, we can create a place for your git repositories. mkdir /path/to/repos chown git:git /path/to/repos You are going to need to add your database settings and gitorious configuration. cp config/gitorious.sample.yml config/gitorious.yml nano config/gitorious.yml; What’s left to do:

Open Source Development With CVS Copyright © 1999, 2000 Karl Fogel <kfogel@red-bean.com> This document is free software; you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. This manual describes how to use and administer CVS (Concurrent Versions System). This is version 1.21 of this manual. Top Introduction This is a set of free, online chapters about using CVS (Concurrent Versions System) for collaboration and version control. These chapters are excerpted from a larger work called Open Source Development With CVS (published by The Coriolis Group, ISBN 1-57610-490-7). These chapters are released under the GNU General Public License. An Overview of CVS pserver

Related: