Changes between Version 7 and Version 8 of drm4gDevelopment

Dec 12, 2016 7:04:51 PM (6 years ago)



  • drm4gDevelopment

    v7 v8  
    6161To be consistent with our [wiki:DRM4G/Development#OurGitworkflow gitflow], all you'll be able to do is create '''feature or bugfix branches''', and you'll have to follow our naming conventions to do so.
     62* Our !GitHub's default branch is "'''develop'''", and this is done intentionally, since the "'''master'''" will only be updated when publishing a new release
     63 * __This means that all pull requests to the "'''master'''" branch will be rejected__
    6264* The naming convention will just be to create branches in lower case letters separated by underscores ("'''_'''") that describe what you're trying to accomplish with the branch.
    105107== Commiting changes
    107 After you've tested that everything is in working order it's time to update your !GitHub fork.
     109After you've tested that everything is in working order, it's time to update your !GitHub fork.
    123125== Creating a Pull Request ==
    125 ###########First you should update and check that there are no conflicts############
     127As time passes, chances are that the main DRM4G repository has had other contributors merge changes into it, so you should first update your local repository and check that there are no conflicts.
    127 Go to your repository page on github
     130git checkout develop
     131git remote add github #just do run this command the first time to add the main repository to the list of your remotes
     132git pull github develop
     135If there have been any changes, but there are no conflicts, you can just ''push'' your changes into your remote repository.
     138git push origin develop
     141In the case that there are conflicts, resolve them and commit the changes, after do the ''push'' to update your remote repository.
     143After, you just have to go to your repositories web page and click on the "'''''New pull request'''''" button.
     148A message will tell you if there are any conflicts that need to be solved or if an automatic merge is possible. Then you just have to click on the "'''''Create pull request'''''", give this merge a title (which will serve as the commit message if the pull request is accepted), a comment if you want (can be useful to explain in more detail why this should be integrated into the DRM4G), and click a second time on the "'''''Create pull request'''''" button.
     150Now you'll have to wait and see if the administrator of the project accepts the changes you're proposing.
    131154For more information on how to use git
     158Another option would be to create a new branch from the "'''develop'''" branch and then try to make a pull request from that.
     161git checkout develop
     162git checkout -b new_branch
     163#make some changes
     164git add .
     165git commit -m "Description of the changes you've made"
     166git push origin new_branch
     177For the administrator of the DRM4G's !GitHub repository:
     179When you see that there's a new pull request, either because you saw it on the projects page or because you received a message in your mail informing you about it, you can click on the "'''''Pull requests'''''" button.
     184* If you agree with the changes made, and there are no conflicts, you can just click on the "'''''Merge pull request'''''" button.
     185 * You'll automatically see a commit message that will look something like this: "__Merge pull request #X from <contributor>/<branch_name>__"
     186 * Bellow that, you can write an "optional extended description".
     187  * When running `git log` from the command line, you'll just see both lines shown as the commit message.
     188* If don't agree or there are conflicts, you can click right next to the "Merge pull request" button, where it says "'''''command line instructions'''''" to perform a manual merge.
     189 * Just follow the instructions shown there.
     190 * Optionally, you could also try to solve the conflicts wiht the web editor, but this isn't recommended since you can't test what you're changing, unless the conflict is in a comment or a text message, not in the code.