|
|
|
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
|
|
|
|
|
|
|
|
### 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
|
|
|
|
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.
|
|
|
|
|
|
|
|
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:
|
|
|
|
1) Write meaninful commit messages, with a short explanation on the top and a more specific one under:
|
|
|
|
|
|
|
|
```
|
|
|
|
[Topic] short message
|
|
|
|
*Blank line*
|
|
|
|
Long explanation
|
|
|
|
```
|
|
|
|
|
|
|
|
For example
|
|
|
|
```
|
|
|
|
[Wiki] Add Git Workflow page
|
|
|
|
|
|
|
|
The page contains the description of our workflow with git, in particular:
|
|
|
|
- Basics(pull, add, commit, push)
|
|
|
|
- Branching(master, testing, 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..
|
|
|
|
|
|
|
|
2) One commit = One task. Not less, not more.
|
|
|
|
|
|
|
|
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 |
