I'm getting lost with Git branching model and the workflow that I want to create for my team (developers + designers).
Suppose that the project is based on a MVC pattern, so we have a structure similar to :
Models/
Controllers/
Views/
Developers works on the M & C parts with some basic/generated views (Rails, Django or CakePHP app for example)
and Designers works on the V part
How can I manage that developers works on M&C and keep some basic crappy views, and in the same time, designers make sexy views based on controllers actions coded and added by developers progressively ?
I tried to make it works with 3 branches :
master (production-ready)
dev
ui
but no idea how a designer working on ui branch can keep the code elsewhere than /views updated an a working app...
Thanks folks for help !
With git, there's no reason for developers to work on a separate branch or to have mocked up views. Have designers and developers work in the same branch, on the same codebase. When a view is done (or at least improved and not crashing) have the designer commit and push them to a master repository. The same is true for developers: when a local change is 'done', have them commit it and push it.
Before pushing, each side needs to pull (to ensure there are no conflicts). If the two groups are working in mutually-exclusive pieces of code (separate files or even separate parts of the same files), then the pull will simply update the local copy and all will work well.
With this, both sides are always seeing the most up-to-date codebase, and contributing directly towards the exact end goal, watching it evolve.
Git is so simple to use, theres no reason everyone should not have their own branch to work out of. Hell, thats one of the main reasons to use a version control system. In Git, commits are cheap.
Typically, we have a master, and anyone who is working on updates or features will branch from the master and branch a branch if need be, then a release master (someone like me) will take care of merging them all back down, checking for conflicts, testing the release and merging back to master.
As you work on it, others can receive your changes by doing a fetch/pull against your branch to pull in the changes.
Git isn't magic. It doesn't let your designers use code that the developers are actively writing. The developers still have to write, test and commit their code, and push it some place the developers can pull it from.
Typically you'll have a "bare" repository that all parties push their work to when it's ready to be shared. Everybody else pulls that work down. It might be the designers job to pull the developer's work and merge the dev branch into the ui branch, for example:
git checkout ui
git fetch
git merge dev
If you really want to enforce things like branch and path rights, I suggest you checkout gitolite
This will allow you to manage access at all sorts of levels.
Related
We are using visualstudio.com TFS to store the source code. We have DEV, STG and PROD branches. now I want to automate build and release to IIS server.
But it looks like to me that TFS compiles the code from the branch where I commit to, and that's the only build, after that I can install the same binary on all the servers.
But it doesn't seem to be ok, because what if we find a bug on the live code, so we need to fix it, but we already have new code in DEV, and we don't want to revert, and install the old code with the fix on the dev server?
What I think we should do is to merge the code from DEV to STG, from STG to PROD, but I couldn't find any module for that. And it looks strange, I would be surprised if I am the only person whats to do this, especially because it is doable with Jenkins.
thanks
I typically discourage automating merging of code between branches; merging should be a deliberate action. When someone expresses that desire, it's usually a sign of a problem with the branching model and deployment model they're using.
Code promotion branching (where you have one branch that corresponds to each environment, as in the scenario you described) is a bad practice because it encourages you to build different sets of binaries for each environment. You build something for a lower environment, test it, validate it, then totally disregard that testing and rebuild from source. That should terrify you, especially for production branches -- you have no idea if what you just built is going to work properly.
Current thinking is to minimize the number of branches you have, and instead isolate in-progress work behind feature toggles so that features that aren't ready for production can simply be disabled, but still allow deployments to take place. With sufficiently mature feature toggling practices and testing practices in place, you can actually eliminate branching entirely and work out of a single branch, promoting binaries to production whenever your automated and manual QA process deems the version they're testing is good.
Assuming you're using TFVC, if you want to maintain a code promotion branching strategy, then you'll need to maintain multiple builds and releases, one for each branch/environment. Typically, in this kind of scenario, I'd eliminate the stage branch entirely. Anything that goes to the Dev branch is built and deployed to Dev. Anything that goes into the Prod branch is built and follows a deployment pipeline from staging->production. Hotfixes can go directly into the prod branch and be merged backwards. There are tons of strategies for branching; you'll need to read up on the subject and design a branching and release strategy that works best for your team.
Do you really need a Branch to CheckIn / CheckOut Code in TFS i.e, just add files to a folder ?
What would be advantage to Branch in that case ?
You do not need a branch to check in and check out.
Branches however provide you with the ability to make changes to more thank one version of your code at once. Lets say that you have one folder at $/ProjectA/MyAwesomeApplication/Master. You can happily work away, checking in and releasing. At some point you find a bug in production that needs fixed immediately. However MASTER is well beyond what was last released and you don't want to deploy those changes yet.
You know which build is deployed and thus which changeset. You can branch MASTER at that changeset (the past) and create $/ProjectA/MyApplication/QuickFix. There you can fix that bug and ship, then merge back into MASTER and delete that branch.
Now obviously this is expensive and time consuming. A better way would to move forward and just ship what is in MASTER. If you have feature flags and good testing them you should be able to do that. There are however always those exceptions to that rule, and that's where branching comes in.
If you are using Git in TFS rather than TFVC the story is different.
The Microsoft ALM Team describe the Basic Branch Plan as needing a MAIN, DEV, and RELEASE branch.
I am working on introducing branching/merging to a new team who currently uses source control with no branches whatsoever.
I was wondering how the RELEASE branch is actually used.
Can changes be made in the DEV branch then be merged up to the MAIN branch without needing a RELEASE branch? MAIN would still be read-only. It would basically be the RELEASE branch in essence. The reason I say this is because we don't have that many changes but I want to isolate the stable code from new changes. Our concept of a "release" per say is not yet well defined. I am still working on that.
I just don't know if my team needs a RELEASE branch (considering our needs specifically).
I would appreciate some comment about the strategy of just having a MAIN and DEV branch.
Typically the release branch(es) are used for "safekeeping". Basically the same as a label.
Releases to production are usually a pretty important event, and you want to know exactly what source you released (in case you ever need to go back to it). Way back when people used to create Labels to track this, but creating Release branches is better for a couple reasons:
Labels are mutable in TFS, meaning somebody could change a label and there would be no audit trail
Branches are also mutable of course (changes can be checked in), but this can be locked down via branch specific permissions
Also if a change is made to a Release branch (which it never should be), at least you have an audit trail through history
Even though a branch looks like a heavy-weight operation creating a copy of your entire code base, in reality TFS just creates a new pointer to the same files, so the storage cost is trivial
I went the other way when I implemented TFS at a client (replaced SVN). What I did was introduce a MAIN branch and a RELEASE branch and not a DEV branch initially as that seemed very confusing to the team. It is also hard to convey the purpose of a DEV branch to an SVN familiar team initially.
The main purpose of our RELEASE branch was to preserve a historical placeholder as said in another answer. Currently we are using Git and we have a CI server that does the release process and branches to release/$version_number. I think that concept might be easier to understand and convey to your team. i.e. automatically create release branches when you actually release.
we have a team of 3 and have about 10 clients for our branded/customized apps
All of the customized apps have a central code base in git (master).
We would like to use git as the central repository for all of the apps.
What we would like to achieve is:
we will set up a code base as master, it has its dummy graphics and data.
Each time we have a new client, we will make a new branch (client1). Update graphics and customize the app, then we deploy to the production.
So developers will work on their local machines, make a sub branch (client1-1, client1-2) etc
then commit back to parent branch (client1).
Later, if we want to commit a change from client 1-1 all the way back to master, is that possible?
Also, is that the standard development process for iOS app ?
I feel that is not a good idea because, when you deploy to production or merge with the master, you will be practically be spending a lot of time on merge conflicts, then getting the code to the production. If i were you, I will have 10 different git repositories and if a new customer comes, then i will create a new one. Since, git is free, creating a repository will not be difficult. Saves you a lot of time and tension as well. Once the repository is ready, then clear all your production to make it as if new. Then push the ready repository. Hope this helps...
We are allowing external consultants to work on a portion of our source. We created a new TFS project and granted them rights to that. Branching does work between TFS projects, so we can branch the "real" TFS project they're working on to the consultant project. However, we only want to expose portions of it. Here's what we want (simplified):
OurProject
Mainline
Applications
Secret1
NewApp
Libraries
Secret2
Shared
ConsultantProject
Mainline-Branch
Applications
NewApp
Libraries
Shared
If we simply branch Mainline and delete the Secret folders on the branch, merging back must be done carefully to avoid deleting the Mainline Secret folders. We want to simplify future merges (both ways) while minimizing risk.
How can this be accomplished?
I know this may not be answering your question, but rather the intent of your question. Why not just set permissions to hide those secret items from the consultants and branch as you would any other time?
I agree with Alex. TFS doesn't have any built-in mechanisms to handle sparse branches. The closest analogue in TFS is branching/merging by label, but that strategy brings a ton of management overhead which is very error prone.
So, just let the branch/merge system do its thing and use ACLs to ensure your consultants can't see the Secret Sauce.
Note that for complete security, you'll need to create a 2nd solution for them that does not include any of the Secret projects, then ACL the main (all inclusive) solution out of sight. Do any non-Secret projects depend on the Secret projects? If so you'll have to do something similar (though slightly more involved).
Instead of branching and then deleting files/folders from the branch, branch only the files that you want them to have access to.
eg:
Branch Mainline -> $/ConsultantProject/Mainline-Branch.
Right click on $/ConsultantProject/Mainline-Branch/Applications/Secret1 and undo your checkout.
Similarly undo checkout on $/ConsultantProject/Mainline-Branch/Libraries/Secret2.
Check in your branch ($/ConsultantProject/).
With this completed, merges from one to the other will not affect the files/folders that you didn't branch.
TFS really likes for all dependencies of a project to be inside one folder. I would restructure your folder layout quite a bit. Here's how I would do it.
TeamProject
SecretApplication
SharedLibrary1
Application1
SharedLibrary1
SharedLibrary1
ConsultantApplication1
SharedLibrary1
Here's the detail...
Notice how all the apps are peers? SharedLibraries are shared/branched into the apps that use them. That way apps can move forward at their own pace and pull down shared changes at their own pace, and merge their changes to shared code back at their own pace. TeamProject->SharedLibrary1 is the "mainline" for SharedLibrary1. Everywhere else you see SharedLibrary1, it's a branch. Each application folder is its own "mainline", making your structure more app-centric than "all our work" centric.
With this setup, you merely make a branch of Application1 and call it ConsultantApplication1. That way you can setup your security to allow your consultants to only see that one app and all its dependencies. They can merge and pull at will. Well, they won't be able to merge without seeing the source project, but you can. All other apps in your team project will be invisible to them.
Let me know if I've misunderstood something or there are some requirements preventing you from using a structure like this. If there's a secret shared library under Application1, we'll have to think on this some more, but I think that would have compilation issues anyway. Regardless, placing all dependencies for an app under a single folder helps a ton and is a great practice.