Skip to content

Latest commit

 

History

History
128 lines (79 loc) · 5.99 KB

CONTRIBUTING.md

File metadata and controls

128 lines (79 loc) · 5.99 KB

How can I contribute?

  • You can fix the typos (if any) in any documentation of this repo.
  • You can check for any unassigned issues and comment on that issue that you'd like to get that issue assigned to you. (Remember: Do not work on issues assigned to someone else and do not work on any issue without having it assigned to you.)
  • Create an issue if you see any bug and then once you get approval from the admins, you can assign yourself and comment an ETA for the issue and start working on it.

How can you make a Pull Request (PR)

Note: Steps 1, 2 and 3 are one-time steps required for setup. If you have already cloned the repo and added upstream, consider following this documentation from step 4.

  1. Forking repository

Fork this repository using the Fork option at the top-right corner of this page. This will create your own copy of this repository. You'll be redirected to your forked repository. Copy the link of this repository (which will look like https://github.com/<your-username>/identity-service/) as you'll need it in step 2.

how-to-fork

  1. Cloning repository

Clone your forked repository, this will download your fork in your computer. To do this, open your terminal (command prompt/bash/git bash) and enter the following command, paste your link after the word clone without the <>.

git clone <link which you copied in step 1>
  1. Adding remote repository

Add the Real Dev Squad repository as a remote repository, so that you can anytime pull the latest changes from the Real Dev Squad repository which is being deployed. This needs to be done only for the first time.

git remote add upstream https://github.com/Real-Dev-Squad/identity-service/
  1. Getting the latest code from the develop branch (Can be skipped if you've cloned the repo just now)

If it's been quite a while since you have cloned the repo/made the last pull request, it's recommended to take a pull from the develop branch. The reason is, there may be some changes that could have merged after you had cloned the repo/made the last pull request.

To do so, make sure you're in the develop branch by checking out the develop branch:

git checkout develop

Once you're in the develop branch, it's time to take a pull:

git pull upstream develop

Now that you've made sure that you've got the latest changes, we can proceed to create our branch

  1. Creating a branch

Create a new branch to work on. We require a different branch so that we always have a stable, working version in the default (develop) branch. We're not supposed to touch the main branch as it is the one getting deployed on production.

git checkout -b <branch-name>

We will try to name the branch according to the task we are going to perform in it. If it is going to be a feature, the branch name should begin with feat or feature. If it is going to be a fix, the branch name should begin with fix or bugfix. The branch name should be self-explanatory. For example, if I want to work on a feature called login-form, the branch name will be feature/login-form. If it is going to be a fix in form-data, the branch name will be fix/form-data. Command example:

git checkout -b feature/login-form
  1. Just do it!

Perform the tasks you wanted to.

  1. Committing your changes

Now you have made the changes, though they are saved in your system, Git doesn't know what changes you've done. So you have to commit your changes. The first step is to add the files which you want to add to the staging area, the dot after add in the first command tells Git to check for changes in all the files. The second step is about committing to your changes. The message part is a short description of your commit, and what changes that particular commit is doing. For example, while creating a login form, the commit message can be something like creating login form.

git add .
git commit -m "Write a message about your commit"
  1. Making sure you have the latest changes from the develop branch

It may so happen that since the last time you cloned the repo/took a pull from develop, some changes may be merged in the develop branch. So to be on the safer side, we should have those changes as well.

In order to do that, we first check out to develop branch by:

git checkout develop

Once we're in develop, it's time to take a pull:

git pull upstream develop

Now that our local develop branch is in sync with the remote develop branch (of the Real Dev Squad Repository), we should let our branch know about the changes from the develop branch (if any). To do so we first checkout to our branch:

git checkout <branch-name>

Once we're in our branch, we rebase our branch on top of the current develop branch (we change the base of our branch so that it appears as if we have worked from the time the latest changes were merged in the develop branch). To do so:

git rebase develop

You should solve the merge conflicts, if any.

  1. Pushing your code

Now it is time to push the changes of your local develop branch to your fork of the repository which is on Github (which we cloned in step 2).

git push origin <branch-name>
  1. Pull request

Now go to your forked repository and you'll see that This branch is xx commits ahead of Real-Dev-Squad:develop. Right next to it will be an option to Pull Request. Click on it, and submit your pull request (also known as PR) explaining what you've done.

how-to-open-pull-request

  1. Review stage

Wait for it to get reviewed, make the changes required (if any), commit your changes, and push the changes again in your forked repository as mentioned in Step 7 and Step 10, your commits will be added to the same pull request you had opened earlier (if it is NOT closed).

  1. Congratulations on making your first Pull Request! 🎉