Personaly i can understand everything in there. However i tend to do things differently myself.
How i usualy work: * I use clone with https way 1. Fork the repository to my own account 2. clone the repository localy, making my fork 'origin' (git clone <https-url (of the fork)>) 3. add the original repository as a remote with the name upstream (git remote add https://github.com/apache/struts.git) 4. create a branch for changes 5. do changes localy 6. add changed files (git add <changed files>) 7. commit changes localy (git commit -m "my comment explaining what changed") 8. push to origin (being my fork) (git push origin <branchname>) 9. create pull request Reasons for using own fork as origin: * When looking up commands i tend to always come across commands that push to origin * It tends to make it more awkward to accidently try to push to the original git repo Spotted typo: Do you changes and commit them... => Do your changes and commit them ... I'm not saying either way is better, just thought i'd mention this slightly different approach. Regards, Stefaan Dutry (sdutry) 2017-02-03 16:15 GMT+01:00 Lukasz Lenart <lukaszlen...@apache.org>: > 2017-02-03 16:06 GMT+01:00 Greg Huber <gregh3...@gmail.com>: >> How would one resync the github fork with the struts orignal version? > > You don't have to :) You are always starting off the master from origin > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
