-
Notifications
You must be signed in to change notification settings - Fork 2
Git UWNRG
This guide is by no means comprehensive and relies heavily upon information from http://nvie.com/posts/a-successful-git-branching-model/, https://confluence.atlassian.com/display/BITBUCKET/Fork+a+Repo%2C+Compare+Code%2C+and+Create+a+Pull+Request and Version Control with Git Second Edition. Please read and understand the guidelines for using the Git repository with UWNRG, and if anything goes wrong with your repository, stop all actions and contact the controls lead at the time. The less random commands you type in, the higher the chances are that your changes can be recovered.
There are many additional options, but these are the main commands to be used for operating Git, and a simplified explanation of their function. For more information, explore Internet.
This command adds files to be tracked by Git. A good option to use is -p, which allows you to interactively choose parts of the patch to add to the index.
The default text editor for Git will be opened to add a commit message, which must be added to commit the work. All commits can be seen in the history of the Git repository. A good source to read on proper commit messages is http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html. To include an issue in a commit message with bit bucket, follow the standards provided by Bitbucket at https://confluence.atlassian.com/display/BITBUCKET/Automatically+Resolving+Issues+when+Users+Push+Code#AutomaticallyResolvingIssueswhenUsersPushCode-IncludingIssuesinaCommitMessage.
Fetches from and merges another repository with the local repository.
Updates remote repositories to the state of the branch in your local repository. This may require conflicts to be merged. Always perform the git pull command before git push to ensure all conflicts are resolved first.
Removes the file specified from the repository and deletes it from the local file system. This must be done if you are removing a file from the repository, as if it is just deleted from the file system without informing Git, it leads to a bad state of the repository.
This can be used to rename a file, or move it to a new location. This updates both the repository and the local file system, preventing the repository from entering a bad state.
Updates files in the local repository to match the version specified. Use the option -b to create a new branch.
With no arguments, all existing branches are listed (the current one will be highlighted with an asterik. With OPTION –d the specified branch will no longer be tracked. With no options, the specified branch will be created.
Joins two or more development histories together. The options --no-ff is used so that information about the existence of a branch will always exist, even if a fast-forward could be performed. This should only be performed if there are no local changes not yet tracked and committed.
UWNRG will use three types of branches for development: master, development, and feature/bug branches. A special competition branch should be started when going to a competition so random changes to the code will not affect the stable version of the code, but that will not be covered below as it is a rare occurrence, and the branch will only be used for a short period of time.
This branch will be the working version of the code. At no time should this branch not be able to compile and run.
This branch will be used to merge in features incrementally. These features should not break the build, meaning that the development should be fully working, just like master, at all times. When full functionality is added for whatever feature set is being developed, this branch should be merged into the master branch. There should only ever be one development branch.
This branch will be used to develop a specific feature or fix a specific bug. Feature/Bug Branches should be created often, so as to allow better history on the changes in making a feature. Once fully completed, and only then, will it be merged into the development branch. Merges back into the development branch should happen often though, so features should be split into small sections to accommodate such requirements. The naming scheme being used is
bug/BUGNUMBER feature/FEATURENAME
Underscores ‘_’ will be used to separate words, and no uppercase letters will be used.
A merge conflict will occur when there is no obvious resolution for the difference between two branches. When this occurs, it is up to the person performing the merge to fix the state of the code before finishing the merge. All conflicts must be resolved before one can commit.
The command ‘$ git diff’ will show all the conflicts in the merge.
The first section of a conflict is the version of code from the current repository. The second section of a conflict is the version of code that is being merged in.
$ cat hello
hello
//>>>>>>>HEAD:hello//
worlds
//=======//
world
//>>>>>>>623898a7asag83987298aasd:hello//
more text
The naming conventions and ideology behind the branches is still the same, but the method in creating the branches is different. All users should have write access (except for the controls lead who has admin access).
$ git clone url
Follow the naming specifications mentioned above in the Branches section. Perform this command from the development branch.
$ git checkout -b BRANCHNAME
The following commands will add all changed files to be tracked by Git and commit them to the branch.
$ git add -p FILENAME
… repeat for all files you wish to be tracked
$ git commit
The pull request will ensure there are no conflicts before pushing. If there are, read the Merge Conflicts section to understand how to deal with them.
$ git pull origin HEAD
$ git push origin HEAD
This should be done only when the feature/bug is complete, and should be pulled into the development branch. To create a pull request, go to the repository on bitbucket.org, and click the ‘Pull Request’ button. This will open a new window which will allow you to choose the branch you are currently working on and select the destination branch. The destination branch should almost always be the Development branch. Doing so will allow your code to be reviewed before it is added to the development branch. Before creating a pull request, ensure all coding guidelines are followed by checking your changes (can be done with the compare feature in bitbucket or git diff).
Make sure when creating the pull request that you check off that you want to close the branch after a successful pull request.
After the pull request is accepted, the branch will be closed, and you should switch the repository of your local code to an active branch. Your local Git repository will not change automatically.
Update the issue tracker for the particular feature/bug you were working on, referring to any applicable wiki pages. If the feature implemented is deemed important enough by the controls lead, then a new wiki page should be created for the feature. The name of the page should be feature/FEATURENAME. Use the template feature wiki page found on the home wiki page to help with formatting.
Logging issues is a public feature. Anyone can do so at https://bitbucket.org/MatthewCMaclean/uwnrg/issues. If the feature is based on a specific issue on Bitbucket, use the commit message conventions mentioned in the git commit description in the Main Commands section.