Im not an expert at git, but I have a iOS project that has code that I would like to reuse. I will be switching out images and a little data to make each application different. I know you can do this with the targets approach but I wanted to keep everything seperate and out of the original xcode project. So my question is, do I create a branch for each new project, and if so what is the correct terminology or command to grab bug updates from the original code base into my new branch from the main branch? The new branch will never commit back to the master branch also.
I strongly suggest you make different repository for each project, not different branch.
If you have one repository for several projects and for each project different branch, very soon you'll have a mess in your repo.
Also, if you fix a bug on part of code which you want to reuse, you'll need to merge the fix with all branches which use that code.
So, I think the better and much cleaner approach would be to create different repositories for each project, and code which you want to reuse you can add as a git submodule.
So, you'll have repository for your iPhone project then submodule for your shared library, Restkit, and so on...
You will want to review the git branching section of the online reference at GIT-SCM. At a high level you will want to look at merging the various branches. Xcode 5/5.0.1 helps you immensely by using the menu Source Control > Working Copy > Project Name > New, Switch, or Select Merge Into/From Options...
Related
We're using Mercurial to manage a project that has two teams working on it. Our team manages the repo, and we're using hg flow on it, with default, develop and feature branches. The other team does their work in a separate repo, with us pulling in their changes every now and then.
The other team isn't particularly up to speed on Mercurial, and they've wanted to do their work on the default branch. This makes pulling in their changes annoying, because we'd like to keep our default branch clean.
We've done what Ned Batchelder suggested in http://nedbatchelder.com/blog/201111/advanced_mercurial_branches.html, but that still leaves commits in our repo with their branch marked as default. So does using Bitbucket's pull requests.
Other options that spring to mind are using patches or using graft and strip. I'd love to hear suggestions that would be less hassle.
If you want "Hard way, but nice results" you have to forget about easy pure-Bitbucket interface of syncing repositories
With Convert Extension --branchmap option you can rename any branch in source repository into any name. Thus, your workflow will be something like:
Prepare file for branch-mapping
Clone|pull from fork to local repository
Convert cloned repo, using branchmap, into repository with good naming of branch(es)
Push result of convert into your Bitbucket0repository
Or consider using bookmarks instead of named branches. Then you can move their changesets into your develop bookmark without any of its past default-ness showing through.
hey're not entirely crazy for wanting to develop in the default branch; it's the standard advice: https://www.mercurial-scm.org/wiki/StandardBranching#Don.27t_use_a_name_other_than_default_for_your_main_development_branch
I'm using TFS version control and am very new to version control in general. The project I'm working on needs a new feature added. Would I branch the entire project or would I only branch those individual files or folders as I work on them? It seems easier to just copy the solution folder and work on an entire new copy but then if I have to go back and fix bugs in the original version I'll have to do them again in the new version. I'm a bit nervous because I've never used branching before and I don't want to screw my project up.
it's personal preference but check out the Rangers Guide to branching here http://blogs.msdn.com/b/visualstudioalm/archive/2012/10/17/alm-rangers-ship-the-new-branching-and-merging-guide-v2-1.aspx
for your situation, i would branch the whole solution, it makes it easier to develop if you have the whole solution, when you are happy you can then merge in your 'feature' branch back to the original branch. If changes have occured on the original branch in the mean time you may have to manualy merge files during the merge operation.
I have a library containing a few classes. Now I want to split up this library into two separate libraries. What is the correct/best way to handle this in combination with source control?
My initial thought is to create a new repository for each new project and in the initial commit mention that it was split of from a now unmaintained project.
While I only have a few commits so far, an issue with this method is that the history of the project is lost.
It depends on which version control you are using. For instance, in git you can use filter-branch to do the trick.
You can make a copy of the original repository, then use git filter-branch to keep the history of the part you are interested in and dropping everything else.
$ git filter-branch --subdirectory-filter mydir1
$ git gc --aggressive
$ git prune
Beware this is destructive. You will see a considerable reduction of the repository size, only having the history of mydir1 and removing all those unreachable objects.
Then, repeat the same for other libraries/subdirectories. In that way, you will keep only the history that belongs to each part/library/directory.
If you are using a different version control system, then you have to figure out the equivalent way to do it.
The rule of thumb I follow depends on whether you will be developing and/or deploying the libraries independently. If you are separating the libraries simply for code organization and the code is deployed as a single solution, then there is no need or benefit to creating separate repositories.
On the other hand, if you will be versioning and releasing the libraries independently, then having the code in separate repositories helps this. So, for instance, if you are separating the code because some of it belongs in a share framework, then put the framework code in its own repository. This will allow you to maintain, build and release the framework separate from any applications that are built using the framework.
HTH
you can create a new repository but also you can create new projects under the same repository and delete the old one in time. actually, that's up to you. if you see the previous project as test level or pre-alpha stage, you may want to create a new repository. but other than that, using the same repository is very likely for this situation.
I have a project A. This produces a product that's working and already submitted to the app store etc. Now, I'd like to create a new project, let's call it project B, and I want B to be based on A. Obviously B will add more UI and behavior on top of A.
After doing some research, the only option seems to be using cross-project referencing, because I'd like to reuse Project A's XIBs, images etc in Project B. Am I correct in assuming that cross-project referencing should work in that scenario?
Well I'm having some serious problems in getting this thing working. I'd like to achieve project level reuse. In Java or in .NET this wouldn't even be a consideration, the technology allows that. Because iPhone doesn't support frameworks, I think the developers are pushed towards more primitive approaches like code duplication.
So, how can I tackle this problem. How can I create my Project B, based on Project A (including XIBs, images, etc)?
Thanks,
If A and B are so similar perhaps you could consider simply creating a new build target; this would give you a single project with target A and target B. Both targets would have access to any of the resources in the project.
If you have a fair bit of shared code then you can create a static library; iOS doesn't support dynamic linking to user-generated libraries, but it supports static linking just fine. This would make the cross-project dependencies useful, because you could have project B reference library A from project A and build it as a dependency.
I did this same thing at one point:
I copied and pasted the entire app and then had two separate apps that I could work on individually.
Contrary to popular opinion, it is possible to create iOS frameworks.
Maybe you could use a scm tool like Git or Piston (http://piston.rubyforge.org) and 'clone' the code. Do something like:
#add original project to git
cd /your/base/project/code
git init
git add . #Stages all files to check-in index
git commit -m 'Your commit message here'
Then
#clone the original project into a new one
cd /your/new/project/directory
git clone /your/base/project/code
git checkout -b aNewWorkingBranchName #create a new working branch to modify
#modify code to your <3's content, use git pull/push/merge/rebase/diff as required to track/update original project
This should let you develop the 'new' project independently, while allowing you to pull in changes when required. Piston allows 'vendor' branching against both Git or Subversion repositories, tying your new code to a particular remote revision. Have a look at its documentation.
So my team is just starting to use branches on our project, and we've run into an organizational issue concerning the way Eclipse/CVS handle branches and projects. My question is this:
Is it possible to ensure that multiple projects are always synched to the same branch with CVS in Eclipse?
Here's a simplified scenario:
Two projects: ProjA and ProjB, and two branches: Dev and Release.
So let's say both projects are synched to Release in my workspace, and I decided to add a new feature. I only anticipate that this feature will touch ProjA, so I naively branch only that project to Dev. So now my workspace is inconsistent.
After a few hours of work, I realize that I need to make a small change to ProjB, so I pop open the file in question and make my change, forgetting to sync it to Dev.
Later, after my changes are complete, I commit them. Now, I've just committed the changes in the first project to Dev, and the changes in the second project to Release. Woohoo, broken build!
A solution to this problem would either:
not have let me sync the two projects separately
not have let me commit to two branches at the same time
Now, in the real world, we have about 30 projects, and a number of developers working on feature branches, many of whom seem destined to use branching to break the build any way possible. I'd like to remove some of those ways.
Is changing vcs an option? Having recently transitioned at my work from cvs to mercurial, I don't think I could go back. I think that any of mercurial, git or bzr would solve those issues.
After much trial and research, it seems that because of the way branches are handled in CVS (that is, on a per-file basis), a scenario like the one I seek is not possible (at least not without some tool special-built to this purpose).
We ended up just going with a soft solution: By changing the color and format of the CVS label decorations in Eclipse to something more striking and isolated, it's much easier to casually identify which branch a project (or file) is synched to.
The Eclipse settings are found at Team > CVS > Label Decorations > Text Decorations and General > Appearance > Colors and Fonts > Basic > Decoration Color.
And, of course, implementing some best-practices along the way.
There are two approaches you can take here.
Name your Eclipse projects after the branch they're created. So if you're working on a feature branch for ticket number 123 dealing with ProjA you check out your Eclipse project as ProjA_123 (or ProjA_Dev if you wish). You can call your release branch ProjA_Release.
Alternatively you could maintain separate Eclipse workspaces for each branch.
So long as you have some system to identify which branch your working checkout is from, you should be fine.