next »

[ProgramGamer]

Discuss Git below. I am this close to losing my mind to it. 

[ProgramGamer]

And now dropbox keeps derping image uploads. Great.
Edit: fixed.

[Juskelis]

I haven't interacted with Git directly, but GitHub has been pretty user friendly for me.

Also dropbox is the leading reason I pay so much for internet; I really need to cut the cord.

[Dacke]

Discovering git was one of the best moments I have had in programming. Going from no version control (with constant slip-ups, sometimes ruining an entire small project during refactoring ) to actually being in control. Locally, out-of-the-box, with almost no overhead. Distributed version control is the best thing ever.

Did you look at the help I tried to give you in the General help thread?

[Layl]

As much as I like git, it can be such a fucking temperamental son of a *explitive* and *explitive* *explitive* with *explitive* in the *explitive* with a *explitive* *explitive*.










Still it's better than svn.

[Juskelis]

Still it's better than svn.

amen.

[oahda]

Only time I've had major problems with git has been when making mistakes myself, entering the wrong commands / wrong order / forgetting something. And even then it has usually been possible to reset things to how they were before my mistake. Just make sure you know what you're doing. Maybe one of those visual interfaces could be your friend if you feel lost in the terminal interface.

[Mittens]

I share the sentiments of Dacke, I just started using Git this year and I absolutely love it.
Before using it I accidentally deleted a script file which I then had to spend hours completely re-writing, since moving to git I've accidentally mangled or deleted other files and then been able to rewind them, it's really saved the day and I'm a big fan of how easy it makes working from 2 locations.
I used to copy files from one computer to another on a USB flash drive, what a fool I was!

[Dacke]

I'm happy to admit it can be a bit confusing at times, though. I only use git, but any open-source distributed version control is fine by me. I've heard good things about mercurial, which sounds like a slightly friendlier git.

[pmprog]

What do people have against SVN? I used it before Git, and still do some places.
Never had any problems with using either; and both beat me having several computers and several USB pens all with copies of my source - which I'd always end up getting mixed up.

Perhaps because I only use the real basic functionality? I never do branches and the like

[NoOneSpecial]

I fooled around with git a relatively long time ago, I still prefer GitHub's in web browser client to it.

[Layl]

<snip>

Perhaps because I only use the real basic functionality? I never do branches and the like

Yep, git shines in its functionality with branching, tagging, merging and the likes. It especially works great if you make use of its decentralized nature, allowing forks to be maintained independently while still allowing them to merge back.

[OccamsRazor]

I think source control in general is a finicky pain in the cloaca, but Git is probably the lesser evil out of the bunch.

[Mittens]

What do people have against SVN? I used it before Git, and still do some places.
Never had any problems with using either; and both beat me having several computers and several USB pens all with copies of my source - which I'd always end up getting mixed up.
Perhaps because I only use the real basic functionality? I never do branches and the like

When I was first interested in using some version control I tried out SVN but I always found it too awkward to use or know what versions various files were on. It's entirely likely I just had no idea what I was doing. I also didn't know how to have the repo hosted online, meaning I had one of my machines as the SVN server? (I don't even)

But yeah, currently I'm using TortoiseGit which is really geat for easily just hitting Pull at the start of work and Push at the end. I've also got the repo hosted on the GitHub website which has had some nifty benefits. At one point I needed a file from a specific commit in the past, I was able to just browse my way to the commit, find the file and download it on it's own.
I really can't believe I used to work without this set-up, I only wish someone had told me to do it sooner and I would have literally saved hundreds of hours of my life

[InfiniteStateMachine]

I use and manage git 95% of the time at work and home but I'm not a huge fan. I'd say it's serviceable but doesn't really excel in any area it specializes in. I really just use it because it's what's already being used. Sort of the baseline distributed SCM tool.

It has the worst auto-merge I've ever seen. I've never had an automerge do something destructive in any of the 6+ SCM tools I've used. Luckily the idiomatic way to use git is to locally branch on every change you do so even when an automerge goes to hell you don't lose anything more than your time.

I'm not sure why more people don't use mercurial over git. It has a simpler interface, large binary file support (for many years now) and some pretty cool stuff like non-destructive history re-writing. If there's some deep flaw in hg then I haven't seen it yet. Maybe the issue is that it's too similar to git to warrant a change.

If you have money and a server then for game projects Perforce is easily the best way to go. Well worth the money. It's also got free options now and I even have a cloud account with it. Perforce even understands the entire git api commands so you can use git clients to interact with it (although I have no idea why you would want to do that). What's more useful though is you can push out a Perforce CL to a git repository.

Of course if you are doing something like a code-only open source library then you would definitely want to use git/mercurial over perforce. Perforce is not good for large, lightweight opensource projects.

There are 2 source control solutions I'm really interested in trying in the future.

1) Plastic SCM. Sounds amazing for games. Code can be on a distributed stream while assets are on a centralized stream so you can branch easily if needed. This becomes more of a concern when your large project begins to hit thousands of developers.

2) Fossil. A more modern web based SCM with built in issue tracking.

Also SVN isn't really THAT bad. If you need a centralized model then you could do a lot worse. Like CVS.

Finally anyone remember Alien Brain? Now THAT was an ambitious project :D

[InfiniteStateMachine]

Also this git manual is essential

http://git-man-page-generator.lokaltog.net/

[TheLastBanana]

The last time I used Mercurial, I hadn't used Git yet, and my only SCM experience was with SVN, so take this with a grain of salt. But in my experience, I had a lot more trouble getting Mercurial to work with a team. With Git, if you're about to do something stupid like push before pulling, it refuses to do it unless you force it. With Mercurial, my team kept accidentally doing things like trampling each other's changes and leaving the upstream repo in a state that broke the SCM for everyone else.

Like I said though, we were all pretty new to SCM, so it was likely just user error and misunderstanding.

[odrez]

Hmm.. I'm using git on a daily basis and you could say that we're close.

Maybe a short introduction to the minimal stuff you need when working with git (because all the tutorials out there seem to include all the additional stuff that you need once per month or once per year) and some best practice for teams should help.

Here's how I start (I'll use command-line only because the GUIs often make things worse)

Step 1. Create a folder

/dev/mygame

Step 2. Initialize repository

Code:

> git init
Initialized empty Git repository in /home/user/Documents/dev/game/.git/

Step 3. Get the status of your repository

Code:

> git status

Initial commit

nothing to commit (create/copy files and use "git add" to track)

This will show you changes and stuff you need to commit or pull.

Step 4. Create & add some files

Code:

folder/ binaryfile  binaryfile2  great_stuff.txt  hello.txt  image.jpg

Step 5. run git status again (I do it a lot)

Code:

> git status

On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	binaryfile
	binaryfile2
	great_stuff.txt
	hello.txt
	image.jpg

nothing added to commit but untracked files present (use "git add" to track)

Step 6. Just add everything

Code:

> git add .
> git status

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   binaryfile
	new file:   binaryfile2
	new file:   great_stuff.txt
	new file:   hello.txt
	new file:   image.jpg

Git now knows what you want to commit.
   
Step 7. Run git commit and write a message

Code:

> git commit -m "Added X and Y and did Z"
[master (root-commit) 168087d] Added X and Y and did Z
 5 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 binaryfile
 create mode 100644 binaryfile2
 create mode 100644 great_stuff.txt
 create mode 100644 hello.txt
 create mode 100644 image.jpg

Step 8. run git log to see your latest entries

Code:

> git log
commit 168087d6156a3dd9dc0edc9d357a4f455f1dfe86
Author: Sylvius <[email protected]>
Date:   Mon Oct 5 21:57:07 2015 +0200

    Added X and Y and did Z

   
This is all you need if you're the only person working on the repository! With that, you're able to check out old versions.

The workflow is as follows:

Change your stuff, run git status, add everything you want to add (you can use wildcards *) and commit.
____________________________________________________________________________

If you're not the only one working on your game (First Team Member):

Step 1. Initialize a repository on the server:

Code:

git init --bare mygamename.git
Initialized empty Git repository in /media/Elements/git/unityprojects/mygamename.git/

Step 2. clone the repository on your local machine

Code:

git clone [email protected]:unityprojects/mygamename.git
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

The domain is username@domain:(homedirectory of username)/folder.git.
However, you can always use services like bitbucket.org to create repositories on their servers.

Step 3. Do all the stuff you did in the first section

* Add Files
* Change Files
* Copy and Paste, Move Stuff

Git will know about these changes

Step 4. Run git status

Code:

> git status

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	hi.txt
	smallimage.jpg
	stuff/

Step 5. Add everything and commit

Code:

> git add .
> git commit "Added YX and ZY"

Step 6. Run git push

Code:

> git push
Counting objects: 4, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 315 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To [email protected]:unityprojects/mygamename.git
 * [new branch]      master -> master

Your repository is now up to date.
__________________________________________________
 
But we're multiple people! How do we do that?
 
Step 1. You have the repository, now get your own branch:
 

Code:

> git checkout -b "myname"
Switched to a new branch 'myname'

Step 2. Make your changes, add everything, push everything. Maybe the server will tell you, that the branch does not exist:
 

Code:

git push
fatal: The current branch odrez_branch has no upstream branch.
To push the current branch and set the remote as upstream, use

git push --set-upstream origin odrez_branch

Do exactly as it says and run git push with --set-upstream.
 
Step 3. Everyone has it's own branch

Code:

> git branch
  my_branch
  another_person
* another_person_2
  master

 
Step 4. Merge

One person checks out his local master:

Code:

> git checkout master

He makes sure he has the newest version of master

Code:

> git pull

He then merges each branch step by step:

Code:

> git merge origin/my_branch
Updating 1bbfb20..616ab6d
Fast-forward
 other_stuff.xml | 0
 stuff.xml       | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 other_stuff.xml
 create mode 100644 stuff.xml

> git merge origin/another_person
...
> git merge origin/another_person_2
...

This should not fail. If this fails, it's because people commited changes to the same files!
Of course it's difficult for git to guess which changes are good to use.

Code:

Auto-merging hi.txt
CONFLICT (content): Merge conflict in hi.txt
Automatic merge failed; fix conflicts and then commit the result.

You should avoid that in general. Merging is ugly stuff.

git will produce things like that:

Code:

++<<<<<<< HEAD
 +hallo
 +hallo 2
++=======
+ hallo 3
+ hallo 4
++>>>>>>> my_branch

So the file now contains both stuff. Bad. Copy the changes from my_branch (or master) and run

Code:

> git checkout --theirs hi.txt

or

Code:

> git checkout --ours hi.txt

To use either the original file in the master branch or the new file in the other persons branch.
Now copy the changes to the new file how you want it to be:

Code:

hallo
hallo 2
hallo 3
hallo 4

Step 3. What a ride, now add everything, commit and push

Code:

> git add .
> git commit -m "Merged branches back to master"
> git push

You master branch now contains all the changes made by individual teammates.

You can checkout a version now if you want:

Code:

> git checkout -b v.0.0.1
> git push --set-upstream origin v.0.0.1

and go back to your branch:

Code:

> git checkout my_branch

Merge master to your branch:

Code:

> git merge master

This should not fail, since you already resolved conflicts while merging my_branch to master previously.

Step 4. Start working again

This is a very basic workflow that works great for smaller teams.
____________________________


But WHY?

- Git is decentralized, so you can easily clone the complete repository, move it to somewhere else, work offline, stuff like that
- Git knows about changes in your folder without needing explanation. SVN is a beast when it comes to moved folders, files, deletions etc.
- A Git Server is really easy to setup, runs 100% reliable and is lightweight. SVN will let you check the server and fix things on a daily basis.
- Git is extremely powerful and there are a lot of cool Web and Native GUIs for it.

Git is sexy.

And don't forget about .gitignore!

Code:

folder/ignored_subfolder
ignored_folder/*
*.ignored_fileextension

This will stop git from tracking e.g. IDE specific files and big binaries.

[ProgramGamer]

Firstly, thank you for posting such a detailed tutorial on such an old thread. It really shows how much you care, and I appreciate that very much!

However, I've learned how to use git already since I last posted here. Most of my problems stemmed from the fact that I was unfamiliar with the structure of commands, as I'd never used a command based program before (I didn't know how to set the directory with CD, or how the syntax of commands usually look). Now that I know all that, I must say that I find git much more friendly to use.

But wait, there's more!

From my experience so far, the documentation in place for programs such as git is simply not up to date with modern users who are being introduced to command line programs. It is full of technical terms that are impossible to understand unless you've worked with other such programs before, and assumes a lot of knowledge on other parts of how git works. It is a horrible experience for beginners even though it is a very powerful tool for version control, and that is why I would still not recommend it to newbies. I would teach them the basics of command line first, and then introduce them to basic git commands. But hey, that's just me!

[ProgramGamer]

Also: