Learn the basics before you work with Git
Git can scale with complex environments, but more conflicts can arise. Get the Git basics down before your developers use forks or branches for projects.
While many work with Git in a single-user environment, the version control system scales for larger environments. So, how does a user, developer or administrator take that single-user experience and scale it?
Git provides availability and support for every major OS, which makes it the go-to for many programmers. Git's functionality is identical across Mac, Linux and Windows.
The developers of Git designed the version control system for distributed use, without the need to actively change how tasks are done. Git enables each programmer to store a complete copy of the source code locally. Whereas some early version control systems enabled developers to check out only part of the source code. When developers work with a complete copy of the source code, the work doesn't stop if the centralized repository becomes unavailable.
But, before they work with Git, users and groups must understand how branches and forks work. As environments grow in size and complexity, programmers must take caution not to step on each other's toes.
Git fork vs. branch
In software development, a fork creates a new, independent copy of the source code tree. Sometimes developers need a completely new and independent copy of the data. When they fork a Git project, it becomes its own separate instance, which means it will not alter the original project. Open source developers often create forks when they want to use an existing code base for a new project.
By default, when a developer uses git add, git commit and other commands, they commit to his local copy. In a merge, they push into the master, centralized version of the code with git push origin master.
A merge conflict occurs when two developers change the same file and have different versions of the code. At this point, each developer could use git pull -- not to be confused with a pull request -- to download changes into their local copies. Programmers can use the git rebase option to synchronize all the changes together into one developer's copy, which makes this copy the master after they upload and integrate the changes.
Go on, Git
Git serves as the foundation of many version control products, including GitHub, GitLab, Bitbucket and Azure DevOps Server. Developers commonly use these tools for source code management and to keep track of changes in a multitude of files.
Here are several examples of Git-based tools:
- GitHub is a web-based service for version control, which hosts Git. GitHub offers the same version control and source code management functionalities as Git, but with additional features, such as access control and task management. Microsoft acquired GitHub in June 2018.
- GitLab is a web-based Git repository manager, which is based on Git version control. GitLab expanded to cover DevOps lifecycles after originally being created for source code management.
- Bitbucket, an Atlassian product, is a web-based version control repository based on Git. Bitbucket supports cloud, data center and Bitbucket Server deployments. Bitbucket Server, also based on Git, enables users to perform Git-like actions, such as code merges.
- Azure DevOps Server is a source code management that supports Git and its Team Foundation Version Control. Similar to GitLab, Azure DevOps covers the broad DevOps application lifecycle.
Branch out
More commonly, developers use branches when they work on significant changes. For example, a team might work on a new feature independently of ongoing bug fixes and other projects.
Branches are independent from working changes on the main trunk, also called the master. Developers can work with Git independently on these branches, then merge them back into the master at a later date. This structure enables multiple independent projects to commence without affecting day-to-day code changes.
Developers can then check their changes back in via a merge request, which is essentially a peer review of the update. After approval, the team pulls the merge request back into the main trunk.
Some conflicts can occur between the different branches and trunks, but they are typically easy to resolve. Branches are logically separate from the main trunk, but that can't stop a pull request from another developer before approval.
Teamwork makes Git work
Before IT teams work with Git, they must understand and agree on a set of standards, as developers can use -- or abuse -- Git in many different ways. Without an agreed-upon set of practices, the team could run into data loss, if not outright chaos when it attempts to pull unapproved changes. Gitflow is one set of best practices an organization can use in distributed environments.
Management, in particular, must make some decisions about the version control system. A team can choose between hosted or self-hosted versions of Git, each with different pros and cons. For most users, hosted Git provides all the necessary resources.
When it comes to security, administrators should protect accounts with two-factor authentication and manage repository access with Active Directory, which GitHub has started to support in a limited fashion.
