freeCodeCampOxford.github.io

Welcome to the freeCodeCampOxford website repository. If you would like to contribute, and you know what you're doing - go for it and thank you, looking forward to your PRs.

Project Guidelines ·

• Git
  • Some Git rules
  • Git workflow
  • Writing good commit messages

1. Git

1 Some Git rules

There are a set of rules to keep in mind:

• Perform work in a feature branch.

  Why?

  Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. read more...

• Branch out from develop

  Why?

  This way, you can make sure that code in master will almost always build without problems, and can be mostly used directly for releases (this might be overkill for some projects).

• Never push into develop or master branch. Make a Pull Request.

  Why?

  It notifies team members that they have completed a feature. It also enables easy peer-review of the code and dedicates forum for discussing the proposed feature.

1.1 freeCodeCamp Oxford Git workflow

• Clone our git repository in the project directory. For subsequent features/changes this step should be ignored.

  git clone https://github.com/freeCodeCampOxford/freeCodeCampOxford.github.io.git
  cd freeCodeCampOxford.github.io

• Checkout a new feature/bug-fix branch.

  git checkout -b <branchname>

• Make Changes.

  git add <filename> OR git add --a
  git commit -m "your commit message"
  git push

• Sync with remote to get changes you’ve missed.

  git checkout develop
  git pull

  Why?

  This will give you a chance to deal with conflicts on your machine before submitting a Pull Request.

• If you don’t have conflict skip this step. If you have conflicts, resolve them.

• Push your branch.

  git push

• Make a Pull Request.

• Pull request will be accepted, merged and close by a reviewer.

• Remove your local feature branch if you're done.

  git branch -d <branchname>

1.2 Writing good commit messages

Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. Here are some rules of thumb (source):

• Separate the subject from the body with a newline between the two.

  Why?

  Git is smart enough to distinguish the first line of your commit message as your summary. In fact, if you try git shortlog, instead of git log, you will see a long list of commit messages, consisting of the id of the commit, and the summary only.

• Limit the subject line to 50 characters and Wrap the body at 72 characters.

  why?

  Commits should be as fine-grained and focused as possible, it is not the place to be verbose. read more...

• Capitalize the subject line.

• Do not end the subject line with a period.

• Use imperative mood in the subject line.

  Why?

  Rather than writing messages that say what a committer has done. It's better to consider these messages as the instructions for what is going to be done after the commit is applied on the repository. read more...

• Use the body to explain what and why as opposed to how.

Visit Codecademy for free Git practice

You can search for live server for your text editor for more comfortable development.

Here are the most popular ones:

• VSCode
• Atom
• Sublime Text 3

Please answer the questions which appear when you submit your PR honestly and feel free to go back over your code and change it to make sure it fulfils the requirements. We massively respect your time creating super-awesome-feature, but if it's challenging to review it, you won't see the fruits of your work for longer than it should have been.

Happy Coding!

Noticed a mistake? Create your own PR and let us know!