-
Notifications
You must be signed in to change notification settings - Fork 4
Developing VeloxDFS
IMPORTANT One feature for branch, if you add more features merge part might become very complicated.
-
Create a branch from the latest commit of master:
$ git checkout master # Move to master branch $ git pull master # Update to latest commit $ git checkout -b my-feature-branch # Create branch from that commit
-
Add your feature and as much unit tests as possible.
- Add your unit test to the Autotools
make check
rule - Check test/Makefile.am file. - It is imperative not to touch code that is not related to your feature.
IMPORTANT One branch/feature per person is the best approach. Do not call your branch with the persons names but with the feature name (Check coding style page).
-
By the time that your branch (feature) is getting ready it time to open a pull request (PR) in Github. As soon as the open request is opened the team will be notified and a automated deployment of your code will be trigger in a Travis Ci virtual machine (Further info at Continuous Integration part).
-
If the virtual machine worked without problem is time to group together your mess of commits and create as few as possible with very meaningful messages, [Commit message standars] commits.
You will want to use
git rebase -i
probably. I encourage you to instruct yourself about this command as it can be dangerous to use.$ git rebase -i #commit of beginning of branch
Also, do not forget to comment your code in the Doxygen manner, and to update the documentation of the project if you have added something that needs to be known to other developers or users.
-
Once your code is tested in your local machine and the VM and your commits are well organized is time to get an approval from some of the team mates through a code review. You can request it in the Github Pullrequest form. The other team mate will check your code and comment parts that might need to be fixed or modify. Iterate through step 4 and 5 until you get the approval.
-
You get the approval, you are ready to merge. Use
merge commit
strategy to keep an linear story while maintaining some of the individual commits so that your work contribution will be totally counted. In the commit message that you can modifiy in the PR form addrelease: X.Y.Z
according to the version you will release, [versioning schema] release. -
The VM will generate the documentation site (Doxygen) automatically and generate a tag and tarball with the version you specified in the commit message (If you forgot to specifiy the release version, just do it manually
git tag -avX.Y.Z -m ".."
).
-
To keep things simple it would be recommendable to Update from a tag in VeloxDFS. This is, VeloxMR is always dependent to some version (Master commit) of VeloxDFS. So If VeloxMR was dependent on v1.8.1 and you want update it, it will later depend in the other version like 1.8.5 for instance.
In VeloxMR folder routhly follow the following commands:
$ git remote add MR git@github.com:DICL/VeloxMR.git # Fetch VeloxMR remote $ git fetch MR $ git checkout mapreduce $ git checkout -b update-vX.Y.Z # Create branch from DFS tag $ git merge --squash --no-commit vX.Y.Z # Merge, you might want to use -Xours or -Xtheirs
Now it is the hard part, you will have merge conflicts for each files that are repeated. Make sure just to merge source code related to DFS you should ignore other merge conflict files such as
configure.ac
file orREADME.md
file. THose files you want to keep the current MR version, you do not want to copy them from DFS. You can disable merge on those files with the following command:$ git checkout --ours FILE1 FILE2 FILE...
On the other hand if you want to get ride of MR Files and just copy DFS execute:
$ git checkout --theirs FILE1 FILE2 FILE...
Be very sure that you only merged or include files related to DFS. Check time to time with
git status
. -
Once ready execute command:
$ git commit
Write a meaninful message and then you can follow PR workflow described in the first section.
This part is much harder and relies on more obscure git features. The idea is to create a manual patch file with the exact changes.
-
Create a commit which only includes the DFS related files in the VeloxMR folder. You can check many manuals online how to do it.
-
Create patch file with:
$ git format-patch -1 <commit sha>
-
Apply in DFS in a branch called
add-mr-updates
or something like that with the command:$ git apply --stat file.patch # See patch stats $ git apply --check file.patch # Check patch $ git am < file.patch # Apply patch
-
Create Pull request and follow the steps on the first section.