I’ve been using GitHub for two open source Xojo project, but we now need to have multiple developers working on the same Xojo Web App.
My plan is to upgrade my GitHub account so we can have private projects, but I’m not sure how to properly use GitHub where I might be working on a Customers WebPage and another person working on an Invoices Web Page…
Do we need to ‘sign out’ code? I’m not very educated on this yet…
Thanks Tim!
BitBucket allows for free private accounts btw.
Make sure you explore the GitFlow workflow. In a nutshell, each developer creates a “feature”, does their work, then merges it back into the develop branch.
I have an email outlining this. Perhaps I’ll post that here.
we moved all our projects, especially the private ones to BitBucket.
Here is that e-mail. Forgive any typos.
First, here is a site with some good general information and examples. Scroll down to read about git flow.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Git flow is a popular way of managing revisions centered around a few basic ideas and actions. It is built into recent version of git and supported by clients like the free SourceTree and the commercial Tower apps.
You start git flow with two main branches, master and develop.
The master branch is never modified directly. It is the code for the currently released version of the app and it is only updated on a new release.
The develop branch is never modified directly either. It starts as a branch of the current master and is updated with changes that are developed in other branches (“feature” or “hotfix”, see below). The key here is that the develop branch should always be in a state where it can become the new master at a moment’s notice.
Git flow is then concerned with the actions that we as developers might take. The first common action is to start a “feature”. This feature should be appropriately named, e.g., “Add_invoice_query_window”, and is usually branched off of develop, although it can start from any commit or branch. The developer works in this branch to add and test his code, committing as he goes. Once complete, he “finishes” the feature. By choosing “finish”, git flow merges the feature branch into develop and optionally deletes the branch.
Each developer can have as many simultaneous features as needed and can manually merge one feature into another, or cherry pick changes from any other branch.
The next action that a developer might need is a “hotfix”. By starting a hotfix, git flow will branch off of master, not develop, and the purpose of a hotfix is to correct a bug that came up in the currently released version that cannot wait for the next release. Once a hotfix is “finished”, git flow will merge it back both into master and develop. At that point, the new master should be compiled and released.
The final action is the “release”, started after all the needed features have been merged into develop and it’s ready to be deployed. This is where you can make final changes like updating the version number, release notes, etc. When a release is “finished”, git flow will merge it into master and develop, and tag that branch with the version number. After that, the next cycle begins.
In short, start a feature (or features), make it work, finish a feature. When all your features are done, start a release, update version, etc., finish the release. If a bug in the currently deployed version comes to light, start a hotfix, fix the bug, finish the hotfix. By using “start” and “finish” through git flow, it handles the appropriate merging and tagging for you.
WOW. Thanks so much Kem!
Kem, this should be a blog post somewhere.
i think we need a forum feature where you can ‘like’ a post more than once 
Paul has offered to turn this into a Xojo guest blog post, so look for it there.
With git-flow, bear in mind it’s not just a methodology to deal with multiple developers as the subject is here but in fact, although it solves the problem eloquently, that is not even it’s primary purpose. It is an effective methodology to deal with change management, wether you are one developer or a team of a hundred.
For example, say you are one developer using a simple 1 remote repository setup. You are working on a new feature for your client, 1/2 through completion and they call you with a critical bug. You now have to go back in your repository, find the release commit, branch from it, fix the bug, somehow merge the stuff back in, and deploy but not deploy code associated with your 1/2 completed feature. There are ways to do this, but nothing as nice as git-flow.
In git-flow, this is easy as your master branch is always the latest version deployed, as Kem said. You then just start a hot-fix, which branches from master, fix the bug and complete the hot-fix. Master is now ready to be shipped to your client and your current develop branch contains the bug fix also.
If you use git, I’d highly recommend git-flow, regardless of developer team size. If you do not use any SCM system, I’d highly recommend you start ASAP. It can be a bit daunting at first, but in the end I think you’ll find it manages your release cycles so effectively that you’ll wonder how you worked before it.
I should point out that I was introduced to Gitflow by Jeremy. As far as I know, he invented the thing.
Ha! I’m not smart enough to come up with something as nice as git-flow… I think Vincent Driessen is the original creator of git-flow (A successful Git branching model » nvie.com) and interestingly enough, the git-flow methodology will work for almost any SCM system, but on some it can be expensive (SVN for example) and cheap on others such as Git or Mercurial.