IMPORTANT One feature for branch, if you add more features merge part might become very complicated.
$ 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
make check
rule - Check test/Makefile.am file.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).
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.
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.
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 add release: X.Y.Z
according to the version you will release, versioning schema.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 or README.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.
$ git format-patch -1 <commit sha>
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