I am working on Android project with 4 developers.
and the Client order the following :
New design for the app (4 developers)
Keep updates and fixes till new design ready (1 developer)
My issue is :
How to apply the above on Git repository (branches)
Shall I create a new branch for re-design and another one for update and fixes ? and what is the best usage to avoid code moving and repeating ?
some updates and fixes may affect java classes that under design changing.
Advice, please.
Very thanks
Since you are using Git, this can be done easily via Basic Branching and Merging workflow.
Your team should know how to apply Git operations like branch switching, merging and how to solve branches conflicts.
A full article about this can be found in Git documentation here
is covers a case similar to yours.
Related
I have recently started to look into android development (aosp) and read about "repo" tool/wrapper that takes care of all the android's sub projects .
While I think repo does a fairly good job at what it does, I wanted to know if there are any alternatives to it.
I thought git submodules are sufficient for this but many posts on internet discourage use of submodules ( due to some "drawbacks" which I feel are not drawbacks at all ).
Keeping in mind that the source code for different sub projects should have their own releases or indipendednt code bases I am not sure if git subtree is a good solution for this.
It would be great if someone can point out some alternatives to repo or any other information about this.
The repo tool is the standard way to work with AOSP code base. Sure you can manually manage the repos yourself but that is going to be rather tiresome and error prone.
Otherwise using submodules or subtrees won't let you inter-operate with Google and everyone else working on the AOSP codebase, so unless you are planning to do a one-way fork of AOSP there are no alternatives to the repo tool for working on AOSP.
repo has one huge disadvantage: it detaches HEADs. You can't switch to specific branch under specific subrepo. Unless you do repo start
tsrc, as far as I know, has less functionality but doesn't have this specific problem.
Also, you can use embedded mechanisms of build systems like Bazel (git_repository/new_git_repository).
I've been learning to develop against the Android source tree, and while things are going well I'm not sure I've completed things in the most efficient way to merge into future versions.
Background: Android has many repositories that fit together. In some cases, a repo uses branches with names like "android-5.0.0_r6" to delineate a specific release. In other cases, that branch doesn't exist, instead, a tag exists with the name "android-5.0.0_r6".
My method: What I've done is create a new branch, called "nowsci-5.0.0_r6" based off the branch or tag (depending on which that repo had) for the repositories I needed to modify. I then made my changes, and pointed the android manifest at my new repos and everything seems to work fine.
My question: What should I do when "android-5.0.0_r7" rolls out? Is there an easy way to create a new branch of "nowsci-5.0.0_r7" and merge my modifications from r6 into r7? Or should I have done this completely different?
Here's one of the repos for example: https://github.com/Fmstrat/platform_frameworks_base
Thanks.
Follow their lollipop-release branch instead of the android-5.0.0_rX branches.
Imagine mobile application that is planned to be implemented for both iOS and Android.
Development was started from the iOS version only and now the time has come to start with Android one.
iOS application's code is stored at its' own Git repository that named after the apps name, e.g. "MYApp".
Now I would like to create one common repository for both iOS and Android applications and name it again after application's name: "MYApp".
It is not a problem at first glance.
Just create repository, create 2 subfolders there and start working.
But.
I would like that Android developer could work only with his folder and iOS developer only with his one too and both of them could see only their own folders related history (log).
I worked with SVN previously.
Usually I created subfolders and you could checkout any of them to work only with this subfolder.
History was also filtered to your scope.
I'm stuck with implementing the same under Git.
Please, help me to find right direction.
I will sum up solutions suggested.
Use branching for different platforms. I don't think that it is good idea, because branches used for another purpose. It seems to me very "jacky".
Use submodules. Just create as many repos as platforms you are targeting to, name them "MYApp-iOS", "MyApp-Android", etc. and finally end up with "master" repo, that could be names as "MYApp" (without any suffixes). Then add all related repos to "master" one with git submodules feature.
Use git slave. Investigating...
Please, feel free to edit this list to brainstorm the problem.
There is a way to keep to kind-of-related separate projects in a same git repository utilising git branching.
But keep in mind that that is not why branching was implemented into git. One of its uses would be development of a radical new functionality to your app that might not see the release any time soon for example.
On the end: it is a matter of opinion. If you are prepared to administrate a more complex repository just to keep both codes on the same place - you can.
I would definetly make two separate repositories though. Couple of opinions on this topic can also be found here on SO: Git branches with completely different content
EDIT:
gitslave seems to tackle your problem. You might want to give it a try.
I am working on new version of an app. What SVN structure should I use for creating the new version of the app? Should there be a trunk and than branches for each version 1.0, 1.2 etc? 1.2 is really based on 1.0 and not on the trunk? So I would like clarification on how to structure this? Its really a several projects like model, ui etc and and the model does not change quite so much with reach major version/release, but the ui project does. So I would like advice on how to setup branches for say version 1.2. Also with SVN should each developer have their own branch?
If you are starting a new project, it is good to start with typical layout like this:
trunk
tags
branches
At least the trunk should be created initially, as you will probably put your initial code there.
Under branches, you can store feature or maintenance clones of the trunk, or just any other branches.
In any case, all this is just a widely used convention; SVN functionality does not depend on naming or layout at all. However, some higher-level tools can - for instance maven-release-plugin...
Before you commit to SVN, please, take a few minutes to read http://hginit.com/ and think about using distributed version control system (DVCS), like Mercurial or Git. It makes life so much easier.
I'm trying to create a fairly low-level change in Android source -- changing the package manger. I want to get the whole source using the repo tool described in source.android.com. I have a fork of the platform_frameworks_base project on github.
So, the question is how do I go about getting my platform_frameworks_base instead of the one provided by Android. I just want to be able to clone my own fork, create a branch in there and then push it in my own github. I can worry about pull requests to the main repo later.
Any help on the strategy/method of doing this?
p.s. My "workflow" is aimed to be similar to this: http://appanalysis.org/download.html
probably a bit late :) , but for the records, you might be want to take a look into this http://www.primianotucci.com/blog/fork-android-on-github