///////////////////////////////////////////////////////// /// General Workflow /////////////////////////////////////////////////////////
- Fork the repo
- Cut a namespaced feature branch from master - bug/... - feat/... - test/... - doc/... - refactor/...
- Make commits to your feature branch. Prefix each commit like so: - (feat) Added a new feature - (fix) Fixed inconsistent tests [Fixes #0] - (refactor) ... - (cleanup) ... - (test) ... - (doc) ...
- Squash commits so that only meaningful commit text is merged into upstream master
- When you've finished with your fix or feature, Rebase upstream changes into your branch. submit a pull request directly to master. Include a description of your changes.
- Make pull request and get someone else approve/merge it
///////////////////////////////////////////////////////// /// Detailed Workflow /////////////////////////////////////////////////////////
- Fork the repo
Use github’s interface to make a fork of the repo, then add that repo as an upstream remote:
git remote add upstream https://github.com/hackreactor-labs/<NAME_OF_REPO>.git
- Cut a namespaced feature branch from master
Your branch should follow this naming convention: - bug/... - feat/... - test/... - doc/... - refactor/...
You can create and go to a branch using this command:
git checkout -b your-branch-name
Prefix each commit like so - (feat) Added a new feature - (fix) Fixed inconsistent tests [Fixes #0] - (refactor) ... - (cleanup) ... - (test) ... - (doc) ... - (structure) ...
Make changes and commits on your branch, and make sure that you only make changes that are relevant to this branch. If you find yourself making unrelated changes, make a new branch for those changes.
- Commit Message Guidelines
- Commit messages should be written in the present tense; e.g. "Fix continuous integration script".
- The first line of your commit message should be a brief summary of what the commit changes. Aim for about 70 characters max. Remember: This is a summary, not a detailed description of everything that changed.
- If you want to explain the commit in more depth, following the first line should be a blank line and then a more detailed description of the commit. This can be as detailed as you want, so dig into details here and keep the first line short.
- Squash Commits
- Minimize the number of commits so that upstream master branch is as clean as possible
- "git log" and copy hash from commit BEFORE the last one you intend to squash
- "git rebase -i OR git rebase -i HEAD~<#>
- Replace the word "pick" with "squash" on commits you want to merge with the commit above
- For additional reference, check out this article:
Check this out for instructions on squashing commits.
- Rebase upstream changes into your branch
Once you are done making changes, you can begin the process of getting your code merged into the main repo. Step 1 is to rebase upstream changes to the master branch into yours by running this command from your branch:
git pull --rebase upstream master
This will start the rebase process. You must commit all of your changes before doing this. If there are no conflicts, this should just roll all of your changes back on top of the changes from upstream, leading to a nice, clean, linear commit history.
If there are conflicting changes, git will start yelling at you topart way through the rebasing process. Git will pause rebasing to allow you to sort out the conflicts. You do this the same way you solve merge conflicts, by checking all of the files git says have been changed in both histories and picking the versions you want. Be aware that these changes will show up in your pull request, so try and incorporate upstream changes as much as possible.
You pick a file by git add
ing it - you do not make commits during a
rebase.
Once you are done fixing conflicts for a specific commit, run:
git rebase --continue
This will continue the rebasing process. Once you are done fixing all conflicts you should run the existing tests to make sure you didn’t break anything, then run your new tests (there are new tests, right?) and make sure they work also.
If rebasing broke anything, fix it, then repeat the above process until you get here again and nothing is broken and all the tests pass.
- Make a pull request
Make a clear pull request from your fork and branch to the upstream master branch, detailing exactly what changes you made and what feature this should add. The clearer your pull request is the faster you can get your changes incorporated into this repo.
Once the CI tests pass, at least one other person MUST give your changes a code review, and once they are satisfied they will merge your changes into upstream. Alternatively, they may have some requested changes. You should make more commits to your branch to fix these, then follow this process again from rebasing onwards.
Once you get back here, make a comment requesting further review and someone will look at your code again. If they like it, it will get merged, else, just repeat again.