[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
signature.asc
Description: This is a digitally signed message part.