How To Contribute - Video Guide

Heya everyone, I made this tutorial to help those of you who are wondering how the process of contributing works. I hope this is a useful resource for all of you!

 

That is good and helping me ... Keep going...

 

Thanks for making this, Nathan, it's a fantastic guide that covers not only the technicalities, but also the discussion surrounding contributions.

 

I think this is a good place to ask this:

How do you do when you see a PR but think that the implementation isn't enough? Do you create a new PR? I feel like then it could get crowded. I created a new PR but I'm not sure that it was the right call

 

You can actually commit your new implementation to the same branch on which you have worked on and merge it with your master branch that would automatically update the already created pull request with your master branch. So you don't need to create a new pull request.

A open pull request always contains the latest commit from the branch doesn't matter when it is created. Let me now if that didn't make sense.

 

I meant to "fix" someone else's PR. Like, if you have an entirely different implementation, is it frowned upon to create a different pull request for the same issue? Or is it acceptable?

 

I don't think you can fix the implementation of someone else's PR unless they give access to their repository (then you have to fork their repo and push to that branch).
Also I don't think it is optimal to work on the same issue instead you can comment of someone's else PR which you think you can help with your suggestions. I wouldn't say it is not acceptable to create PR for the same issue but the ultimate merging permission lies with Unity Team. They get to decide which ones to merge and which ones to close.

 

You can open PR to someone else branch and let them know in comments of original PR. Person that owns PR can merge your changes and also Unity can merge both of them one by one.

 

@Kamyker is correct. You cannot push on each other's fork, unless the other user gives you writing access.
But you can still do a PR from your fork to the branch they opened a PR with.

For instance:

You:master

open a PR to ->

OtherUser:Bugfix

who opened a PR to ->

UnityTechnologies:master

 

So, Linux users cannot contribute since Git Hub desktop doesn't exist for Linux.

 

Can’t you just use command line to do all the git commands? Would think it works the same way, just not a pretty user interface.

 

Gitkraken has support for linux :https://www.gitkraken.com/
Similar to gitdesktop but with more features

 

Thank you but can we use this for these projects?

 

May want to ask one of the Unity staff like @cirocontinisio or @MileyUnity just to make sure, but I'd say whatever tool you want to do your own work in is fine, at least from what I've seen so far. Just make sure that tool doesn't introduce any unnecessary/temporary/extraneous files when you do a PR so that the code base doesn't get bloated.

 

You dont have to use github desktop to collaborate with a git project on github. The client you use doesn't affect the project.
https://git-scm.com/download/gui/linux
Git itself is a command-line program, these gui clients exist just to make life easier for nonprogrammers. Whichever gui client you choose, there should be tutorials for interacting with a project hosted on github.

 

Yes you can. At the end of the day all you have to do is commit your changed files to remote (github) and create a pull request to unity's repository so it doesn't matter which client you are using to commit you changes (command line, github desktop, gitkraken, or any other as stated by @Zold2012 )

 

Hey! Yes, like the others say you can use whatever Git tool you prefer and works with Linux (including the command line). The only reason Nathan put Github Desktop in his video is because it's a simple tool and he wanted to provide an easy choice for beginners. But anything goes!

Are you already a Unity user on Linux?

 

Simplicity is the key to power
I would always prefer great UI over command line

 

If you need a visual git interface to work with, I might also recommend installing visual studio code on your linux machine and you should be able to use the built-in git interface there.


Download vscode:
https://code.visualstudio.com/

How to use git in vscode:
https://code.visualstudio.com/docs/editor/github

Note that the above link also has a link to an extension that allows you to manage issues within the IDE (I haven't tried it yet, but it does sound super cool so I'm looking now for the first time)

@APSchmidt

 

First of all: Great video DapperDino! I think explaining git to newcomers is one of the most important things to do and you did a great job!

I do have two small suggestions for the process you described in your video:

(1) Merge master into your feature branch, not the other way around.

Reasoning: If you work on two features at the same time, you could not open two pull requests for each feature seperately. In general you would not be able to work on seperate things if you merge everything back into your own master. The pull request should go from your feature branch to the origin master.

(2) Before opening a pull request, make sure to pull the origin master changes into your feature branch.

Reasoning: Having updated your branch to the latest version of the origin master will increase the likelyhood of the branch to be merged without prolems when it is reviewed.


This is also according to the process cirocontinisio posted:

https://www.tomasbeuzen.com/post/git-fork-branch-pull/

I think that updating your video with the correct (standard) process would help a lot of newer people to not run into those problems.


Best Regards,
Zantis

 

I found that the standard recommendation is not merge the master and "feature branch" (branch for development) and for updating the "feature branch" recommended to use the "rebase vs merge" (in official Git Doc).

probability of it is very low

If someone doing the fix or features not in one hour (it's a common situation), with very big probability his commit with his changes will be after some new updates in this case merging new updates will be very badly is looked in history.

I didn't use GitHub often before this project (especial for disturbed development), therefore many simple Git tasks & questions wasn't clear to me. And I spent some time to find information & did some tests. I decided "shortly describe" the main tasks & variants of use Git concern to this project. Also I put there the results and compare different strategies for development (pros/cons)

The standard command line Git interface only used for recieve some information which absent in "Desktop interface".
I made video and put on Youtube (see description for timecode!!!), i think it may be helpful for beginners ("Git&Unity project") or veterans will left comments, if I'm wrong
(I did the most tasks by GitHub Desktop.)

P.S>
Dapper Dino video made great video, but for me it wasn't enough.
(In any case, I recommend to all begin watch from Dapper Dino video.)