-
Notifications
You must be signed in to change notification settings - Fork 5
Git workflow
You do not have the rights to directly write on the project. Hence if you wish to push some code, the best thing to do is to fork the project. Once done, you will have a copy of the the repository in6pio/Incipio to your own namespace, with write access.
On your fork, you can develop and do changes as you wish. We recommend you to do your modifications in separate branches so that you can keep the original branches up to date with the original repository.
If you are not used to this kind of workflow, do not worry, everything is detailed below!
Nothing easier than that: go to https://github.com/in6pio/Incipio and then clic on the fork button ;)
For more, check this GitHub guide: forking projects.
First, clone your fork!
Here it becomes a little bit trickier if you never did it. With your fork, you can do your changes as you like it will not affect the original repository. However, sometimes changes may happen on the original repository and you want to keep your fork up to date so that you can develop with the latest work. To achieve that, you have to configure the tracked repositories.
To see which repositories are tracked, use git remote -v
. The current result should be something like:
origin [email protected]:yourNameSpace/Incipio.git (fetch)
origin [email protected]:yourNameSpace/Incipio.git (push)
Now, add the original repository to tracked repositories: git remote add upstream [email protected]:in6pio/Incipio.git
. Now if you do git remote -v
again you should have:
origin [email protected]:yourNameSpace/Incipio.git (fetch)
origin [email protected]:yourNameSpace/Incipio.git (push)
upstream [email protected]:in6pio/Incipio.git (fetch)
upstream [email protected]:in6pio/Incipio.git (push)
That's it! Now, if you wish to update your repository, you can do:
-
git fetch upstream
: get the updates from the original repository. -
git fetch origin
: get the updates of your remote repository (the fork).
Source: GitHub: syncing a fork
It is highly recommended to use the development environment provided to develop. If you want more information on it, check this link.
If you wish to properly keep your fork up to date, do not touch the original branches like master
!
Now let's start. It is assumed that your repository is up to date. Create your branch featureName
(the branch name has really no importance, you will be the only one to use it) from the dev
branch:
git checkout origin/dev # You are now on your remote branch `dev`
git checkout -b featureName # You are now on the branch featureName
Now you can start to code. Do not forget to follow the project contributing guidelines!
It is assumed that you have your latest work that you wish to submit pushed on the branch featureName
on your fork. Before submitting your work, first check that your work following the project standards. Then, to clean your work, do not forget to rebase it first. Why? To ensure your work integrates the latests commits of the original repository and ease the merge! Never did that? Then do the following:
Go on your branch featureName
.
Update your local repository:
git fetch upstream
git fetch origin
git pull featureName
Rebase your work:
git rebase upstream/dev
Solve the conflicts, and only the conflicts, nothing else! To do so, check the conflicted files. Once this is done, do:
git add -A
git rebase --continue
And to that until the rebase is successful :)
Now repush your work. You will probably need to do a force push.
Good! Now you can do a pull request with the original repository on the dev
branch (in6pio:dev
) as a base
and your fork branch as HEAD
(yourNameSpace:featureName
).
- Learn Git with pcottle
- Bien utiliser
git merge
etgit rebase
- Getting solid at
git rebase
andgit merge
- How to undo almost anything with Git
Last be not the least, if you feel uncomfortable with Git in command lines, checkout:
Good coding!
- Git Workflows For Successful Deployment - Matt Surabian (bocoup) | May 07, 2015
- Git Best Practices: Workflow Guidelines - Andrew Berry (Lullabot) | June 14, 2012
- GitHub Flow - Scott Chacon | August 31, 2011
- A successful Git branching model - Vincent Driessen | January 05, 2010
- Practical Git: A Workflow to Preserve Your Sanity - Keith D Gregory
- Understanding the Git Workflow - Ben Sandofsky
- Git Workflows That Work - Spencer Christensen | May 2, 2014
- Git branch strategy for small dev team - Bilal and Olga | March 11, 2010
- Git Branching - Branching Workflows - Git official doc
- Comparing Workflows - Atlassian
- Git Workflow in Invenio - Invenio
This guide is here to provide you the guidelines to contribute to the project.