Remote Features

Content

Remote Features#

The portfolio of tools offered by different remote services varies between providers. However, some features are nearly universal. and can be roughly described as follows:

Universal Features#

Feature	Description
Repository Hosting	Stores Git repositories in the cloud, making them accessible from anywhere.
Web Interface	Provides a user-friendly web interface for managing repositories, viewing commit history, and tracking issues.
Collaboration Tools	Facilitate team collaboration with features like pull requests, code reviews, and issue tracking.
Access Control	Manages permissions and access levels to ensure only authorized users or teams can make changes.
Continuous Integration/Continuous Deployment (CI/CD)	Integrates with CI/CD tools to automate testing and deployment processes.
Backup and Recovery	Offers backup solutions to protect against data loss and provide recovery options.

Web Interface#

Most features that remote hosting platforms offer are accessible via a web interface, which exposes not just their specific features but also offers visualizations for specific functions. Web interface provide:

Web interface provide access to remote features and visualization of a variety of ’s own features

Regarding visualizations for features, we provide some specific links to these views for our Weekend Out exercise repository that resides both on GitHub and on GitLab.

Feature	GitLab Link	GitHub Link
Current State
Commits
Branches
History Overview
Tags

Collaboration Tools#

Issues#

(or Issues for )

Issues document and track tasks, bugs, thoughts, questions, and any kind of work that needs to be addressed in a repository.

An issue allows to document all planned changes, discovered bugs, questions related to the repository, etc. It is a genuine piece of information tied to a repository and useful in project management, especially in collaborative projects involving multiple developers or an entire community.

Different types of issues:

Bug
Feature requests
Tasks
Documentation

Generally, issues tend to have the following properties:

Not all / issue Issues are actually issues

Generally, any problem, question, or proposition that needs to be addressed can be documented in an issue.

Property	Description
Description	Each issue has a title and a description section that outlines the problem (expected and actual behavior), task (e.g., steps to reproduce), or an enhancement (e.g., a new feature, potential ideas or solutions to fix a bug).
Assignees	Issues can be assigned to specific team members to clarify tasks and responsibilities and facilitate project management.
State	To track progress on an issue, generally they can have two states “open” (still to be resolved) and “closed” (issue has been resolved).
Labels	Issues can be categorized using labels, e.g., “bug”, “documentation”, etc., to help organize and prioritize work.
News Feed	Issues provide an activity or news feed, that displays any related changes (e.g. commits) and that anyone with can access and write comments to offer insights, feedback, and exchange ideas on how to resolve an issue.
Milestone	Issues can be grouped under Milestones and be integrated into an overarching planning, even between repositories for some remote services.

Merge/Pull Requests#

Merge Request () or Pull Request () are formal request by a developer to have their code changes merged from one branch into another branch.

Merge/Pull Requests typically relate to one or serveral Issues.

In contrast to Issues that focus on documenting any kind of task that needs to be addressed, Merge/Pull requests are designed to document actual changes in a repository. However, this leads to a rather obvious relation between Issues and Merge/Pull Requests:

Drafts are a thing!

Many remote services know the concept of a draft Merge/Pull request. With a draft Merge/Pull Request you might create the request even much before the implementation is completed. This can be useful to group related issues and discuss the implementation with other team members early on.

Property	Description
Source Branch	The branch containing the new changes that will be merged into the target branch (e.g., main or develop).
Target Branch	The branch where the changes are merged into, typically the main or develop branch.
Description	Each Merge/Pull Request has a title and a brief description outlining the changes made in the branch. It can also contain specific keywords ( or ), such as to close a specific issue once the request is accepted.
Assignee(s)	Merge/Pull Request can be assigned to specific team members to clarify responsibilities and facilitate project management.
Reviewer(s)	One or several members of the repository assigned to review the changes and provide feedback. Typically, a reviewer should be very familiar with the parts of the target branch that are affected by the changes.
State	To track progress on an Merge/Pull Request, generally it can have three states “open” (still to be merged), merged (the request has been accepted and the source branch was merged into the target branch) an “closed” (the request was denied).
Labels	Issues can be categorized using labels, e.g., “bug”, “documentation”, etc., to help organize and prioritize work.
News Feed	Issues provide an activity or news feed, that displays any related changes and that anyone can access and write comments to offer insights, feedback, and exchange ideas on how to resolve an issue.
Milestone	Identical to issues, Merge/Pull Requests can be grouped under milestones and be integrated into an overarching planning, even between repositories for some remote services.

In a collaborative project, it is a useful tool for:

Review code changes before merging
Discuss changes and suggest improvements
Testing code to ensure changes don’t break the project or the overall workflow.
Approve code changes or workflow (by one or several developers).

Pull / Merge Request workflow:

Create branch
Commit changes (any work done on the branch)
Push branch into remote repository

¹Some IDEs offer a direct way to create a Pull / Merge Request from within the IDE. E.g. for Visual Studio Code, there is the GitHub Pull Requests and Issues extension or the GitLab Workflow extension.

Create Pull / Merge Request to propose the changes from the source to the target branch ¹ ¹Some IDEs offer a direct way to create a Pull / Merge Request from within the IDE. E.g. for Visual Studio Code, there is the GitHub Pull Requests and Issues extension or the GitLab Workflow extension.
Review and Feedback, requesting additional changes as needed
Rebase or merge target branch to include its most recent state
Automated Testing run to ensure the changes don’t introduce bugs or other problems
Approval
Merge changes into target branch

Milestones#

A collection of Issues and Merge/Pull Requests to facilitate project management.

Property	Description
Description	Title and a short description that outline what this milestone is about.
Start Date	The date when work on the milestone is expected to begin.
Due Date	The target date by which the milestone should be completed.
Related Objects	Several lists including related Issues and Merge/Pull Requests, helping to track progress and contributions towards achieving the milestone.

Labels#

Allow to categorize and organize Issues and Merge/Pull Requests in a repository, helping developers to prioritize and track work more effectively.

Labels are a great help for prioritizing, categorizing and navigate through Issues and Merge/Pull Requests. On some remote service providers, Labels can be reused between repositories leading to a consistent labeling between repositories.

One thing that should be noted, is that Labels do not exist in and so they have absolutely nothing in common with Tags in .

Create scoped Labels

Joining a property and state with :: into a single label, like priority::medium

Property	Description
Name	A clear and concise name for the label that describes its purpose (e.g., “bug”, “enhancement”, “documentation”).
Color	A color associated with the label, used for visual identification and organization within the project.
Description	Optional detailed explanation of what the label represents, providing context for when to use it.

Activity Tracking#

A News Feed \(\neq\) history

Activity-tracking is a feature of remote service platforms such as GitHub and GitLab, and not a concept itself. “News Feeds” might contain parts of the history, but not vice-versa.

One of the key services offered by GitHub, GitLab, and other platforms, is tracking and providing a full record in an organized way of all the changes beyond the commits history provided in . It’s much more than just keeping a list of changes, it includes a full history of what happened, when it happened, and why it happened.

Tracking activities is available both for Issues and Merge/Pull Requests and is reported in the attached “News Feed” that can also be used for commenting. Despite the automated activity tracking it is also possible to manually create links between Issues and/or Pull/Merge Requests simply by pasting their URL as a comment in some News Feed.

By means of this automated tracking, the complete life-cycle is documented which can drastically facilitate collaboration and documentation, as these “News Feeds” effectively turn into a digital logbook.

Key advantages:

Clarity and Transparency: understand what has been done in a repository, why and by whom, even after months or years.

Every time something in the project is changed GitHub/GitLab records:
- What changed, i.e. the actual lines of code;
- Why it changed through issue tracking and pull requests:
- Who changed it
Accountability and Responsibility: tracking who made changes and why makes it easier and faster to address problems.
Collaboration and Communication: the full history of changes ensures everyone is on the same page, even in teams working remotely or in different time zones. The Pull/Merge Request system encourages discussions and reviews within a team or a wider community.
Continuous learning and preventing mistakes: with a record of every issue, change, and discussion, new users or future developers can look back and learn why certain decisions were made, what worked and what didn’t, or how similar problem were solved, which in turn allows for better informed decision-making in the future.
Gather Contextual Information: extending with contextual information facilitates the identification of a previous healthy state or breaking changes in dependencies thus making it easier to recover from mistakes, quickly identify or even prevent bugs introduced by external changes.
Efficiency and Trust-Building: keep track of an open discussion directly where the changes are made, makes it easier to find information and builds trust (vs. long-chains of e-mails and endless meetings).

News Feed ⚡ History#

The or News Feed provides a broad overview of recent activities, the History provides a detailed and structured view of the project’s evolution. Both tools help to track changes, discuss ideas, understand references to related topic (issues, merge/pull requests, etc.) and make project management and collaboration more efficient.

News Feed#

The News Feed provides a high-level overview of activities in the repositories. It includes updates such as new commits, pull requests, issues, and comments. This feed is useful for quickly catching up on recent changes and interactions within the project but also for getting a sense of the project’s overall activity and progress. Additionally, it can help you stay informed about the work being done by other contributors and provide opportunities for collaboration and feedback.

History#

History, on the other hand, offers a detailed view of the changes made to your codebase locally and remotely. It provides a chronological record of commits, branches, merges, and other actions that have occurred throughout the project’s history. By using commands like git log, you can visualize the commit history in a concise and graphical format. This is particularly useful for understanding the sequence of changes and how different branches and merges have evolved over time. It also allows you to navigate through the project’s history, compare different versions of the code, and identify the changes that have been made by you and other contributors without the need for a web interface. This can be helpful for debugging issues, reverting changes, and understanding the context of specific commits.

Compared to the News Feed, it does not provide real-time updates or notifications about recent activities and interactions.

A Note on Collaboration#

Clearly not just but also related remote services aim to facilitate collaboration. They provide an extensive toolset that should not be overlooked, even when working on your own.

A big part of collaboration is documentation and most collaboration tools provide some form of standardisation to it, be it in the form of Issues, Merge/Pull Request, Labels, or alike. Thus, when it get to such tools, we recommend to embrace the following ides:

You’re always collaborating, whether with colleagues or your past and future selves!

Access Control#

This is a crucial feature remote services provide and is handled somewhat somewhat differently between remote service providers, unfortunately.

We will discuss this feature in some more detail in the section Organizing Projects but in short:

Remote services like GitLab and GitHub, not only allow repository owners to grant access to hosted repositories, but they also offer:

fine-grained access control over content, functions and actions,
controlled access at an organizational level across multiple repositories,
the ability to further distribute access rights,
protection for specific resources (e.g protected main branch), and
automated access control though integration with enterprise identity providers.

Continuous Integration & Continuous Deployment (CI/CD)#

It is likely that you stumbled over the term 🌟CI/CD🌟 before, but it might not be very clear what this term actually means and why it should matter also for non-software developers.

In fact we consider it of such general relevance in the context of remote services that we dedicate an entire course, ci-cd-workflows (or simply Part 3), in our series using-git-in-academia to this subject.

We recommend to follow Part 3 to learn more about CI/CD, but in short:

CI & CD both refer to automation procedures that perform certain tasks whenever some events occur.

Continuous Integration relates to automated procedures, like tests, that are triggered whenever some changes are to be integrated into a repository.

Continuous Deployment (or sometimes Delivery) on the other hand refers to automated procedures that are run whenever the content of a repository should be put to use.