What are GitHubs best practices

Version Management: An Introduction

This article describes what version control systems are, what problems they solve, and what terms you will come across in your day-to-day work with them, along with their meanings.

A world without versioning

Assume a project is implemented without version management and there is an error. To fix this bug, changes are made to the code of the project and, as is often the case, different approaches are tried until the right fix is ​​found. It happens that after several attempts you realize that something else is no longer working than what you actually want to fix, because a previous approach was not completely reversed before starting a new approach. So something has been forgotten that now affects the new approach.

And the whole thing will only get worse the more changes are made, as more can be forgotten until the project at some point no longer works and you don't know anymore how to restore the last working state is. If several people are also developing the project at the same time, this problem multiplies even further until one is more concerned with making agreements and fixing problems with changes that have not been reversed than with driving the actual development forward.

Solution approach and basic terms

To avoid this problem, tools are used, the main task of which is it Track changes in code automatically and by appropriately placed markings easy to undo again. The process of tracking changes with marked statuses is called Version management, the marked stands are called Commits and always receive a comment that explains the changes since the last highlighted status (since the last commit). This comment is called Commit message. The set of all marked statuses (commits) is the so-called History. A project that is tracked by a version control system is called a Repository.

A repository has one or more development branches that represent different work statuses in the project. These branches of development are called Branches, they can be thought of as different sets of commits that have a common base. A branch always has a name that is the default name of the first branch when creating a repository. Typically there is one or two main branchesthat reflect the current state of overall progress and that too any number of work brancheswhich each reflect an area of ​​further work that has not yet been completed.

A merge brings together changes in different branches.

When the work on a working branch is completed, the changes in it (the commits) are merged with the current overall progress (i.e. one of the main branches). The merging of branches (i.e. different amounts of commits) is called one Merge. Version control systems manage the changes in most cases fully automatic together to a common stand. An automatic merge cannot take place unless different changes have been made to the same places in the same files. There is a so-called Merge Conflict in front. In such a case, manual intervention is required, and the version management system conspicuously identifies the places to be merged in the code.

Working together and other terminology

Another simplification that version control systems offer in software development is that easy exchange of code in a team. This is usually done via a server that contains the shared status of the project - the so-called Remote server. Version control systems offer a function with which individual commits or entire branches (sets of commits) can be uploaded to the remote server. The process of uploading is called a Push. The opposite of this - downloading code from Remote server - is called Pull.

To keep local and server-side branches in sync, you should push and pull regularly.

In the joint work of a team, it should always be clear which functions the main branches have and how work branches are to be named. Our holistic proposal for this can be read in the later article GN010-0300. For the explanations in the following, the only main branch and every branch whose name begins with is a working branch:

The remote server usually runs in a service with a web interface, whereby GitHub.com, Bitbucket.org and GitLab.com are currently the most popular services. GitLab also has a Community Edition that can be installed on its own servers. In each of these services there is the option to create users and to assign read and write rights to them individually in projects. Individual branches can also be additionally protected, they are then named Protected Branch, which means you need additional rights to push or merge changes there.

The main branches (e.g. the branch) are typically protected. If a developer who completes a work branch (e.g.) wants to merge it with the overall progress (merge), he must ask another developer with appropriate rights to do this for him. This is done using a Merge requests via the web interface of the remote server service. Another developer with the appropriate rights can do this validate the change made in the working branch and possibly suggest corrections or make them yourself before doing the merge. Merge requests or individual code positions can be used for communication in the web interface Leave a Comment.

Which version control system?

The most common version control systems currently used are SVN, Git and Mercurial.

There are different version control systems with different goals and advantages and disadvantages (see comparisons here and here). The most widely used in software development today are Subversion (SVN for short), Git, and Mercurial. SVN is considered obsolete, especially since it relies on a central functionality, which makes working offline more cumbersome. Git and Mercurial, on the other hand, are decentralized version control systems that significantly improve the ability to work and manage projects separately through the use of local working copies.

Functionally, Git and Mercurial are definitely comparable with each other, but behind Git (mainly for historical reasons) there was always a significantly larger community, which is why over time there has been more and more dominant version control system has risen in our time. The widespread use, the many tools available and the Support on many services For project management, it is easy for us to recommend: Git is currently hard to ignore.

How can I just use Git?

Although Git is a command line tool and even a stable Git version is preinstalled on some systems (e.g. Macs), we guess App developers who otherwise have little to do with the command line from its use. Instead, we recommend using a good Git program with a user interface:

SourceTree allows the use of Git without a command line.

SourceTree is available for both Mac and Windows and is the program of our choice. It's free, quite clear, and supports all of the important work steps that are required in your daily work with Git. Installing Git also eliminates the need for SourceTree, as a current Git version already integrated is. In the next article (GN010-0150) we will go into detail about working with Git in SourceTree.

Related Links