6.0. Repository

What is a code repository?

A code repository serves as a centralized platform that supports collaboration in software development. It offers tools for version control, managing contribution guidelines, and establishing automation workflows. The key elements defining a code repository include the host platform, the owner (which can be an individual or an organization), and the repository name. For example, a project might be identified by a URL such as https://github.com/fmind/mlops-python-package where additional details on project specifics or documentation could be appended.

Popular code repositories include GitHub, GitLab, and Bitbucket, each providing features tailored to different collaboration needs and complexities. GitHub is renowned for its robust support for public repositories, while GitLab and BitBucket are preferred by both private and public entities. Moreover, cloud providers like Google Cloud Platform, Azure, and AWS offer integrated code repository for public and private organizations.

Why do you need to configure a code repository?

Share your code with others: Code repositories facilitate easy sharing of projects, promoting collaborative development and feedback.
Reference your project: They provide a stable environment for hosting your code, ensuring it is always accessible and traceable.
Setup collaboration: Code repositories support multiple developers working on the same project simultaneously without conflict, utilizing features such as branches and pull requests.

Configuring a code repository is essential for both organizational and personal projects, as it secures projects from being confined to a single machine and enhances collaboration, security, and reliability.

Which information should you provide in a code repository?

On the repository's main page, you should include:

Name: Use a concise and descriptive name to clearly identify your project.
Description: Provide a detailed description outlining the project's purpose, scope, and functionality.
Tags: Employ tags to help categorize your repository under relevant topics, facilitating easier discovery based on certain technologies or functionalities.

Maintain organizational consistency by following any existing naming conventions which might include team names or technical stacks. For example, forecasting-bikes-ml includes the team name (forecasting), project domain (bikes), and tech stack (machine learning). Such conventions avoid collisions if another teams want to create a bikes project, or if the same team wants to used another technology stack (e.g., spark for data processing).

Commits, branches, and tags are essential for version management and ensuring changes are recorded and retrievable. Commits are useful for logging new changes, branches for isolating work during development, and tags for organizing project releases.

Creating a Commit

A git commit represents a snapshot of your project's history at a particular point in time. Here are the steps to create a commit using Git:

Modify your files or add new ones within your project directory.
Stage the changes you want to include in your commit by running:
```
git add <filename>
```
To add all changes in the directory, you can use:
```
git add .
```
Check the status to see what changes are staged for the next commit:
```
git status
```
Commit the staged changes by running:
```
git commit -m "Your commit message"
```

Here, replace "Your commit message" with a brief description of what changes were made in this commit.

Creating a Branch

A git branch allows you to develop features, fix bugs, or safely experiment with new ideas in a contained area of your repository.

Switch to the branch from which you want to base your new branch (commonly the main branch):
```
git checkout main
```
Create and switch to a new branch by running:
```
git checkout -b <branch-name>
```
Replace <branch-name> with a descriptive name for your branch, such as feat/add-login.

Creating Tags

A git tag is used to mark specific points in repository history as important, typically for release versions.

Check your commit history to find the commit to which you want to attach a tag:
```
git log
```
Create an annotated tag on your current commit by running:
```
git tag -a <tag-name> -m "Your tag message"
```
Replace <tag-name> with your version or release identifier, such as v1.0.0, and "Your tag message" with a description of what this tag represents.
Push the tag to your remote repository:
```
git push origin <tag-name>
```

What is the best method to clone a code repository?

To clone a repository, you can use either HTTPS or SSH, with SSH being the preferred method due to its security benefits. SSH does not require credential re-authentication for each push or pull operation, unlike HTTPS.

To create an SSH key:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

After generating the SSH key, add it to your repository host account settings. It's crucial to remember never to share your private SSH key as it serves as your secure credential. Always keep it confidential. You can identify the public key, which is safe to share, by its .pub file extension. For instance, if your private key is named id_rsa, your public key will be named id_rsa.pub and this is the key you upload to your repository host for authentication.

To clone a repository with SSH (recommended):

git clone git@hostname:user/repository.git

To clone a repository with HTTPS:

git clone https://hostname/user/repository.git

Is it possible to restrict the visibility of a code repository?

You can adjust the visibility of your code repository to be either public or private:

Public repositories are accessible to everyone and are ideal for open-source projects.
Private repositories are only accessible to specific individuals or teams and are suitable for sensitive or proprietary projects.

Choose the visibility setting that best aligns with your project needs and organizational policies.

What is the difference between forking and branching a code repository?

Forking a repository involves creating a complete copy of the repository under your account, enabling you to work independently without affecting the original repository. Branching creates a separate line within the same repository, allowing for isolated development that can be merged back into the main code base later.

Forking is typically used when public collaborators wish to develop their versions of a project, whereas branching is suited for ongoing collaboration within the same project direction, recommended for both public and private organizational use.

Is it possible to setup automation at the repository level?

Automation can be effectively implemented at the repository level through the use of webhooks, third-party apps, and integrations. These tools can help automate tasks such as testing, deployment, and integration workflows, which enhances productivity and ensures consistency across operations.

Webhooks: Webhooks can be configured to trigger automated workflows in response to events within the repository, such as pushes, pull requests, or merges. For example, a webhook could trigger an automated build or test in a continuous integration system whenever code is pushed to a repository.
Third-party apps: Many third-party applications are available on platforms like GitHub Apps or GitLab Integrations that can be used to extend the functionality of your repository. For instance, applications like CircleCI, Travis CI, or Jenkins can be integrated for continuous integration and continuous deployment (CI/CD) pipelines. Another popular choice is SonarQube, which can be integrated for automatic code quality reviews.
Integrations: Most repository platforms offer a range of built-in integrations that connect with other tools and services. For example, GitHub can integrate directly with project management tools like Jira or Trello to link commits and pull requests to tasks. Similarly, it can integrate with deployment platforms like Heroku or AWS, enabling automatic deployments when changes are made to specific branches.

How can you protect the code of the main branch?

To safeguard the integrity of your main branch, you can implement branch protection rules. These might include requirements for pull request reviews, status checks before merging, and restrictions on who can push to these crucial parts of your repository, ensuring all changes are thoroughly checked.

Navigate to Your Repository Settings: Go to your repository on GitHub, click on "Settings," and then select "Branches" from the sidebar.
Add Branch Protection Rules: Click on "Add rule" in the "Branch protection rules" section. Enter the name of the branch you want to protect, typically main or master.
Configure the Protection Rules:
- Require pull request reviews before merging: This setting requires one or more reviews before a contributor can merge changes into the protected branch, which helps ensure that code is reviewed and approved by other team members.
- Require status checks to pass before merging: Enabling this ensures that all required CI tests pass before the branch can be merged, which is crucial for maintaining code quality and functionality.
- Include administrators: You can enforce these rules on repository administrators as well, ensuring that all changes, regardless of who makes them, undergo the same level of scrutiny.
- Restrict who can push to matching branches: This setting allows you to specify which users or teams can push to the branch, adding an additional layer of security.
Save Changes: Once configured, save the changes to enforce the rules on the branch.