Git Onboarding

Owned by ssiegl (Unlicensed)
Last updated: May 22, 2015 by Stefan Siegl
3 min read

Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system. It identifies the functional and physical attributes of software at various points in time, and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle.

Git benefits

Git is a distributed configuration management tool, meaning that each repository contains all snapshots (yeah snapshots, not differences!). That means you can do all operations you normally would have done remotely (check the history, create a branch, check-in) with your local repository. In fact this is the standard operation. Work on your local repository with all the functionality you loved from other tools (like subversion) and addition great features. If you are finished with your work or want to get the current state of the development of someone else, you can fetch this information into your repository or push your changes to the central repository respectively.

The best part: Git support branching and I really mean support branching, not as in Subversions idea of branching, which is more like "create branches as you like and have fun merging them together later one... bring some time and prepare for annoyance". Not to mention about CVS idea of branches which is something along the line of "Branch... hm... yeah you might do that. Merge... you might do that, too, but expect no help from me". Git's internal system is designed to make branching and merging easy and "less" painless.

Have you ever been implementing a functionality, changed a lot of file but are not yet finished and your senior tells you that there is a bug that needs to be fixed right now. With other tools you would have to store your changes "somehow". With Git you can simply tell Git that it should store them for you (or even create a branch from it), step back to your master, fix the bug, and jump back.

 

The following presentation is used as a basis for a Git workshop. It is not meant to be a replacement to all the books and other information that can be found. On the other side, it tries to give a rough overview of the differences between the central version control systems and the distributed ones. Furthermore, there are some pages trying to explain how Git works internally.

Who should read this?

Every developer of inspectIT should read this presentation and execute all the hands-on parts. This ensures that a basic understanding of the Git concepts, commands etc. is build up. After reading this presentation carefully, you should have no problems to answer the following questions:

  • What is the difference between Git and central version control systems
  • What does a DAG have to do with Git
  • What is the identifier for each commit, each object
  • How can I configure remote repositories, and how can I push/pull to/from these
  • How can I branch and merge locally
  • What is rebasing and how do I use it effectively
  • ...

Furthermore, the presentation contains at the end several pages to explain the new process in inspectIT with respect to JIRA, Gitorious, Hudson etc.