I have a question about git.I'm working in a project and i have 9 branches, the first branch name was make users system.
Today i want to add an avatar to my users but i don't know what is the step to do with git.
Should i create a new branch ?
git checkout -b add-more-details-to-users
Or just switch to my first branch make users system then add changes ?
thank for helps
It all depends on your workflow. If you're working in a team, most of the times when implementing a new feature it's better to create a new branch, test it and merge with the master. It's not a good practice to put too much code and implemented features in one branch since it increases the possibility of breaking up some other functionality.
Also I would suggest you to make your branch names more descriptive, like: add-avatar-to-user , not make-users-system and if you're using any project management tools, task/story id like so: add-avatar-to-user-12345
Take a look at this link, I like this kind of workflow, we are currently using it in our team:
http://scottchacon.com/2011/08/31/github-flow.html
Since it sounds like make users system is like your master branch, you should checkout a new branch from it, which is called a feature branch, add the changes and, when you're happy the changes and everything works, merge it back.
You should really read up on some articles on how to keep your branches organized
http://nvie.com/posts/a-successful-git-branching-model/
Related
I finished working on a local branch1 and merged it to master.
Now I would like to work on another feature for my application and so I will create a second local branch2, finish to add the feature and merge to master also branch2. This can go on for as long as I need to implement my application with features and until my application is completed.
Suppose now that after all these implementations I would like to make some improvement or change on the topic that was the job of branch1, say the static pages about, help and contact. Is it possible to checkout to and reuse branch1 for these changes or that branch cannot be used anymore and should rather be deleated?
After a while there might be a considerable pileup of old topic branches that I initially may have wanted to keep for these purposes. However these old branches are all outdated, no more a complete reproduction of the master branch as they were when created: is this a prerequisite in order to merge with success?
The branching/merging strategy is yours to decide but you seem to describe a feature-based workflow.
In that case, after you have merged your feature branch branch1 to master, the content/history of this feature is contained in the master branch thanks to the merge. branch1 becomes useless and even obsolete with time so you can safely remove it so that old feature branches don't accumulate in your repository.
If you then look at the improvements you want to add to the functionality introduced by branch1, you can see those improvements as a new feature and therefore create a new feature branch from master to perform those improvements.
How you should organize your workflow is rather subjective and the best strategy often depends on how the project is organized in terms on contributors and how you deploy your changes.
You can use these old branches, but ... you should merge new changes from master before (So you can avoid big merging problems in future). When you need to reincarnate old branch do:
git checkout very-old-branch
git pull ./ master
# do some changes into very-old-branch
git add .
git commit -m 'changes in the very old branch'
# need to merge very old branch with new changes into master again
git checkout master
git pull ./ very-old-branch
git push origin master
But it would be better not to be necromancer and to just create new branch and make changes in it:)
You should take a look on gitflow.
Its a very known workflow for doing such kind of development as you are asking
The full workflow will look like this. In your case you refer to the feature branches (purple ones).
The relevant article is here:
http://nvie.com/posts/a-successful-git-branching-model/
As you can see you keep working on new features all the time and once you done with them you simply merge them back to dev (in your case can be master)
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.
I have created a basic admin system using RoR. It has very basic functionality such as users, roles, security features and a basic UI. I want to put this project into a master GIT repository.
If I want to create future projects, I'd like to use this base project as the foundation. Do I create braches?
MASTER PROJECT
MASTER PROJECT > SUB PROJECT #1
MASTER PROJECT > SUB PROJECT #2
So both sub projects are identical to the master project at this point. If I want to make a universal code change to any file within the MASTER PROJECT, how do I make that change trickle down to all sub projects. That is my FIRST QUESTION.
SECOND QUESTION:
What if I want to make a code change to a particular file on one of the sub projects?
e.g.: If I customize the layout in SUB PROJECT #2 (application.html.erb), I want that change only to affect SUB PROJECT #2. I want all sub projects to use the application.html.erb from MASTER PROJECT UNLESS it has changed (customized). It would be nice if SUB PROJECT #2 only contained the one customized file. All other missing files fallback on MASTER PROJECT.
THIRD QUESTION:
If I make a change to application.html.erb in the MASTER PROJECT, it is supposed to tickle that change down to all sub projects UNLESS one of the sub projects has a customized change to that file already. In this case, SUB PROJECT #2 does.
I'd want GIT to either:
a) Skip the update on application.html.erb on SUB PROJECT #2
OR
b) Prompt a warning to allow for some sort of merge.
Does that make sense? Is this setup possible? What would it be called? Where do i start?
Question 1:
You could use branches to track this. However, you should also consider whether what you need is simply a set of templates.
Git does not perform automatic merges by itself. You can write a script to do this, but otherwise you'll need to manually perform a git merge on each subproject branch.
Question 2:
Any branch you create will initially be identical to the original branch (master), at the time you created the branch. It will not change until you commit changes or merge in changes from the master branch. It wouldn't make sense to have this branch contain only the one customized file, so you may want to consider why you're asking for that if you want to use version control branches. The branch may only contain modifications to the one file, but nothing enforces this.
Question 3:
This is what git is designed for. When you do a git merge on the subproject branch, git will try to automatically merge the content and if it fails it will mark a conflict and allow you to manually perform a merge. You can also tell git to use another merge strategy, such as 'keep the local version', but this is a more advanced technique, and probably isn't what you want.
I recommend you start with the git-tutorial and make sure you have a good understanding of branching in git. Then, revisit this idea and make sure it still makes sense for what you're trying to acheive.
Maybe it's the right choice to put your master project into its own repository and make a new one for each project. There's git submodule which enables you to integrate other repositories in a project. YOu should try to have project specific changes only in the relating repositories, changes on the master project you can update via git submodule!
Currently we have a branch structure like this: Develop --> Release. I want to change it so that it looks like what the TFS Branching Guidance document calls "Basic Branch Plan". It looks like this Develop <-- Main --> Release.
I was going to do this:
Rename Develop to Main (creating Main --> Release)
Creating a branch from this Main reusing the "Develop" name (creating Develop <-- Main --> Release)
Will I have problems with TFS reusing an old branch name for a new branch? Know any gotchas or things to look out for?
Additional Info
I did this in a test instance creating test branches without any files, pending changes, history, etc. (not a good real test) and TFS let me do the rename and branch without difficulty. However, I won't feel comfortable with this unless I can take our production TFS project collection, restore it in the test instance, and test the rename/branch on real data. There is a lot of history and branches there and I don't know what will happen. As noted in the answer, there are other considerations before doing this.
I'm preparing to do similar steps (except I'm moving subfolder locations of both parent and a child while grandchildren stay put.)
QUESTIONS:
When are you planning the rename?
Are there any child branches under Develop branch that you didn't mention?
Do you have any shelvesets against Develop that might be impacted by the rename?
General answer: Proceed with caution. From my reading branch renaming in TFS2010 can cause a few unexpected side effects. TFS will be doing the following steps (under the hood) for your scenario:
Rename Develop to Main ==> Branch Main branch from Develop, then delete Develop branch
Create new "Develop" branch from Main
I recommend reading the following posts:
Renaming Branches in TFS 2010 (ChandruR’s Blog)
"MSDN Blogs > ChandruR's Blog > Renaming branches in TFS 2010
So my recommendations for this case:
Avoid renaming branches - a cleaner solution would be to, at the right point in your release merge all changes to a parent branch and then re-branch to create a new branch hierarchy.
Or for the brave of heart :)
You will need to time the rename of your branch, to a point in your release where you can merge to all related branches. The steps to follow are:
..."
Renaming branches in TFS2010 - But it works on my PC!
“In TFS 2010 behind the scenes a rename is actually a branch and delete process, this meant we ended up with the new branch, but also a deleted branch of the old name. This is not obvious unless you have ‘show deleted items in source control explorer’ enabled…”
"Now implemented as a branch + delete behind the scenes (new name is branched from the old, then the old name is deleted). This allows traceability in History, but allows us to get around the problems with merging renames (see Add, Rename, Add scenario). "
.
RANDOM THOUGHTS
Get all devs to merge (or abandon) all safe changes in child branches of Dev. Also prune any inactive branches before the rename.
Read above articles.
Search to find the page (that I haven't found yet) that describes exactly what will happen in simpler terms based on real experience.
Specifically I'd like to know what happens to shelvesets on the Develop branch after it is renamed to Main. (Next step can answer this.)
You might consider making a "Sandbox" Team Project (or Team Project Collection) then try out your scenario to see if there are major issues.
Pick right timing (see link#1) and go for it.
Check history, do a merge between the renamed branches, check history again.
Allow developers back in.
Good luck, and post back with any new information (including your end results)! -zs
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.