I was looking at that last night. I don't get what the colors mean in his post and the lines are they each a repo?
Reading it again now...
Say we have a 3 developer shop.
Here ill change that diagram up, now each dev would be a colored dot in his diagram and works from home or whereever.
There is a server somewhere where everyone can get in to, but as the integrator of master you cant pull from everyone's repo back to the server due to firewalls and non static ip's. So I don't get how we are making a new master?
Here is what it looks like to me:
http://postimg.org/image/pziuihd1t/

STOP AND SLOW DOWN. Your photo is totally WRONG You cannot mix the developers with the Branches. Not to sound harsh, but you seem to be in a hurry, and the concepts here use sound programming principles, that take awhile to get used to

Study this photo instead. You will never be able to checkout developer A or B's code regardles of Where they are.

Developer A clones origin.
Developer B clones Origin.
They each receive the entire copy of origin as a local repository.

Developer A works on Feature A, the Pink Line
Developer B works on Develop, the Yellow Line

Developer A Contacts you via email and says Feature A is ready, and sends you the link to his local Repo(within your firewall), you merge Developer A's Feature into Developer B's Yellow Developer Line, and tell Developer B to repull from developer. Developer B now sees Developer A's changes in his local repo. If he was inadvertently working on developer A's feature, Developer B will receive a Fix request in his local repository(because his fix to feature A doesn't match what you approved). This helps with delegating tasks.

If Developer B was following Directions and only working on develop, and finishes, after repulling the new change from developer A, he will contact you via email and say please merge my changes in develop with the master(blue dots). You will merge Develop into Master, leaving origin untouched.

Developer A and B will repull master.

After all having new masters they start on the next task.

After Bugtesting Developer A's Feature and Developer B's change to master, if you approve, ie everything works, you will push master to origin, and tell developer A and B to submit the next changes

Developer C gets hired on and has no local Repo, he clones from origin, which contains all the work that Developer A and B have already done and creates his own local repo.

Each dot in the diagram is a branch pull, ie when you tell Developer A and B to repull they will each create a blue dot.

Yeah thats why git having it all on my laptop is a problem, and making branches people wont know about is a problem. Were all over the place not in an office my team mates cant get to my laptop it needs to be on a server.
svn has worked for well for me for years, never had a server die or fail without a mirror or any of that.

Still reading the stuff from above

Sorry for a second post on the same comment.

With cvs or subversion there is a single master which contains all the information. If the server dies you've lost data, and if you have no backups then you're screwed.

With git, everyone who clones the project has everything they need to set up a new server, accurate until the point in time when the repo was cloned or last pulled. Every laptop or workstation is a full backup. If you're spread all over the world, then even the destruction of a continent by an asteroid will not lose your data.

The integration work flow model
Git supports several different work flow models and most corporate environments adopt the integration manager model – where a single person is responsible for all the commits to the “blessed” repository.

Developers clone from this blessed repository when needing to work on the project, pushing their changes back to their own independent repositories, asking the integrator to pull in their changes for approval and inclusion into the next release.

As a developer you don't work on the "blessed repo," you check it out, work on it, submit your changes to your independent repo, then ask the integrator to approve your change, and upload for you. After that your changes are seen by everyone. Even the integrator pulls the blessed repo into his local repo. The only difference is that in some companies the integrator doesn't have to ask for permission to push his changes. In your case, you would be considered the integrator.

All this does is enforce a monolithic central repository on software which has no need for it. It also places all the load for a reliable official working copy on a single person, which IMO is ridiculous.

If you're going to have a central authoritative repo, it makes sense to have a team who can commit to a central repo, as many (including me) do with github. That's really only necessary because we all work from laptops and nobody is always on line to get all the commits.

All this does is enforce a monolithic central repository on software which has no need for it. It also places all the load for a reliable official working copy on a single person, which IMO is ridiculous.

If you're going to have a central authoritative repo, it makes sense to have a team who can commit to a central repo, as many (including me) do with github. That's really only necessary because we all work from laptops and nobody is always on line to get all the commits.

Git was made by Linus Torvalds, who (if you didn't know) was the same guy who started the Linux kernel. He made it specifically with the kernel in mind, and he also mentioned in that youtube video that it's used on projects with a quarter million files. Don't think that's the kernel, but the kernel has hundreds or thousands of developers, not all of whom Linus trusts.

Git is designed such that each checked-out repo is a complete repo, with history and everything. It is, in effect, a complete backup of the repo, so if your "official server" goes down and you have 14 developers, then you have 14 backups of what was on the official server.

eyoung100 is exactly right on everything, except that when you "check out" a project from a remote, you use "git clone" rather than "git pull."

I think it would be a really good idea to go through one or several git tutorials. If you feel like you need a central repository, then maybe the github one would be a good idea. They take a lot of the harder administrative stuff out for you, let you focus on developing.

One thing I think the OP is having trouble with is that of access to developer workspaces. That's just not how it typically works, and I would call it a huge problem. When I clone a repository to my laptop, I'm the only one with access. Period. The same is true for all the other developers.

I can, on my local copy, branch off of the master for my own development. If I'm the only one who is working on that feature, then nobody else needs to have or see that branch. I commit regularly as I go, and don't need to worry about whether anything works or not. Meanwhile, I could pull from my local master as many times as I want, and it's not tarnished by my local development. When I get it working and tests passing, I can merge it to my local master and retest before committing (to local), and then I can push my changes to the central public repo with "git push."

What other people are saying about "master pulls" is when not all developers have write access to the central repo. It seems to me that the OP is working on a small team, and it's reasonable that they all have write access to the server.

Looking at that youtube video from early in this thread, I see a lot of really pertinent points starting right around 10:50, maybe a little earlier. Here's what I got from it:

Linus started with tarballs and patches for revision control.

He hates CVS and SVN, has never used them for the kernel but did use CVS while working for a company.

He went to BitKeeper for awhile, and this is what convinced him that a SCM was worth using.

He used three criteria to find a satisfactory SCM, and that basically eliminated everything available. See later.

He wrote git in two weeks, and it was better than anything else available.

Three criteria:

Must be distributed.

Must be fast.

What you get out MUST BE EXACTLY what you put in, or you get an error.

The first two I can understand, but the last one is crazy. Most revision control systems evidently don't detect corruption. I've seen it myself with both cvs and svn: The first clue that there is corruption is that your code won't compile. You fish around and discover that the file is borked.

I seriously recommend that video, even though I gave it a thumbs up before.

This is all too small? Big corporation? gitolite or a corporate account on github might be *the* thing you need.

I have been some sort of "Subversion Zealot" for many years. Subversion is just great. But after working with git a couple of years now, I do not understand how I could ever work with a non-distributed VCS like Harvest, CVS or SVN.

Now you have a git repository. It contains all your added files on branch master. Now lets setup the described development model.

Code:

git branch develop

All done. Now let's setup the bare repository for the server.

Code:

cd ..
git clone --bare myproject

This is now the folder which is put on the server. Its the central part of your model.

Now clone from the server the working repository.

Code:

git clone https://my-server/my-path.git

Now you have in your repo both branches master (which only holds releases) and develop (where develoment work like merging is done).

Now checkout develop

Code:

git checkout develop

Here you can do your work. For bigger features i create a branch like

Code:

git branch feature/cool-feature
git checkout feature/cool-feature

After you have done your work, add files and commit them to feature/cool-feature. Test it and so on.

now merge it to develop

Code:

git checkout develop
git merge --no-ff feature/cool-feature

Now all your work is on branch develop. You polish your work and merge it to master if its ready

Code:

git checkout master
git merge develop
git tag v1.0

It is all in your repository. Not yet on the server. Lets push it to the server

Code:

git push origin master
git push origin develop
git push origin --tags

Your working branch feature/cool-feature can now be deleted or be kept. Depending on what you want to do. Your co-workers can get your changes form the server like this:

Code:

git fetch origin

all data is now available to them, but their branches develop and master are behind the server. To pull them forward, they can do the following:

Code:

git checkout develop
git merge origin/develop

If they made changes to the develop branch, they merge it. If your changes dont interfer with your changes, git will do the work. If it encounters problems, you need to resolve them.

you can add other remotes like origin, like bob or alice. and keep all data in your repository. Merge bob's changes locally to your develop branch and so on.

It's only your definition, that the server is the most relevant part. There is no "right" or "wrong" repository. All are equal. It's only definition, that linus linux-2.6.git repo is the most important repo for linux.

still all your reading all the recommended git stuff ....
Thanks for staying with me.
I quit watching the video as soon as linus said "this is not a tutorial on git if you want that there is this thing called google"
I have definitely got git set up now on the server (Gentoo of course)
and can use it with ssh keys.

AHHH HA a "bare" repository is what I was missing! Thats a repo on the server we can all push to.
Now I don't have to worry about being code hoarder.
I was just getting to that on http://gitbyexample.org/
which is the best so far for my needs.

schorsch_76 wrote:

All done. Now let's setup the bare repository for the server.

Code:

cd ..
git clone --bare myproject

This is now the folder which is put on the server. Its the central part of your model.

Now clone from the server the working repository.

Code:

git clone https://my-server/my-path.git

Now you have in your repo both branches master (which only holds releases) and develop (where develoment work like merging is done).

Where there will be two directories on the server each with a git repo
one will be a bare and one will slurp up the new stuff from the upstream project?
developers can "push" incomplete or feature branches back to the "bare"
New stuff from upstream will need to be merged into the bare. - I think_________________Donate to Gentoo

Where there will be two directories on the server each with a git repo
one will be a bare and one will slurp up the new stuff from the upstream project?
developers can "push" incomplete or feature branches back to the "bare"
New stuff from upstream will need to be merged into the bare. - I think

If you do your work on a upstream project, you can adjust the development model. Add a branch upstream. Start all branches master/develop/upstream at the same commit. You merge upstream to develop, do stuff, merge to master and make your release. If upstream has a new release, you can update the upstream branch with that data commit it , tag it like upstream/v0.9.8, and merge it to develop. Git will do the merging. If there are conflicts resolve them. All your changes are the changes from the new upstream release are now on your develop branch and behave like expected.

If you started development branches from develop prior to the merge of the new upstream release, rebase your local feature/cool-stuff to the new head of develop. All changes will then be in your rebased branch feature/cool-stuff. Including all changes from the new upstream release. An other method would be to merge develop to your feature/cool-stuff branch.

This is basically a method with is used by debian package maintainers. There is one drawback. DONT REBASE PUBLISHED BRANCHES!!! Never ever!!!. Your co-workers would hate you! Rebase can be substitued by merging but is sometimes more convienient than merging.

Edit: You update upstream branch locally and push it like normally to the server.

However that the video is not a tutorial it will show you WHY you should not see it as a drop-in replacement for your current workflow. So please watch the video and take the advice the others gave instead of fitting the GIT idea into you current way of thinking. Fit your current way of thinking into GIT.

However that the video is not a tutorial it will show you WHY you should not see it as a drop-in replacement for your current workflow. So please watch the video and take the advice the others gave instead of fitting the GIT idea into you current way of thinking. Fit your current way of thinking into GIT.

+1 on that.

Most workflows are designed around the limitations of the tools available. Git is designed in a way that most of the organizational limitations don't exist. The video shows Linus expressing that wonderfully. He trusts a handful of people, each of whom trust a handful of people. Some of each of those handfuls intersect, but eventually you get to the hundreds or thousands of developers who contribute regularly to the Linux kernel. Each person puts out pull requests to his/her friends with new changes, they integrate into their own version and test accordingly. The changes don't pass through the entire universe of developers as fast, but each change gets more testing this way.

Edit:

I forgot the point.

Anyway, if git can handle that sort of a non-structural arrangement, then it can certainly adapt to pretty much anything you might want. It might be really beneficial to you and your coworkers to come up with something that makes the most sense for you.

If everyone is always on laptops and the lids aren't all open at the same time, then you might want a central server. Otherwise, you might not actually need one.

I'm putting in a good word for Mercurial. It has a lot of similarities to Git (distributed version control, designed by a kernel developer, cryptographically signed commits, supportive of central repositories, introduced at basically the same time), but it's a *whole* lot friendlier to use.

I've suffered through CVS and Subversion; I'd never want to go back to those--not even for the "benefit" of a central repository. Having the whole repository right there in your checkout is the way to go! I'd sure slog through Git before I'd go back to one of those server-based systems, but I'd much rather do it with Mercurial.

The Mercurial tutorials already mentioned in this thread are very useful. The concepts apply to other distributed version-control systems also.