https://github.com/benawi/distributed-process-coord-election
Implemantation of Distributed Process Coordination Election Algorithim
https://github.com/benawi/distributed-process-coord-election
bully-algorithm coordinator election multithreading ring-algorithm synchronization
Last synced: 3 months ago
JSON representation
Implemantation of Distributed Process Coordination Election Algorithim
- Host: GitHub
- URL: https://github.com/benawi/distributed-process-coord-election
- Owner: Benawi
- Created: 2023-04-04T11:22:39.000Z (over 2 years ago)
- Default Branch: master
- Last Pushed: 2023-04-28T13:24:13.000Z (over 2 years ago)
- Last Synced: 2025-01-15T21:07:03.517Z (11 months ago)
- Topics: bully-algorithm, coordinator, election, multithreading, ring-algorithm, synchronization
- Language: Java
- Homepage:
- Size: 27.3 KB
- Stars: 4
- Watchers: 1
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Distributed-Process-Coord-Election
## Implemantation of Distributed Process Coordination Election Algorithim
## Give me ⭐️ If you like this project!
## [Feedback or Question](https://github.com/Benawi/Distributed-Process-Coord-Election/issues/1)
# How to use GitHub flow
## Main branch
You can think about the `main` branch as a snapshot of your application that at any moment can be used for:
- deployment to production (which often occurs automatically) - you do not want to deploy broken code by accident.
- developing new features with multiple collaborators - your teammates need a stable version of your project to start implementing changes.
Therefore the `main` branch should always be stable code that actually works and can be safely used. Any changes required in the application should be introduced in `feature` branches and approved before merging them to the `main` branch.
*NOTE: The `main` branch is a rather new name. Previously it was called the `master` branch. GitHub [has changed it for good reasons](https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/), but you can still see some references to the `master` in many articles. Do not let that confuse you.*
## Feature branches
Before you start working on a new feature, you should create a new `feature` branch that is based on the `main` branch. You will use this branch for all your work.
In order to get a deeper understanding of `feature` branches
Remember that your branch name should be descriptive (e.g.: `refactor-authentication`, `user-content-cache-key`, `make-retina-avatars`), so that others can see what is being worked on.
## Opening pull requests
Once you start working on any project, initialize its `main` branch. Then, add changes in a `feature` branch(es).
You will need to create a *pull request* to compare your `feature` branch with the `main` branch and submit the link to that pull request via your Dashboard.
After you submit the link to your pull request you will get a code review from one of our code reviewers.
You should not merge your pull requests to the `main` branch of your project without a code review that *approves* your changes.
------