Skip to content

Process

Jump to bottom
Diana edited this page Feb 19, 2018 · 6 revisions

Waffle

Process

  • add an issue, look at the number on the card (upper left corner - let's say it's 33 in this case)
  • make a branch with a # and the number of the issue you're addressing at the end (eg. example-branch-#33) git checkout -b example-branch-#33
  • push the branch to origin (this moves it to the progress card) git push --set-upstream-origin example-branch-#33
  • commit away
  • add away
  • push away
  • when you're ready, issue a pull request at Github. Make sure to add closes #33 in the description or title
  • after review and after the PR is going to be closed, the card moves to done. (works only for merging into default branch).

Git

Repo

  • go into your desired folder in the command line
  • git clone https://github.com/chingu-voyage4/Geckos-Team-28.git
  • !!!!! don't modify anything on master or dev !!!!!
  • Follow the guidelines under Waffle for creating branches

Process

  • before coding pull changes from the dev branch

Branches

  • follow the guides under Waffle for naming branches (at the top of this same page)

Commits

  • Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed".
  • Always leave the second line blank.
  • Line break the commit message (to make the commit message readable without having to scroll horizontally in git).

Example

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Further paragraphs come after blank lines.

  - Bullet points are okay, too

  - Typically a hyphen or asterisk is used for the bullet, preceded by a
    single space, with blank lines in between, but conventions vary here

SCSS

Process

  • use the command line to transform scss into css
  • open command line
  • go into your folder's directory
  • go into styles folder
  • write sass --watch scss:css
  • profit

Folder structure

abstracts

  • _functions.scss

  • _mixins.scss

  • _variables.scss

  • The abstracts folder gathers all Sass tools and helpers used across the project.

  • Every global variable, function, mixin and placeholder should be put in here.

  • The rule of thumb for this folder is that it should not output a single line of CSS when compiled on its own.

  • These are nothing but Sass helpers.

base

  • _base.scss

  • _fonts.scss

  • _helpers.scss

  • _typography.scss

  • the boilerplate code for the project. In there, you might find some typographic rules, and probably a stylesheet, defining some standard styles for commonly used HTML elements.

components

  • _button.scss

  • It contains all kind of specific modules like a slider, a loader, a widget, and basically anything along those lines.

layout

  • _header.scss

  • _footer.scss

  • defines the global wireframe

  • contains everything that takes part in laying out the site or application. This folder could have stylesheets for the main parts of the site (header, footer, navigation, sidebar…), the grid system or even CSS styles for all the forms.

pages

  • _home.scss

  • _page2.scss

  • page-specific styles

vendors

  • _normalize.scss

  • vendors contains all the CSS files from external libraries and frameworks – Normalize, Bootstrap, jQueryUI, FancyCarouselSliderjQueryPowered, and so on. Putting those aside in the same folder is a good way to say “Hey, this is not from me, not my code, not my responsibility”.

  • do not overwrite this

main.scss

  • the only Sass file from the whole code base not to begin with an underscore.
  • this file should not contain anything but @import and comments.

_shame.scss

  • the only file we should be ashamed of for using (jk not jk)
  • put all the CSS declarations, hacks and things you are not proud of in this file. (ex !important)
  • make sure you explain why you used the 'hack' so that at a later time you could come back and fix it

JavaScript

  • help me out with this one
Clone this wiki locally