Git, fork, what?

[SagaLore]

Can someone please explain git to me. Specifically, how does forking work. I think I remember people talking about contributing to a project and having it merged back into the core, uh, or something like that.

 

[Ken g6]

First of all, those two things aren't necessarily linked. Forking existed before Git, and Git doesn't have a "fork" command.

Forking normally implies separating your work completely from the original development path. Although it looks like some Git users are now using it synonymously with "branch". Git is famous for the ease of merging different branches, as compared to, say, Subversion. Merging means putting the best parts of two branches into one application. Do you understand that or do I have to use a recipe analogy?

Edit: I'm gonna go ahead. Here's a recipe for angel food cake:

1 3/4 cups sugar
1/4 teaspoon salt
1 cup cake flour, sifted
12 egg whites (the closer to room temperature the better)
1/3 cup warm water
1 teaspoon orange extract, or extract of your choice
1 1/2 teaspoons cream of tartar

Suppose someone else forks it (not with a real fork!) to replace water with milk:

1 3/4 cups sugar
1/4 teaspoon salt
1 cup cake flour, sifted
12 egg whites (the closer to room temperature the better)
1/3 cup warm milk
1 teaspoon orange extract, or extract of your choice
1 1/2 teaspoons cream of tartar

Now suppose the original developer adds frosting:

1 3/4 cups sugar
1/4 teaspoon salt
1 cup cake flour, sifted
12 egg whites (the closer to room temperature the better)
1/3 cup warm water
1 teaspoon orange extract, or extract of your choice
1 1/2 teaspoons cream of tartar
1 cup Cool Whip frosting

Now if the original developer likes the "milk" fork, (s)he can merge them:

1 3/4 cups sugar
1/4 teaspoon salt
1 cup cake flour, sifted
12 egg whites (the closer to room temperature the better)
1/3 cup warm milk
1 teaspoon orange extract, or extract of your choice
1 1/2 teaspoons cream of tartar
1 cup Cool Whip frosting

Although Git doesn't have a "fork" command, the commercial site Github does. I've only used it once, I think: to fork a broken application, fix it, then post a "merge request" on the original application.

 

[Markbnj]

Git is famous for the ease of merging different branches

It pretty much has to be, since the model encourages the maintaining of distributed copies of a repository, doesn't it? To be fair, I've never used it, but it has always struck me as asking for trouble. Merging is a pain in SVN, for example, but it's usually limited because you're finding out about conflicts earlier due to the requirement that you commit back to a central repo.

 

[Ken g6]

I gather merging with Git is much easier than merging with SVN. First, Git will auto-merge changes even in the same file, as long as they're not in the same area. Git would merge the above recipe changes, for instance, automatically.

If there ever is a conflict, Git has other benefits. First, since Git is distributed, you can commit much more frequently, even if the code isn't compiling for instance.

Now, suppose you have added two changes to your local branch: a new feature and a critical bugfix, in that order. With SVN, you might commit them both at once, and if merging the changes with someone else's work failed, you'd be stuck. With Git, you (should) commit each change separately. Then if you try to merge and the result has problems, you can revert back to your code, merge it to a separate branch, reset the main branch, pull in the changes from the central server, and then "cherry-pick" your critical bugfix commit into the main branch, excluding the new feature. You can then work on fitting the new feature in at your leisure.

Or, if you were smart, you'd stash the work on the new feature in a branch when the critical bugfix came in, and attempt to merge the new feature in later. I don't think it's easy to create new temporary branches just for new features with SVN.

 

[Markbnj]

I gather merging with Git is much easier than merging with SVN. First, Git will auto-merge changes even in the same file, as long as they're not in the same area. Git would merge the above recipe changes, for instance, automatically.

I'm not sure whether SVN would handle your recipe example or not, but in general the above is also true for SVN.

First, since Git is distributed, you can commit much more frequently, even if the code isn't compiling for instance.

This is what's always tripped me up when thinking about Git. Isn't it the case that "commit much more frequently" means you're committing to your local repository? I can do that on my file system 🙂. Doesn't that just defer identifying and merging conflicts until you're ready to commit your branch back to some other repo?

With SVN, you might commit them both at once, and if merging the changes with someone else's work failed, you'd be stuck.

When I work in SVN I work on one ticket/bug/fix/feature at a time, test it, make sure it builds, commit it back to the repo and deal with any merge issues, then move on to the next item. When as a team we worked in a branch we merged into the main branch once per day by using SVNs merge tool. The owner of the next item "popped" it off the stack by doing the merge, and then passed the virtual baton to the owner of the next item. Worked pretty well as long as everyone knew we were merging and could be responsive.

 

[purbeast0]

we switched over to git at work from svn a couple months ago and i'm just now starting to understand how it works. seems to over complicate things that were much easier in svn.

the whole concept of having a local repository and a remote repository just seems pointless to me.

 

[nickbits]

we switched over to git at work from svn a couple months ago and i'm just now starting to understand how it works. seems to over complicate things that were much easier in svn.

the whole concept of having a local repository and a remote repository just seems pointless to me.

In the same boat and I agree 100%.

 

[Markbnj]

Git was invented to support Linux kernel development, wasn't it? That means thousands of contributors, and I can see where a central repository on the SVN model would fall apart. Somehow you have to break the effort into teams and push the responsibility out to them. So... distributed. Makes sense. But I haven't yet been convinced that it makes sense for any normal-sized project, say, 5-10 people.

 

[purbeast0]

Git was invented to support Linux kernel development, wasn't it? That means thousands of contributors, and I can see where a central repository on the SVN model would fall apart. Somehow you have to break the effort into teams and push the responsibility out to them. So... distributed. Makes sense. But I haven't yet been convinced that it makes sense for any normal-sized project, say, 5-10 people.

i still don't see how it would fail. with svn you can still have your own branches to work on, then when they are ready, merge them to the main one.

i just don't see how having 2 repositories makes any sense (local and remote).

 

[Zxian]

The development model (and therefore your usage patterns within your development team) is completely different with git. The big thing to unlearn is the "remote" repo is just any repo that isn't on your computer. It could be the central managed repository, or it could be something that you wanted to grab directly from a co-worker. There's nothing special about where the data is stored.

We use it to track our data inputs at work. We have a repository stored on a network drive that all users have access to. We all do our work locally and push our changes to the repository on the network drive. It's quite often that we have multiple people editing different parts of the same file. As long as there are no conflicts, the lead analyst will then simply fetch all the branches, merge the changes together, and then push it back out. I can also be working on something locally (a side test case for example) that doesn't need to clutter up our common repository.

Git also has the ability to commit parts of files. Did some work that should be listed as two separate commits? 'git add -p <file>' and select the parts you want to move to the staging area (and then add to a commit). SVN, to my knowledge, doesn't have this ability.

After having so many nightmares getting SVN to work nicely during my undergrad, git is a breath of fresh air. The workflow is so much simpler, since the work I'm doing doesn't need to have any interaction with anyone else's work until a merge happens. And then the merging is pretty darn straightforward.

Performance is also miles ahead of SVN, since the only time you're ever accessing a network resource is during a pull or a push. Local access is much faster than network access.

Git is also purely file based. I could archive my entire git repo, move it somewhere else (even another computer), and simply resume my work. You could even use a single git repo to manage your file backups and archiving for you if you wanted. Just schedule a "git add *", "git commit -m 'Today's backup'", and you're done. Now you can restore your filesystem to any previous time you wish.


@OP - The Git Homepage has a lot of very good documentation on Git and why it's better than CVCS systems. Have a look at the "About" pages.

 

[Zxian]

i just don't see how having 2 repositories makes any sense (local and remote).

Imagine doing work while on a flight from LA to New York. You fetch while connected to the wifi in LA to grab the entire state of the remote repositories. Then you can work on the plane, commit away happily, branch, merge, whatever you want. Get to your hotel in NY and push the changes back out. And all this time, you're only pushing the changes that you actually want to be seen on the remote repo. Anything you tried during the flight (which may or may not have worked) never clutters up the remote repo.

The purpose of the local repository is to eliminate or reduce the amount of network connectivity (and traffic) needed. It reduces the amount of hardware overhead you need, since all git requires is a network port and a hard drive. You don't need rediculous amounts of RAM for your network repository, and you don't need a powerful CPU either.

 

[KLin]

We follow this branching model here at work using github

http://nvie.com/posts/a-successful-git-branching-model/

 

[tatteredpotato]

i still don't see how it would fail. with svn you can still have your own branches to work on, then when they are ready, merge them to the main one.

i just don't see how having 2 repositories makes any sense (local and remote).

I don't see how you can operate otherwise. It's be awhile since I've used SVN, but unless I'm mistaken you can only have at most 1 unmerged patch at any given time.

Also having non-linear history really makes more sense for version control IMO.

 

[Ka0t1x]

git-stash

One of the main reasons I switched to git.

 

[Crusty]

I used to use SVN exclusively for most of my school projects and small work related projects where I was usually one of the only committers. Now, at work I've been using git exclusively for 2 years and I don't see myself ever going back to SVN.

For me, git has just become part of my workflow, I don't think about it anymore.

 

[tatteredpotato]

git-stash

One of the main reasons I switched to git.

Some of my favorites:

git add -p               (interactively select portions of modified text to commit)
git commit --amend       (melt changes into previous commit)
git rebase -i            (rewrite local history)
git reflog               (list of SHA1's that have been at HEAD)

 

[Zxian]

Some of my favorites:

git add -p               (interactively select portions of modified text to commit)
git commit --amend       (melt changes into previous commit)
[b]git rebase -i            (rewrite local history)[/b]
git reflog               (list of SHA1's that have been at HEAD)

I'm sure you are already, but just make sure you're careful with that one. Don't ever rebase something that's already been pulled or pushed elsewhere. For cleaning up your local commits (squashing, reordering in a more logical order, etc) it's great, but it should be used sparingly IMO.

The reflog is also an amazing thing. My main reason for loving git is the speeeeeed. We've got a few 5GB+ repos here, and they're (almost) just as fast to push and pull from as a bare init.