Revisions allow you to track differences between multiple versions of your content, and revert back to older versions.
Here are the essential commands for an occasional developer.
git clone git@github.com:OpenMx/OpenMx.git
Clone grabs a copy of the history. You only do this once.
Make some changes. Commit them with
git commit -a
Here are some guidelines about writing a good commit message.After you test your changes and are ready to publish to the rest of the team then
git fetch origin # fetch any new commits from other developers git rebase origin/master # put your changes on top of HEAD git push origin HEAD:master # publish your changes
I do not recommend 'git pull'. The user interface for 'pull' is designed for change integrators (think Torvolds), not so much for developers. There is a way to get the same effect as fetch/rebase using pull, but I recommend you do these operations as separate steps.
You can merge changes onto the master branch. However, you should not create a merge commit for no reason. A linear history is easier to understand than a history containing many merges back and forth between slightly different branches. A good reason to make a merge commit is if somebody else contributed the changes and your role is only to merge them. You might merge your own branch too if there is a sequence of commits that are related to the same logical change. However, a merge commit is not an excuse to omit testing each commit separately. Every individual commit should be 100% passing on our test suite.Here is how to create a nice clean merge.
git checkout feature/description # a descriptive branch name is encouraged git fetch team # fetch any new commits from other developers git rebase origin/master # put your changes on top of HEAD git checkout -b master origin/master # create a branch where you can merge to git merge --no-ff feature/description # merge it git push origin HEAD:master # publish your changes
Note that before we merge the branch, we rebase it on top of origin/master. This is important to simplify (linearize) history as much as possible. Without this step, there is a chance of merge conflicts that need to be resolved in the merge. It is more transparent to resolve any merge conflicts in the branch before merging and leave the merge commit empty. This is not an absolute rule, but it is encouraged.