Skip to content
Snippets Groups Projects

Changes

Page history
  • New page
  • Templates
    • Updated Git Workflow (markdown) authored by Alvise de'Faveri's avatar Alvise de'Faveri
    Show whitespace changes
    Inline Side-by-side
    Showing
    with 37 additions and 21 deletions
    Git-Workflow.md
    View page @ 75613094
    If you are completely new to Git, start from reading the [Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics) and [A Simple Guide](http://rogerdudler.github.io/git-guide/).
    ### Basics
    The main idea is to keep a step-by-step history of the code you write, so that you can easily keep track of what's going on and make bug-fixes if problems arise. Typical steps are:
    1) `git pull` will fetch the most recent version of the code
    2) Add, modify and delete files as you wish (changes will remain local)
    3) When you're happy, `git add` what you modified to "stash" your changes for the commit
    4) `git commit` the stashed changes (see below)
    5) `git push` when you want to send your changes upstream
    If you are completely new to Git and Github, start from reading the [Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics)
    or maybe [A Simple Guide to Git](http://rogerdudler.github.io/git-guide/).
    There are some of the terms you'll need to know are:
    1) `pull`: fetch the most recent version of the code (after you `cloned` the repository).
    2) `git add`: "stage" your changes for the commit.
    3) `commit`: group together changes to make them final (see [below](../Git-Workflow#Commits)).
    4) `push`: send your changes upstream.
    On a bigger scale, changes to the code can be made on different `branches`,
    which are different versions of the same project that can be `merged` into each other.
    5) `checkout`: change working branch.
    ### Branching
    On a bigger scale, changes to the code can be made on different *branches*, which are different versions of the same project that can be *merged* into each other.
    Ideally, branches should be divided in these categories:
    - `master` branch: is the final one: everything's that here has been tested and it's all working.
    - `testing` branch: is where development takes places: when a new feature is ready, it has to work with
    In Boardcore there are two main branches:
    - The `master` branch: is main branch, everything's that here has been tested and it's all working (or at least it should).
    - The `development` branch: is where development takes places. When a new feature is ready, it has to work with
    the rest of the code and then, only when everything's working, it can be merged with the master.
    - `feature` branches: they exist for a limited amount of time for developing a specific feature. When the feature is ready,
    a *Pull Request* will be opened to merge the feature branch with the testing one, where it will be tested with
    all the other features that maybe were added in the meantime. If the Request is accepted, you can cancel the feature brench.
    - `hotfix` branches: normally, when a bug is found on the master, a branch is created to find a fix to that bug.
    When the problem is solved, the branch will be merged with the master *and* the testing branch before being cancelled.
    ------------------
    **:warning: WARNING: You should NEVER commit directly to the master**
    -----------------
    To make changes to the software you should use:
    - `feature` branches: are branched off from `development` and exist for a limited amount of time for developing a specific feature.
    When the feature is ready, the developer should open a *Pull Request* to merge the feature branch with the developing branch.
    - `hotfix` branches: when a bug is found on the master, a branch is created to find a fix to that bug.
    When the problem is solved, the branch will be merged with the master *and* the development branch before being cancelled.
    If you want to see a nice branching model example take a look at <http://nvie.com/posts/a-successful-git-branching-model/>.
    ### Commits
    Commits are the core of your team work, because they are the way in which you change the code.
    For this reason, you have to *think* before you commit, and try to write [good commit messages](https://github.com/erlang/otp/wiki/writing-good-commit-messages).
    Some simple rules:
    ......@@ -43,7 +54,7 @@ For example
    The page contains the description of our workflow with git, in particular:
    - Basics(pull, add, commit, push)
    - Branching(master, testing, features and hotfixes)
    - Branching(master, development, features and hotfixes)
    - Commits(how to write commit messages and when to commit)
    ```
    Do this, and everyone will love you - including yourself, when you'll read your code after a month from when you last wrote it..
    ......@@ -53,4 +64,9 @@ Do this, and everyone will love you - including yourself, when you'll read your
    Group together in the same commit the changes that were made for the same task: if you're about to write something like
    > Fixed bug in Class.cpp and Added something else in another Class.cpp
    Think twice! Probably you should do two separate commits.
    \ No newline at end of file
    Think twice! Probably you should be doing two separate commits.
    What's Next
    -----------
    Now that you know how to work on this repository, you can read the [Coding Guidelines](../Coding-Guidelines)
    and start [Writing a Driver](../Writing-a-Driver).
    \ No newline at end of file