I am going to update my Rails3 project to 4 and at the same time have a clean start project all together. So my solution is to create a new rails4 project and just transfer one by one, what I need in my previous project.
I was thinking of creating a new branch for my new rails4 project and eventually when I'm done is transfer it back to master and override it. I have come up with two solutions but I don't know what both implications would be. Which should I implement?
Just create a new branch git checkout -b v2 and do a git rm -rf on the project. Start my new rails app and commit or
Use --orphan? I just recently found this option in git. So I'd use git checkout --orphan v2 do also a git rm -rf on the project and start my new rails app and commit.
Basically they look almost the same but I was wondering like what would happen if I tried to merge them back to master or override master already?
my old project already has a lot of clutter and unused codes and I don't want to do the new one on top of those already. So instead of remove what I don't need, I opted of moving what I need
One solution would simply to manage a different repo, if having the history isn't that important.
Or, if you must keep one repo, go with option 2/ (orphan branch)
If the merge to master with override is what worries you, I have summarized the different ways to achieve that in "git command for making one branch like another".
Related
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/
We have 2 projects, one in rails 2.3.14 and one in rails 3.2.9, we moved the files and changed the structure a bit manually when creating the 3.2.9 repository and now, a few weeks later i want to add all the original repo missing commits to the new repo.
Tried using git format-patch to do it, but since we changed the structure a bit in the new project none of the patches actually applies and returns an error.
Is there a way to do it rather than manually?
try to apply it in the new repo at a revision BEFORE you changed the structure. then merge the new branch into master
Eventually we came to the inevitable conclusion that we have no other option but to merge those changes manually - we exported a patch list from the commits diff and merged the manually one by one, applying the changes in the right places.
Tip for the rest of you: merge frequently if you ever do something like this. applying 533 patches is not a fun thing to do.
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!
We have two separate rails_app, foo/ and bar/ (separate for good reason). They both depend on some models, etc. in a common/ folder, currently parallel to foo and bar.
Our current svn setup uses svn:externals to share common/. This weekend we wanted to try out git. After much research, it appears that the "kosher" way to solve this is using git submodule. We got that working after separating foo,bar,common into separate repositories, but then realized all the strings attached:
Always commit the submodule before committing the parent.
Always push the submodule before pushing the parent.
Make sure that the submodule's HEAD points to a branch before committing to it. (If you're a bash user, I recommend using git-completion to put the current branch name in your prompt.)
Always run 'git submodule update' after switching branches or pulling changes.
All these gotchas complicate things further than add,commit,push. We're looking for simpler ways to share common in git. This guy seems to have success using the git subtree extension, but that deviates from standard gitand still doesn't look that simple.
Is this the best we can do given our project structure? I don't know enough about rails plugins/engines, but that seems like a possible RoR-ish way to share libraries.
Thanks in advance.
I think that the git submodule system have a great advantage over svn:externals or symbolic links (and it is also that makes them more difficult to use): the actual submodule version is stored for each superproject version. So is is quite safe to make changes in the submodule that breaks backward-compatibility: it will be possible to checkout any version of the superproject(s) with the proper submodule version, because the superproject will contain a reference to the proper submodule code. You may also maintain two branches of the submodule (v1.0.x and v2.0.x, for example) and use different branches in different projects without a problem.
So I think it is really worth to use submodules even if they are a bit complicated. Git 1.7 has some major improvements on this area, for example git status now indicates the uncommitted modifications in submodules, so you probably don't forget to commit submodules first. A good GUI may also be a help (I have a small pet project about this, see here).
If you really don't want to care about submodule versions (you never make backward-incompatibile changes in the common code) then I also suggest using symbolic links. Although committing and fetching won't be much easier than for a submodule...
I tend to prefer symbolic links to submodules.
1) Have foo, bar, and the common code (common) in 3 separate repos.
2) In directory for foo, add a symbolic link to common, where necessary.
$ cd foo
$ ln -s /path/to/common lib/common
3) Check in the link.
$ git add lib/common
$ git commit
4) Repeat for bar
This takes advantage of the fact that git respects symbolic links and stores the location of the target (as opposed to following the link.)
Ofcourse, the expectation is for you to consistently use the same target path for common. I work around this by not checking in the symlink, and adding a README.setup file in each of my projects reminding me to add the requisite symlinks upon initialization. Having a devsetup.sh that does this sort of initialization is useful here too.
IMO, this is much nicer to deal with than submodules.
A Plugin is totally the way to go, and if you end up using it on more than two projects or would be useful to the general public, probably worth the effort to make it into making it a gem.
Here is a good resource on the subject
http://nubyonrails.com/articles/the-complete-guide-to-rails-plugins-part-i
and more importantly ...
http://nubyonrails.com/articles/the-complete-guide-to-rails-plugins-part-ii
In the end you will have three git repositories one for foo, one for bar and one for the plugin.
Then in each project to keep it upto data you will be able to do
./script/plugin install --force git://github.com/path/to/plugin/repository
to keep it upto date.
Good luck!
-- jonathan
Git subtree is a part of GIT since 1.7.11 and I wrote an article about sharing code between Rails applications: http://igor-alexandrov.github.com/blog/2013/03/28/using-git-subtree-to-share-code-between-rails-applications
In short: yes git-subtree works and works great!
If you're looking at making a plugin, you should also consider making a gem. They are very similar in terms of using them, but gems tend to be easier to work with, support dependency management, and are easier to share/distribute with the community.
Ryan Bates of Railscast has a great tutorial video about making a gem that you can find here: http://railscasts.com/episodes/135-making-a-gem
You could create a repository with the common code and clone it twice. Both clones would become foo and bar. You could still develop the common code in separate branches in both projects and push that branch to the common code repository. To update the common code in the projects you would just merge the common branch into the master branches of foo and bar.
UPDATE: You can imagine this as a single repository with three branches: common, foo and bar. You would have the common code in the common branch and add the project specific code only to the foo or bar branches. Now you could clone this repository twice as foo and bar and delete one branch from both of them (branch foo from bar repository and branch bar from foo repository). Then you would delete both foo and bar from the first repository. This would become the common repository. The final result would be the same as above.
The best thing you can do is to create a plugin for your common libraries, or even a gem, that way you have a nice way to update/distribute it.
I have a Rails website which has been divided into two separate projects - the public site, and the administration site.
As both sites are using the same database the models are shared between the applications (actually right now they are duplicated). The problem I have here is that when an update to the models occurs in the public project I need to copy the changes over into the admin project.
I've had a look around SO and noticed that there was a question which had answers suggesting using svn:external or git submodule, but I'm not entirely sure how to do this.
Essentially my aim is to be able to make the changes in one place only, commit those changes to git and then be able to pull the changes in the other project when I need to update that as well.
You need to:
commit the submodule in one place
commit the main project (said the public site)
go to the same submodule in the other main project (the admin site)
pulling the latest content (changing the HEAD of that submodule)
going one directory up in the main (admin) project
commit (to record that you now reference a different version of the submodule)
See also true nature of submodules.
Do not use submodules. They are ugly, hard to understand and to maintain. Much better is to use subtrees.
Git subtree is a part of GIT since 1.7.11 and I wrote an article about sharing code between Rails applications: http://igor-alexandrov.github.com/blog/2013/03/28/using-git-subtree-to-share-code-between-rails-applications/
In short: yes git-subtree works and works great!