-
Notifications
You must be signed in to change notification settings - Fork 0
Git Rules
This page covers guidelines for keeping the nBites git repository clean. This should help keep commit histories sensible across all users and assist in preventing conflicts.
In general, you should have 2 kinds of branches: your “master” branch, and everything else. The master branch should either be up to date with the nbites master, or it should have your new code which is stable, well tested, and has a pull request. Do not keep any new code in your master branch unless you have a pull request opened. Your other branches (usually called working branches) can contain whatever work you’re developing.
Once your master branch is stable and well tested, you should get it merged into the nbites master.
- Rebase your master off of the nbites master.
- Push your master to your github remote.
- Go to your remote’s page on github and open a pull request.
Someone else will test your code before it can get merged into the nbites master. If small errors are found, you can keep pushing new commits to your remote’s master, and they will automatically become part of the pull request.
You should attempt to keep your branches up to date with the nbites/master. The easiest way to do this is to have a github remote called nbites, and regularly run these commands:
$git remote update
$git checkout master
$git rebase nbites/master
Rebasing will take all of the commits you have made in your master branch and put them on top of all the ones in the nbites/master (i.e. it’s as if you made all the commits after all of the ones in nbites/master). This is dangerous if your commits generate conflicts with the ones in the nbites/master. Rebasing will not generate merge conflicts since your changes will effectively come after the ones in the nbites/master. If you are worried about conflicts, you can always merge instead, which will create it’s own commit with any conflict resolutions (possibly 0). If merge conflicts occur, you should talk to whoever wrote the code that is causing conflicts before you try to resolve them. That way, you can ensure that the resulting code will still function as intended. You should rebase your working branches from your own master now and again as well.
Your master branch should always be the same as the nbites master, unless you have a pull request open. If, for some reason, you have extra commits in your master that you don’t want to put in a pull request, there is a way to reset your master back to the nbites master. Assuming you have a remote branch called nbites, run these commands:
$git remote update
$git checkout master
$git reset --hard nbites/master
$git push -f
Notice that the -f option is needed when pushing to your remote if it has any commits past the nbites master. Be careful when resetting your master! Unless you have them saved in some other branch, the commits that are deleted are gone forever (which is a very long time).