New unreal project with friends, how to source control?

Hi Guys,

Me and a friend are currently trying to start a project to work on together and use Git for source control as we don’t currently have the option of hosting something ourselves.

We have read all of the tutorials and guides and managed to get the majority of it figured out, with one person having created the project, committed it to the repo and checking in changes etc.

How then do we get the second user to ‘import’ the Git repo at his end so we can then start working on the project simultaneously.

Are we missing something obvious as we feel like it shouldn’t be this difficult and we are just doing something wrong / stupid.

Thanks for any replies :slight_smile:

(This is as non-technical as possible so be warned it doesn’t use the right terminology per se)

Git is confusing at first. Basically your code is on a Git branch, such as “master”. Over time you might create other branches.

When someone wants to work on the project you “clone” the Git, then “checkout”, then work on it.

So at this stage each person will have a “copy” of the whole project.

As each person now changes stuff each person will have something “different” from the master branch.

That’s when you “push” your changes to the master branch, and then you “pull” your changes from the master branch.

This is now the harder part because now you have to make sure you want to have the right stuff added to the branch and you want to make sure people are working on the latest code.

So then that’s the push-pull management, branching, etc. which gets more hardcore. That’s when things like pull requests become important because there should be someone in charge of what gets added to the branch. For example, team members shouldn’t be able to “force-push” code to the branch.

Well that’s my layperson’s overview, as a layperson.

Don’t think you’re stupid or anything, Git is very, very powerful and it just takes time to understand how to “think” in a Git way, as opposed to a traditional SVN-checkout type thing. There’s also Perforce which I hear is good but haven’t tried.

From what I have tried with Git as I mention once you understand how to think like a Git (sounds horrible, I know) it makes more sense.

Finally for projects with large files there’s Git LFS or use Git ignore to only synchronise important parts of the project and use a separate repository eg. Dropbox(?) or Mega(?) for common, in-progress, etc. large assets. You don’t want to be cloning, pushing, pulling with huge files, that’s why Git is best suited to source code and not binaries or massive assets unless you use Git LFS (Github LFS?).

Good luck! :slight_smile:

I am working in tiny team (3 persons, 2 coders and 1 artist) and we decided to not bother with version control. We just post on trelo what part of project is modified by who. Then I migrate that improved part to master project and update it in dropbox (yes its like doing version control manually), but for just 3 people setting it is not worth the hassle, esp when your artist may be not quite happy with yet another weird app on his computer. Also manual merging forces me to check and test changed blueprints.

I have to agree with Nawrot. Perforce caused me more problems than it solved. These things are build for big studios with dozens of people working together.

All i have to do is pick up the phone and tell the other person not to open X blueprint until i am done! :stuck_out_tongue: Faster this way!

I’m gonna be the guy that says source control is a must even if you’re a single dev. Get a server, back up your work and use source control. I cannot imagine my life with out perforce.

Learning and knowing how any of the git svn mercurial, team foundation server or perforce work will give you a huge edge on other developers as you’ll already know what everything means and how to use it, especially if you want to work in the gaming industry professionally, most companies/ studios use perforce, knowing it will get you a job over someone else, i mean i was hired by 3 different companies because i knew perforce git and svn.

Not using source control is the dumbest thing anyone can do if they are serious about their projects development. source control isnt just about allowing other people to work on the same project. Its about controlling and managing the project.

I think this article is so relevant its not even funny.

As well as this article.

Honestly this might sting, but if you are not using some type of source control, you are a cowboy.


You are 100% right. Thats why i learned how to setup and use perforce. Everyone in game development should know how to use these super powerful tools.

Thing is that after using perforce for about a month i slowly started drifting away from it. Dont know why, but it was “slowing” me down. No logical explanation, just my experience.
Maybe there is something wrong with me. Spending all this time and effort to learn it and then reverting back to 1990! :slight_smile:

Hey all, thanks for all the advice in this thread. I’m one of the collaborators in Gazzardis’ project, and we god Git set up and are not making good progress. One thing I’m not so clear on is merging and versioning when we have non-text files like UE4 uses.

Will the plugin version these for us somehow? Or are we forced to manually merge everything, as it’s not text and Git doesn’t know how to merge it? For instance, if 2 people add nodes to a blueprint, will UE merge them for us, or will Github be able to do it, or is it something we need to do manually by opening both versions up and copying nodes?

> Or are we forced to manually merge everything, as it’s not text and Git doesn’t know how to merge it?


> if 2 people add nodes to a blueprint, will UE merge them for us


> or is it something we need to do manually by opening both versions up and copying nodes?


the best thing is if you try to seperate things you are working on as much as possible so you dont go over the same 17 blueprint files.

good documentation of what you have done with a commit and how it works also should help the one who is merging things.