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: Tim Ruehsen
Subject: Re: [Bug-wget] [GSoC] Git & Github workflow
Date: Thu, 23 Mar 2017 17:13:35 +0100
User-agent: KMail/5.2.3 (Linux/4.9.0-2-amd64; KDE/5.28.0; x86_64; ; )

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

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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