bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [GSoC] Git & Github workflow


From: Avinash Sonawane
Subject: Re: [Bug-wget] [GSoC] Git & Github workflow
Date: Thu, 23 Mar 2017 22:22:18 +0530

On Thu, Mar 23, 2017 at 9:43 PM, Tim Ruehsen <address@hidden> wrote:

> A beginner should read 'Getting Started' and 'Git Basics' to get an idea of
> how Git works at http://git-scm.com/doc.

Just to make it more clear, Tim meant first 2 chapters of Pro Git
https://git-scm.com/book/en/v2

> - when your work has been accepted (merged into upstream master), your are
> done and start the next issue on another branch.

And delete the old branch (the one which got merged) either through
Github or Git (git branch -d)

> we should set up a command sequence example for the above (tomorrow).

I'm in!

-- 
Avinash Sonawane (rootKea)
PICT, Pune
https://rootkea.wordpress.com

On Thu, Mar 23, 2017 at 9:43 PM, Tim Ruehsen <address@hidden> wrote:
> On Thursday, March 23, 2017 9:08:45 PM CET Avinash Sonawane wrote:
>> Hello!
>>
>> I am familiar with git. But currently I'm feeling pretty overwhelmed
>> with git operations. There are so many of them!
>>
>> Also we are coordinating wget2 development on Github, which is though
>> a front-end to git but has its own work-flow. You have fork, pull
>> request etc.
>>
>> I have read sufficient git documentation from https://git-scm.com/doc
>> and manpages so I'm very quite familiar with the git data model and
>> its 3 states etc. I have also gone through the considerable Github
>> documentation at https://help.github.com/ I even went through
>> https://try.github.io
>>
>> Now, I'm sure other students appearing for GSoC must have gone through
>> the docs like me. But the problem is to figure out the efficient
>> minimal work-flow while dealing with the git and github with respect
>> to wget2 development.
>>
>> For starters my current (flawed) work-flow is this :
>> 1) fork the upstream repo. Let's call it origin (using Github)
>> 2) clone the origin/master (using git)
>> 3) Pickup an issue (using Github)
>> 4) For a said issue create new branch (git checkout -b)
>> 5) `add` and `commit` changes to branch (using Git)
>> 6) Push changes to origin (git push origin foo)
>> 7) Send a pull request to merge branch foo in rockdaboot/wget (using Github)
>>
>> Periodically keep synching the fork which involves:
>> 1) add remote upstream <- just once
>> 2) fetch upstream
>> 3) checkout master
>> 4) merge upstream/master
>>
>> Now I am sure there's an efficient minimal operation workflow to deal
>> with Git and Github with respect to wget2 development. I am interested
>> in knowing what's your Git-Github workflow? Please no tutorial.
>> There's tons of tutorials/docs on the Internet. Just the workflow you
>> use.
>>
>> I am quite sure this will be very helpful to current and future GSoC
>> students who are most often new to distributed version control
>> systems, particularly Git and Github.
>>
>> If we get helpful responses, I will add this "contributing guide for
>> GSoC students" to our wiki.
>
> Very good thing !
>
> A beginner should read 'Getting Started' and 'Git Basics' to get an idea of
> how Git works at http://git-scm.com/doc.
>
> When it comes to branching (maybe later), here is a good article (also
> explains some git basics): 
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Well, also whenever you have a specific question, search the internet. You 
> find
> a good solution for 99% of your questions.
>
> My general workflow when I want to work on a Github project that I have no
> write access (this is mostly the case):
> - fork the repo via Github interface
> - clone your repo to disk
> - for each issue you work on: create an new branch
> - switch to that branch and try to commit as often as possible (e.g. whenever
> you have one step completed)
> - when think you are finished: push and create a pull request (via Github
> interface)
> - ... now wait for review
> - if you have edit your code, do that test, commit and push again
> - ... now wait for next review (might repeat)
> - if you are asked to just change the commit message: 'git commit --amend' and
> 'git push -f'
> - when your work has been accepted (merged into upstream master), your are
> done and start the next issue on another branch.
>
> No more time now... we should set up a command sequence example for the above
> (tomorrow).
>
> More questions:
> - how to cleanup old branches
> - how to sync with 'upstream' (setting up remotes, merge, fast-forward merge,
> pull, push, ...)
>
> Regards, Tim



-- 
Avinash Sonawane (rootKea)
PICT, Pune
https://rootkea.wordpress.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]