Github Flow

GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.

On this page, you'll find some useful information to interact with this repository.

Here are some benefits:

Simplicity: It's an easy-to-understand workflow that requires minimal command-line knowledge. This makes it accessible to contributors of all levels.

Collaboration: By using pull requests, team members can easily collaborate on the same feature. They can review, comment on, and merge changes.

Continuous Deployment: With GitHub Flow, you can deploy the main branch to production at any time. The main branch is always in a deployable state.

Isolation of Changes: Each new feature or bug fix is developed in its own *branch, which makes it easy to change between different tasks and keeps the *main branch free of incomplete work.

Integration of Changes: GitHub Flow encourages frequent merging. The main *branch is updated with merged pull requests, which triggers automated builds *and tests, ensuring issues are caught and addressed quickly.

Traceability: Each feature or fix is tied to a specific pull request, *providing a history of changes and making it easier to find out when and why a *change was made.

Automation: GitHub Flow works well with continuous integration tools. Tests *can be run automatically whenever a pull request is created or updated, helping *to ensure that the main branch is always in a good state.

Code Review: Pull requests allow other developers to give feedback on the *code before it's merged into the main branch. This can lead to better code *quality and shared understanding of the codebase.

Github branching

Learn about branching and merging with diagrams on the following link:

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Github documentation

The following link by Github describes the flow and philosophy behind it:

https://docs.github.com/en/get-started/using-github/github-flow

Summary:

• Checkout the main branch, and pull the latest changes
• Create a new branch that references the ticket number like:

git checkout -b DC-305-bugfix

• Add you changes
• Add new files and changes to your commit like git add path/to/files/*
• Create frequent commits git commit -m 'MESSAGE ' about the changes
• Push to github using the branch name
• If none exists yet, create a pull request on github
• Address any comments, and fixes, and push new commits
• A team admin or maintainer will review the changes and merge when ready
• Magical north pole elves will deploy the changes to the corresponding environment
• If a branch has been alive for long, run rebase to sync the latest changes
• Only force push to your branches, it can introduce errors if done incorrectly

note: You can work in multiple tickets at once by changing branches, as much *as possible, try to keep only the code for each specific feature on the *corresponding branch.

Inspiration

Original Git branch strategy blogpost:

link

Rebasing

Rebasing is a Git operation that allows you to integrate changes from one branch into another. It's an alternative to the better known "merge" command.

How to Rebase

1. Start by switching to the branch you want to rebase:

git checkout feature-branch

2. Then, rebase your feature branch onto the main branch:

git rebase main|master

This command will replay your feature branch's commits on top of the main or master branch respectively.

3. If there are any conflicts, Git will pause and allow you to resolve those conflicts before continuing. Once resolved, you can continue the rebase with:

git add .
git rebase --continue

4. If you want to abort the rebase process at any time, you can do so with:

git rebase --abort

Once all conflicts are resolved and your feature branch has been successfully rebased, you can push your changes to the remote repository:

git push origin feature-branch --force

Note: The --force flag is necessary because you're rewriting commit history. *Be careful with this command: make sure you're not overwriting anyone else's *changes.

Why We Rebase

Simpler History: Rebasing creates a linear commit history, which can make your project's history easier to understand.

Cleaner Commits: Rebasing allows you to squash multiple commits into a single one, which can make your feature branch cleaner and easier to merge.

Up-to-date Features: Rebasing regularly against the main branch ensures that your feature branch is always up to date with the latest changes. This can make integrating your feature easier and reduce merge conflicts.

Code Review: A linear history is easier to review, as changes are applied sequentially. This can make the code review process more efficient.

iRemember, rebasing is a powerful tool, but it can be dangerous if not used carefully. Never rebase a branch that others are working on, as it rewrites commit history. It's best used for cleaning up local feature branches before merging them into the main branch.

git branch --merged | egrep -v "(^\*|master|main|dev)" | xargs git branch -d