DOCSLIB.ORG

Pragmatic Version Control Using Git.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Pragmatic Version Control Using Git.Pdf Prepared exclusively for Trieu Nguyen Download at Boykma.Com What readers are saying about Pragmatic Version Control Using Git Pragmatic Version Control Using Git is an excellent guide to getting you started with Git. It will teach you not only how to get yourself started but also how to cooperate with others and how to keep your history clean. Pieter de Bie Author, GitX If you are thinking of using Git, I highly recommend this book. If you are not using a version control system (and code or create content on a computer), put the book down, slap yourself, pick the book back up, and buy it. Jacob Taylor Entrepreneur and Cofounder, SugarCRM Inc. Not only has this book convinced me that Git has something to offer over CVS and Subversion, but it has also showed me how I can benefit from using it myself even if I’m using it alone in a CVS/Subversion environment. I expect to be a full-time Git user soon after reading this, which is hard to believe considering this is the first distributed version control system I’ve ever looked at. Chuck Burgess 2008 PEAR Group Member Travis has done an excellent job taking a tricky subject and making it accessible, useful, and relevant. You’ll find distributed version control and Git much less mysterious after reading this book. Mike Mason Author, Pragmatic Version Control Using Subversion Prepared exclusively for Trieu Nguyen Download at Boykma.Com Pragmatic Version Control Using Git Travis Swicegood The Pragmatic Bookshelf Raleigh, North Carolina Dallas, Texas Prepared exclusively for Trieu Nguyen Download at Boykma.Com Many of the designations used by manufacturers and sellers to distinguish their prod- ucts are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragprog.com Copyright © 2008 Travis Swicegood. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmit- ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN-10: 1-934356-15-8 ISBN-13: 978-1-934356-15-9 Printed on acid-free paper. P2.0 printing, March 2009 Version: 2009-4-20 Prepared exclusively for Trieu Nguyen Download at Boykma.Com Contents Acknowledgments 9 Preface 10 Who’s This Book For? ....................... 11 What’s in This Book? ........................ 11 Typographic Conventions ..................... 13 Online Resources .......................... 13 I Welcome to the Distributed World 14 1 Version Control the Git Way 15 1.1 The Repository ........................ 16 1.2 What Should You Store? .................. 17 1.3 Working Trees ........................ 18 1.4 Manipulating Files and Staying in Sync ......... 18 1.5 Tracking Projects, Directories, and Files ......... 19 1.6 Tracking Milestones with Tags .............. 20 1.7 Creating Alternate Histories with Branches . 21 1.8 Merging ............................ 22 1.9 Locking Options ....................... 24 1.10 Next Steps .......................... 25 2 Setting Up Git 26 2.1 Installing Git ......................... 26 2.2 Configuring Git ....................... 31 2.3 Using Git’s GUI ....................... 33 2.4 Accessing Git’s Built-in Help ................ 34 Prepared exclusively for Trieu Nguyen Download at Boykma.Com CONTENTS 6 3 Creating Your First Project 36 3.1 Creating a Repository .................... 37 3.2 Making Changes ....................... 37 3.3 Starting to Work with a Project .............. 40 3.4 Using and Understanding Branches ........... 43 3.5 Handling Releases ...................... 44 3.6 Cloning a Remote Repository ............... 48 II Everyday Git 50 4 Adding and Committing: Git Basics 51 4.1 Adding Files ......................... 52 4.2 Committing Changes .................... 55 4.3 Seeing What Has Changed ................. 58 4.4 Managing Files ........................ 61 5 Understanding and Using Branches 65 5.1 What Are Branches? .................... 66 5.2 Creating a New Branch ................... 67 5.3 Merging Changes Between Branches ........... 69 5.4 Handling Conflicts ..................... 74 5.5 Deleting Branches ...................... 77 5.6 Renaming Branches .................... 78 6 Working with Git’s History 80 6.1 Inspecting Git’s Log ..................... 81 6.2 Specifying Revision Ranges ................ 82 6.3 Looking at Differences Between Versions . 85 6.4 Finding Out Who’s to Blame ................ 86 6.5 Following Content ...................... 88 6.6 Undoing Changes ...................... 91 6.7 Rewriting History ...................... 94 7 Working with Remote Repositories 100 7.1 Network Protocols ...................... 100 7.2 Cloning a Remote Repository ............... 103 7.3 Keeping Up-to-Date ..................... 104 7.4 Pushing Changes ...................... 105 7.5 Adding New Remote Repositories ............. 106 Report erratum Prepared exclusively for Trieu Nguyen this copy is (P2.0 printing, March 2009) Download at Boykma.Com CONTENTS 7 8 Organizing Your Repository 109 8.1 Marking Milestones with Tags ............... 110 8.2 Handling Release Branches ................ 112 8.3 Using Valid Names for Tags and Branches . 114 8.4 Tracking Multiple Projects ................. 115 8.5 Using Git Submodules to Track External Repositories . 116 9 Beyond the Basics 122 9.1 Compacting Repository History .............. 123 9.2 Exporting Your Repository ................. 124 9.3 Rebasing a Branch ..................... 125 9.4 Using the Reflog ....................... 128 9.5 Bisecting Your Repository ................. 131 III Administration 135 10 Migrating to Git 136 10.1 Communicating with SVN ................. 136 10.2 Making Sure git-svn Is Available ............. 140 10.3 Importing a Subversion Repository ............ 141 10.4 Keeping Up-to-Date with a Subversion Repository . 143 10.5 Pushing Changes to SVN .................. 145 10.6 Importing from CVS ..................... 146 11 Running a Git Server with Gitosis 147 11.1 Making Sure Dependencies Are Met ........... 148 11.2 Installing Gitosis ...................... 149 11.3 Creating Administrator Credentials ............ 149 11.4 Configuring the Server for Gitosis ............. 150 11.5 Initializing Gitosis ...................... 151 11.6 Configuring Gitosis ..................... 151 11.7 Adding New Repositories .................. 152 11.8 Setting Up a Public Repository .............. 154 11.9 Closing Thoughts ...................... 155 Report erratum Prepared exclusively for Trieu Nguyen this copy is (P2.0 printing, March 2009) Download at Boykma.Com CONTENTS 8 IV Appendixes 157 A Git Command Quick Reference 158 A.1 Setup and Initialization ................... 158 A.2 Normal Usage ........................ 159 A.3 Branches ........................... 160 A.4 History ............................ 162 A.5 Remote Repositories .................... 164 A.6 Git toSVN Bridge ...................... 165 B Other Resources and Tools 167 B.1 Extras Bundled with Git .................. 167 B.2 Third-Party Tools ...................... 168 B.3 Git Repository Hosting ................... 171 B.4 Online Resources ...................... 172 C Bibliography 174 Index 175 Report erratum Prepared exclusively for Trieu Nguyen this copy is (P2.0 printing, March 2009) Download at Boykma.Com Acknowledgments Although my name is on this book as the author, it is only here because of a long list of people. Please indulge me while I take a moment to thank them. Thanks to Dave Thomas and Andy Hunt for taking the chance on a new author. The entire team they’ve put together at Pragmatic Bookshelf is amazing. I owe a special thanks to my editor, the ever helpful Susannah Davidson Pfalzer. I would also like to thank all of those who offered me feedback on the book as it progressed through beta form. Especially helpful was the great team of technical reviewers: Chuck Burgess, Pieter de Bie, Stu- art Halloway, Junio Hamano, Chris Hartjes, Mike Mason, John Mertic, Gary Sherman, Jacob Taylor, and Tommi “Tv” Virtanen. Thanks also to the wonderful teams of developers and colleagues at SugarCRM and Ning who supported me while I wrote this book. Finally, I would like to thank my friends and family for their support and understanding while I wrote this book. My wonderful wife, Meg, put up with the late nights and “work weekends” with very little com- plaining. Without her support, and that from the rest of my friends and family, this book wouldn’t be here today. Prepared exclusively for Trieu Nguyen Download at Boykma.Com Preface Development teams around the globe are changing. They are dropping their clunky, old, centralized version control systems (VCSs) in favor of Git, which is a lightweight, distributed version control system (DVCS) and relative
Load more

Recommended publications
  • Pragmatic Version Control Using Subversion
    What readers are saying about Pragmatic Version Control using Subversion I expected a lot, but you surprised me with even more. Hav- ing used CVS for years I hesitated to try Subversion until now, although I knew it would solve many of the shortcom- ings of CVS. After reading your book, my excuses to stay with CVS disappeared. Oh, and coming from the Pragmatic Bookshelf this book is fun to read too. Thanks Mike. Steffen Gemkow Managing Director, ObjectFab GmbH I’m a long-time user of CVS and I’ve been skeptical of Sub- version, wondering if it would ever be “ready for prime time.” Until now. Thanks to Mike Mason for writing a clear, con- cise, gentle introduction to this new tool. After reading this book, I’m actually excited about the possibilities for version control that Subversion brings to the table. David Rupp Senior Software Engineer, Great-West Life & Annuity This was exactly the Subversion book I was waiting for. As a long-time Perforce and CVS user and administrator, and in my role as an agile tools coach, I wanted a compact book that told me just what I needed to know. This is it. Within a couple of hours I was up and running against remote Subversion servers, and setting up my own local servers too. Mike uses a lot of command-line examples to guide the reader, and as a Windows user I was worried at first. My fears were unfounded though—Mike’s examples were so clear that I think I’ll stick to using the command line from now on! I thoroughly recommend this book to anyone getting started using or administering Subversion.
    [Show full text]
  • Learn Python the Hard Way
    ptg11539604 LEARN PYTHON THE HARD WAY Third Edition ptg11539604 Zed Shaw’s Hard Way Series Visit informit.com/hardway for a complete list of available publications. ed Shaw’s Hard Way Series emphasizes instruction and making things as ptg11539604 Zthe best way to get started in many computer science topics. Each book in the series is designed around short, understandable exercises that take you through a course of instruction that creates working software. All exercises are thoroughly tested to verify they work with real students, thus increasing your chance of success. The accompanying video walks you through the code in each exercise. Zed adds a bit of humor and inside jokes to make you laugh while you’re learning. Make sure to connect with us! informit.com/socialconnect LEARN PYTHON THE HARD WAY A Very Simple Introduction to the Terrifyingly Beautiful World of Computers and Code Third Edition ptg11539604 Zed A. Shaw Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
    [Show full text]
  • Version Control 101 Exported from Please Visit the Link for the Latest Version and the Best Typesetting
    Version Control 101 Exported from http://cepsltb4.curent.utk.edu/wiki/efficiency/vcs, please visit the link for the latest version and the best typesetting. Version Control 101 is created in the hope to minimize the regret from lost files or untracked changes. There are two things I regret. I should have learned Python instead of MATLAB, and I should have learned version control earlier. Version control is like a time machine. It allows you to go back in time and find out history files. You might have heard of GitHub and Git and probably how steep the learning curve is. Version control is not just Git. Dropbox can do version control as well, for a limited time. This tutorial will get you started with some version control concepts from Dropbox to Git for your needs. More importantly, some general rules are suggested to minimize the chance of file losses. Contents Version Control 101 .............................................................................................................................. 1 General Rules ................................................................................................................................... 2 Version Control for Files ................................................................................................................... 2 DropBox or Google Drive ............................................................................................................. 2 Version Control on Confluence ...................................................................................................
    [Show full text]
  • Microservices and Monorepos
    Microservices and Monorepos Match made in heaven? Sven Erik Knop, Perforce Software Overview . Microservices refresher . Microservices and versioning . What are Monorepos and why use them? . These two concepts seem to contradict – why mix them together? . The magic of narrow cloning . A match made in heaven! 2 Why Microservices? . Monolithic approach: App 3 Database Microservices approach . Individual Services 4 DB DB Database Versioning Microservices . Code . Executables and Containers . Configuration . Natural choice: individual repositories for each service Git . But: • Security • Visibility • Refactoring • Single change id to rule them all? 5 Monorepo . Why would you use a monorepo? . Who is using monorepos? . How would you use a monorepo? 6 Monorepos: Why would you do this? . Single Source of Truth for all projects . Simplified security . Configuration and Refactoring across entire application . Single change id across all projects . Examples: • Google, Facebook, Twitter, Salesforce, ... 7 Single change across projects change 314156 8 Monorepos: Antipatterns User workspace User workspace 9 Monorepos – view mapping User workspace . Map one or more services . Users only access files they need . Simplified pushing of changes 10 What does this have to do with Git? . Git does not support Monorepos • Limitations on number and size of files, history, contributing users • Companies have tried and failed . Android source spread over a thousand Git repositories • Requires repo and gerrit to work with 11 How can we square this circle? https://en.wikipedia.org/wiki/Squaring_the_circle 12 Narrow cloning! . Clone individual projects/services . Clone a group of projects into a single repo 13 Working with narrowly cloned repos . Users work normally in Git . Fetch and push changes from and to monorepo .
    [Show full text]
  • Version Control – Agile Workflow with Git/Github
    Version Control – Agile Workflow with Git/GitHub 19/20 November 2019 | Guido Trensch (JSC, SimLab Neuroscience) Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 2 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 3 Motivation • Version control is one aspect of configuration management (CM). The main CM processes are concerned with: • System building • Preparing software for releases and keeping track of system versions. • Change management • Keeping track of requests for changes, working out the costs and impact. • Release management • Preparing software for releases and keeping track of system versions. • Version control • Keep track of different versions of software components and allow independent development. [Ian Sommerville,“Software Engineering”] Forschungszentrum Jülich, JSC:SimLab Neuroscience 4 Motivation • Keep track of different versions of software components • Identify, store, organize and control revisions and access to it • Essential for the organization of multi-developer projects is independent development • Ensure that changes made by different developers do not interfere with each other • Provide strategies to solve conflicts CONFLICT Alice Bob Forschungszentrum Jülich, JSC:SimLab Neuroscience 5 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich,
    [Show full text]
  • Distributed Revision Control with Mercurial
    Distributed revision control with Mercurial Bryan O’Sullivan Copyright c 2006, 2007 Bryan O’Sullivan. This material may be distributed only subject to the terms and conditions set forth in version 1.0 of the Open Publication License. Please refer to Appendix D for the license text. This book was prepared from rev 028543f67bea, dated 2008-08-20 15:27 -0700, using rev a58a611c320f of Mercurial. Contents Contents i Preface 2 0.1 This book is a work in progress ...................................... 2 0.2 About the examples in this book ..................................... 2 0.3 Colophon—this book is Free ....................................... 2 1 Introduction 3 1.1 About revision control .......................................... 3 1.1.1 Why use revision control? .................................... 3 1.1.2 The many names of revision control ............................... 4 1.2 A short history of revision control .................................... 4 1.3 Trends in revision control ......................................... 5 1.4 A few of the advantages of distributed revision control ......................... 5 1.4.1 Advantages for open source projects ............................... 6 1.4.2 Advantages for commercial projects ............................... 6 1.5 Why choose Mercurial? .......................................... 7 1.6 Mercurial compared with other tools ................................... 7 1.6.1 Subversion ............................................ 7 1.6.2 Git ................................................ 8 1.6.3
    [Show full text]
  • Scaling Git with Bitbucket Data Center
    Scaling Git with Bitbucket Data Center Considerations for large teams switching to Git Contents What is Git, why do I want it, and why is it hard to scale? 01 Scaling Git with Bitbucket Data Center 05 What about compliance? 11 Why choose Bitbucket Data Center? 13 01 What is Git, why do I want it, and why is it hard to scale? So. Your software team is expanding and taking on more high-value projects. That’s great news! The bad news, however, is that your centralized version control system isn’t really cutting it anymore. For growing IT organizations, Some of the key benefits Codebase safety moving to a distributed version control system is now of adopting Git are: Git is designed with maintaining the integrity considered an inevitable shift. This paper outlines some of managed source code as a top priority, using secure algorithms to preserve your code, change of the benefits of Git as a distributed version control system history, and traceability against both accidental and how Bitbucket Data Center can help your company scale and malicious change. Distributed development its Git-powered operations smoothly. Community Distributed development gives each developer a working copy of the full repository history, Git has become the expected version control making development faster by speeding up systems in many circles, and is very popular As software development increases in complexity, and the commit process and reducing developers’ among open source projects. This means its easy development teams become more globalized, centralized interdependence, as well as their dependence to take advantage of third party libraries and on a network connection.
    [Show full text]
  • The Software Heritage Graph Dataset: Public Software Development Under One Roof
    The Software Heritage Graph Dataset: Public software development under one roof Antoine Pietri Diomidis Spinellisy Stefano Zacchiroli Inria Athens University of Economics and Business University Paris Diderot and Inria France Greece France [email protected] [email protected] [email protected] Abstract—Software Heritage is the largest existing public software licence analysis and license compliance [14], [15]. archive of software source code and accompanying development However, many research studies are still being conducted on history: it currently spans more than five billion unique source significantly smaller subsets of the entire corpus of publicly code files and one billion unique commits, coming from more than 80 million software projects. available source code artifacts. This paper introduces the Software Heritage graph dataset: a The Software Heritage project [16], [17] aims at fixing this fully-deduplicated Merkle DAG representation of the Software gap, by collecting, preserving, and sharing the entire body Heritage archive. The dataset links together file content iden- of publicly available software source code, together with the tifiers, source code directories, Version Control System (VCS) associated development history, as it is captured by modern commits tracking evolution over time, up to the full states of VCS repositories as observed by Software Heritage during periodic version control systems (VCS)[18]. crawls. The dataset’s contents come from major development In this paper we introduce the Software Heritage Graph forges (including GitHub and GitLab), FOSS distributions (e.g., Dataset, a graph representation of all the source code artifacts Debian), and language-specific package managers (e.g., PyPI). archived by Software Heritage. The graph is a fully dedu- Crawling information is also included, providing timestamps plicated Merkle DAG [19] that links together: source code about when and where all archived source code artifacts have been observed in the wild.
    [Show full text]
  • Reproducible Research, Open Science Logging and Backing up Your Work Git Tips and Tricks, a Scientist Perspective
    Reproducible Research, Open Science Logging and backing up your work Git Tips and Tricks, a Scientist Perspective V. Danjean, A. Legrand, L. Stanisic University of Grenoble, CNRS, Inria Bordeaux June 7, 2016 Reproducible Research Webinar (Episode IV) 1 / 34 Foreword about the organization (1/2) There is currently a screencast of this seminar: https://mi2s.imag.fr/pm/direct The resulting video will be edited and available from GitHub that gathers all the information, slides, and resources: https://github.com/alegrand/RR_webinars/blob/master/README.org There is a few seconds delay between what we say and the screencast. We can have almost live interaction with other sites by using pad to comment and ask questions http://tinyurl.com/RRW-pad4 2 / 34 Foreword about the organization (2/2) No particular prerequisites: we will use command line and demo with a GUI Please install Git and SmartGit by following the instructions given on the RR_webinars GitHub page 1. General introduction plus basic Git usage( ≈ an hour) At any time, feel free to ask questions on the pad. Some of these questions may be ad- dressed "silently" by the other attendees, but do not hesitate to ask it out loudly for the remote ones 2. A short break 3. Slightly more advanced Git usage The actual part that is more devoted to practices favoring reproducible research Many other tutorials on Git but with a dierent perspective Introduction to Git internals by Scott Chacon (GitHub) Please. Stop Using Git by Matthew McCullough http://try.github.com/ http://git-scm.com/docs/gittutorial/
    [Show full text]
  • Free Software Needs Free Tools
    Free Software Needs Free Tools Benjamin Mako Hill [email protected] June 6, 2010 Over the last decade, free software developers have been repeatedly tempted by devel- opment tools that offer the ability to build free software more efficiently or powerfully. The only cost, we are told, is that the tools themselves are nonfree or run as network services with code we cannot see, copy, or run ourselves. In their decisions to use these tools and services – services such as BitKeeper, SourceForge, Google Code and GitHub – free software developers have made “ends-justify-the-means” decisions that trade away the freedom of both their developer communities and their users. These decisions to embrace nonfree and private development tools undermine our credibility in advocating for soft- ware freedom and compromise our freedom, and that of our users, in ways that we should reject. In 2002, Linus Torvalds announced that the kernel Linux would move to the “Bit- Keeper” distributed version control system (DVCS). While the decision generated much alarm and debate, BitKeeper allowed kernel developers to work in a distributed fashion in a way that, at the time, was unsupported by free software tools – some Linux developers decided that benefits were worth the trade-off in developers’ freedom. Three years later the skeptics were vindicated when BitKeeper’s owner, Larry McVoy, revoked several core kernel developers’ gratis licenses to BitKeeper after Andrew Tridgell attempted to write a free replacement for BitKeeper. Kernel developers were forced to write their own free software replacement: the project now known as Git. Of course, free software’s relationships to nonfree development tools is much larger than BitKeeper.
    [Show full text]
  • Branching Strategies with Distributed Version Control in Agile Projects
    Branching Strategies with Distributed Version Control in Agile Projects David Arve March 2, 2010 Abstract Branching strategies play an integral part in traditional software de- velopment. In Agile projects however branching is seen as the opposite to embracing change and therefor given little attention. This paper describes what branching strategies would support an agile workflow. It also describes how a distributed version control tool will fit better around these branching strategies then a centralized tool. This pa- per puts forth some original work on what branching strategies and team organization that fully takes advantage of a distributed version control tool. This paper aims to describe how a distributed version control can support agile teams with advanced branching strategies without slowing down or complicating the lightweight agile processes. 1 Introduction Software development is a process that produces a massive amount of highly complicated content. All of this content is produced by teams that range from just a few developers up to several thousands. It is obvious that this process needs to be highly coordinated. The coordination of this content is a part of Software configuration management (SCM). Traditionally this has been done by a centralized version control tool. [2] Branching strategies have not gained a lot of popularity in agile teams. [3] In recent years several new version control tools have emerged. These new tools break with the standard model of centralized version control (CVC) made popular by tools like CVS [9] and Subversion[6]. The new tools are based on a distributed model. Recent tools include Arch [5], Bazaar [8], BitKeeper [7] and Git [11].
    [Show full text]
  • An Introduction to Mercurial Version Control Software
    An Introduction to Mercurial Version Control Software CS595, IIT [Doc Updated by H. Zhang] Oct, 2010 Satish Balay [email protected] Outline ● Why use version control? ● Simple example of revisioning ● Mercurial introduction - Local usage - Remote usage - Normal user workflow - Organizing repositories [clones] ● Further Information ● [Demo] What do we use Version Control for? ● Keep track of changes to files ● Enable multiple users editing files simultaneously ● Go back and check old changes: * what was the change * when was the change made * who made the change * why was the change made ● Manage branches [release versions vs development] Simple Example of Revisioning main.c File Changes File Version 0 1 2 3 Delta Simple Example Cont. main.c 0 1 2 3 makefilemain.c 0 1 Repository -1 0 1 2 3 Version Changeset Concurrent Changes to a File by Multiple Users & Subsequent Merge of Changes Line1 Line1 Line1 Line1 Line2 UserA Line2 UserA Line3 Line2 Line3 Line2 Line4 Line3 UserB Line3 Line4 Line4 UserB Line4 Initial file UserA edit UserB edit Merge edits by both users Merge tools: r-2 ● kdiff3 Branch Merge ● meld r-4 Merge types: ● 2-way r-1 ● 3-way Revision Graph r-3 Some Definitions ● Delta: a single change [to a file] ● Changeset: a collection of deltas [perhaps to multiple files] that are collectively tracked. This captures a snapshot of the current state of the files [as a revision] ● Branch: Concurrent development paths for the same sources ● Merge: Joining changes done in multiple branches into a single path. ● Repository: collection of files we intend to keep track of.
    [Show full text]