Version control
Working with branches

Working with branches

Branching enables you to work with your peers without one affecting one other's body of work. For example, you can develop a new feature in one branch while one of your colleagues fixes a bug in another branch.

Create a branch

Create a new branch using the Git interface

Switch between branches

Switch between branches using the Git interface

Branch naming conventions

By having a clear and understandable naming scheme for your branches, you can:

  • Quickly understand the purpose of a branch.
  • Identify which branches are associated with which features, bugs, or tasks.
  • Make it easier to navigate the project and find relevant work.

While the specific conventions can vary between teams or projects, good branch naming conventions generally share these attributes:

  1. Descriptive: A good branch name will instantly tell you what is being worked on in that branch.
  2. Consistent: Consistency makes it easier to understand what each branch is for, especially for newcomers to the project.
  3. Short: Shorter names are easier to type and to read.
  4. Punctuated for readability: This typically means using hyphens, underscores, or slashes to separate different parts of the name.

Here's an example of a branch naming convention that embodies these principles:

  • feat-<feature-name> for new features (e.g., feat-user-authentication).
  • fix-<bug-name> for bug fixes (e.g., fix-login-issue).
  • docs-<topic> for documentation (e.g., docs-installation-instructions).
  • test-<testing> for anything related to testing (e.g., test-user-model).

Merge branches

In software development, teams often work on new features or bug fixes in isolated branches. Once the work is complete and tested, it's important to integrate these changes back into the main codebase. Merging facilitates this integration without losing the history of changes.

The following is the process to execute a merge command in Y42:

Merge branches

Merging best practices

  • Keep your branch up-to-date with the main branch.

Regularly pull changes from the main branch into your working branch to ensure a simpler merge process and fewer conflicts.

  • Commit often.

This makes it easier to understand what changes led to a bug or conflict.

  • Write meaningful commit messages.

This helps others understand what changes were made and why. More on writing meaningful commit messages in this section.

Branch update notifications and one-click merge

When working on a branch in Git, staying up-to-date with the latest changes in the main branch is essential. Our new feature enhances this process by notifying you when your branch is behind and providing a simplified merge experience.

Notification when feature branch is behind main:

If your branch falls behind the main branch, you will receive an immediate notification. This notification is visually represented by a yellow icon, showing how many commits you are behind.

Feature branch behind main.

Feature branch behind main.

Clicking on this icon allows you to merge the latest changes from the main branch into your feature branch with a single click.

Conflict indication

In cases where merging the main branch into your feature branch would result in conflicts, the notification icon turns red:

Feature branch conflict with main.

Feature branch conflict with main.

Clicking on this red icon will prompt you to confirm the merge conflict resolution and choose which version to keep (incoming (main) or current).

Feature branch conflict resolution confirmation

Feature branch conflict resolution confirmation

Feature branch conflict resolution.

Feature branch conflict resolution.

Resolving merge conflicts

A merge conflict in Git arises when two branches have made changes to the same part of a file and Git cannot automatically reconcile the differences during a merge. This conflict results in Git marking the file as "unmerged," necessitating manual resolution. When a conflict occurs, Git outputs a message to indicate the issue, and the affected files are marked accordingly.

To manage these conflicts, open the marked files and look for the conflict markers (<<<<<<<, =======, and >>>>>>>). These markers delineate the differing segments of code. You'll need to manually edit the file to resolve these conflicts by choosing which changes to keep, modify, or remove, and then saving the file.


<<<<<< HEAD
CREATE TABLE dim_products AS SELECT * FROM products;
CREATE TABLE dim_products AS SELECT * FROM staging.products;
>>>>>> conflicting-branch

All the lines between the <<<<<< HEAD and ======= exist in the current branch which the HEAD ref is pointing to.

All the lines betweeen ======= and >>>>>> conflicting-branch is content in the new branch that is trying to merge.

Once you've decided how to resolve each conflict, you can save the file, and commit it to complete the merge.

Resolve merge conflicts


How often should I create new branches in my project?

It's a good practice to create a new branch whenever you're starting work on a new feature, fixing a bug, or making any significant code changes. This helps isolate your changes and makes it easier to manage your codebase.

When should I merge branches?

You typically merge branches when work on a feature, fix, or improvement is complete. The changes are then integrated back into the main or development branch to be included in the next release or iteration of the software.