Win GitHub for N00bs
#31
As a newbie to the world of Git myself I never got on with TortoiseGit so after trying various software packages I would recommend using Sourcetree from Atlassian, for me it was simple as a beginner to pick up and being from a major player there's loads of docmentation on how to do stuff plus there tons of guides, tutorials etc on the internet.

https://www.sourcetreeapp.com/

For info on Git from Atlassian see https://www.atlassian.com/git/

Whatever you do, don't any changes directly onto your local copy of Master, once you've created your fork then always create a new branch for each new feature you want to work on, so for each PR you want to create I'd recommend a different branch for each one then all changes in preparation for each PR can be separated. Working this way then allows you to sync your local Master to the remote Kodi master and push changes into your branch, to get your head around this way of working see https://www.atlassian.com/git/tutorials/...g-workflow.

Beginners guide to Sourcetree at https://github.com/GSoft-SharePoint/Dyna...ep:-Part-1 although I'd ignore the bit about using Gitflow.
Reply
#32
(2015-08-31, 11:07)DaveBlake Wrote: Thanks Razze, I can see that I need to keep up with master as best I can, but what about other pull requests that have not yet been merged?

To be specific there are a few of us looking at music library changes - yourself, evilhamster and now me. I hope and expect your PR commits will be merged, meanwhile my changes (improvements for classical music) are going to take me longer to complete let alone get them accepted. Not sure how best to hit a moving target? I have cut and pasted some changes into my code, but wondered if there was a way to merge selected PRs into my WIP repository? How can we best work together?

Well this scenario gets quiet complicated fast.
For one you can actually set my repo as another remote in git and check it out and rebase it onto your version.
But that's probably going to cause problems, when you try to send a PR from that branch.

For now, it would be nice to keep the changes small as possible to get them approved as quickly as possible I think.
Reply
#33
For info to you guys, we work with merge windows for PR's that aren't straight forward fixes.

1st - 20th of the month is the merge window during which any PR's can be merged into Master.
20th - to end of month is for merging bug fixes only, for any PR's not yet merged then use this period to get the PR's reviewed and make any changes asked for after a review, and so get the PR's in a state they can be merged in the next merge window beginning the 1st.
Reply
#34
(2015-08-31, 12:03)Razze Wrote: Well this scenario gets quiet complicated fast.
...
For now, it would be nice to keep the changes small as possible to get them approved as quickly as possible I think.
Yes it does get complicated!

I can see that small and quick has advantages, my first PR is like that and I hope it gets noticed and merged. But even the first step in improving classical music handling requires more than a few lines of code here and there, getting stuck in seems the only way. Have a look in my repo to see what I am up to https://github.com/DaveTBlake/xbmc/tree/...icBrowsing. Perhaps the few of us with music library interests can just keep in contact. I would like to play nicely in the sand pit!
Reply
#35
(2015-08-31, 12:36)DaveBlake Wrote:
(2015-08-31, 12:03)Razze Wrote: Well this scenario gets quiet complicated fast.
...
For now, it would be nice to keep the changes small as possible to get them approved as quickly as possible I think.
Yes it does get complicated!

I can see that small and quick has advantages, my first PR is like that and I hope it gets noticed and merged. But even the first step in improving classical music handling requires more than a few lines of code here and there, getting stuck in seems the only way. Have a look in my repo to see what I am up to https://github.com/DaveTBlake/xbmc/tree/...icBrowsing. Perhaps the few of us with music library interests can just keep in contact. I would like to play nicely in the sand pit!

Well if your branch is for "ImprovedClassicalMusicBrowsing" then everybody who wants to work on it could just fork that and commit his/her PRs to you and if you approve them you can push them consolidated to the main repo. The nice thing about that is, that GIT will still be aware of who did what.
Reply
#36
And I have already messed up.... Sad

Forked master, commited modified code, pushed , created pull request - all well. Then I commited some more code changes to my repository, wanting them to be my WIP not wanting to go any further, but turns out they have been added to my PR. How do I undo this mistake?

I seems that I need a new branch for each PR, or just work in progress. So how do I move a commit from one branch to another? Will that remove it from the PR? Handholding needed I'm afraid.
Reply
#37
2 ways...

1) You can git reset --hard <hashof lastcommityouwant> and force push

or

2) git rebase -i HEAD~N (where N is the total number of commits you made) and when the dialog pops up to select squash reword etc and remove all the commit entries you dont want to keep (keep entries for ones you want) you made from that list from that pop up and save/close and proceed then force push
All commits removed are deleted.

IMO 1 is simplest.
Reply
#38
Thanks for that. After some flailing around I ended up closing the PR and raising a new one on a branch with just the simple code change in it. Had trouble forcing a push. Not sure if I have lost my code changes, hopefully I have local backup.

Zag could be helpful to mention the need for a branch per PR in the instructions.
Reply
#39
Both solutions I mentioned work and aside from this, while this thread is OK for introducing something, its duplicated information already posted somewhere else. I like initiatives like this but I hate the duplication of same information with some different spin for the tools the person who posts it decided to use.
Reply
#40
I have opened a github account and did the setup step by step. how i can use it as a repo for my kodi to share with friends?
Reply
#41
How do you go back to an expanded "git log" view from the condensed pretty view?
Reply
#42
It may sound oddly, but I am a web developer and I struggled with GitHub too... Thank you for an informative article.
Reply
#43
Update your fork with remote changes
Sync changes with the original project you forked from

1) Right click on the repository >> Settings >> Git >> Remote
2) Change remote to "upstream" and the URL to the original projects github URL. Click Add/New to create the new remote.
3) Click yes on do you want to fetch remote branches
4) Right click >> TortoiseGit >> Pull
5) Change remote to "upstream"

Source: http://stackoverflow.com/questions/72974...aster-copy

Squash commits
Combine multiple commits into 1

1) Right click on the repository >> Show log
2) Select the commits you want to squash
3) Right click and select "combine to 1 commit"
4) Right click >> TortoiseGit >> Push
5) Change remote to "upstream" and select Force known changes
Reply
#44
Thanks for this!
Reply
#45
I've been using the Github Desktop client a bit more recently and starting to really love its simplicity.

Finally I worked out how to sync with the origin!

Update/Sync a repo to the most up-to-date original repo commits you cloned from
- Get your cloned repo into the Github Desktop client
- Repository >> Open in command prompt
- git remote -v (to show all the remote locations)
- git reset --hard upstream/master (to reset to the latest commit of the origin
- Then go back to the Github desktop and push your changes.

Your cloned repo should then be exactly the same as the original repository. Yey!
Reply

Logout Mark Read Team Forum Stats Members Help
GitHub for N00bs1