Making progress getting on board with Github... sent a fake/test pull-request. I was not able to delete it, and the tutorials show that this can only be done using the command line interface, which I do not have yet.
I have made a lot of changes/corrections for ConvertFuncs.ahk with more to come. The thing is, some of the changes involve new functions that have been added to support larger changes yet to come, which (IMO) require more than band-aid code. I'm not sure whether these changes will be welcome in the project or not, because some involve a redesign of the current workflow. The main loop works for many things, but restricts other things. I guess I will submit the changes and see whether they are welcome within this project or not.
I will need to go back to the master branch and start again with the changes so that each can be submitted independently (as requested). I'm unsure whether I will need to wait for each pull-request to be approved before submitting another. But some changes build upon each other. Submitting each change as a separate pull-request will be tedious, but I understand the need for this process. I'm still trying to understand branches and wonder if each change requires a new branch or not.
Please let me know whether I will need to wait for approval of one pull-request before submitting another. And any other thoughts you may have.
Thanks!
Andy
you do not need to wait for approval of one PR before submitting another. you can submit as many as you want simultaneously. given this, it is imperative to keep each feature in a separate branch, so that each individual PR is clean. if different PRs build on top of each other, you should note that in the PR comments that that specific PR depends upon another.
it is certainly tedious if you've never used git before, to keep your repository clean and remember to branch off for different features, and also to even keep your individual commits small and contained. as you learn more about git from reading and watching videos, you will see many people stress the importance of this. as a beginner to git you will find yourself spending more time editing your code and organizing your repository commit wise and branch wise. as you get more familiar with the process, you will just think differently from the start, and end up writing the initial code in a more compact way, and committing the changes more often and frequently, to preempt all the manual editing later. you can (and should) always edit your history locally before pushing any changes publicly. you can do this with tools like git rebase which is a command line tool allowing you to go back in commit history and revise commits and edit changes and drop changes. branches are cheap and easy to create and delete so you should get familiar with that process as you will be doing that constantly.
right now all of this will seem meaningless but as you get more experienced with collaborative development you will see the benefit. even if you started using git for your own personal project you will see the benefit of having a clean history when you need to go back and see how/why you made a change and/or why something might have broken. learning git is an investment but very worthwhile for any serious developer. you can browse the commit history of our project to see how each commit is usually a single defined change, with associated test files updated. or if its a refactor sometimes the commit is larger but thats not usually recommended. you can browse other proejcts to see how the commits try to stay small and clean as much as possible. and then PRs are simply a group of small commits (sometimes even just one commit) that create a logical new feature of bug fix etc
Statistics: Posted by guest3456 — Today, 17:48