I am using bitbucket. I create a branch from another branch. But no where i can see this hierarchy as to from where this new branch was created from. Is there a way to make this hierarchy.
use
git merge-base master your-branch
to find the best common ancestor between two branches (usually the branching point).
otherwise you can use this command
git reflog show --no-abbrev your-branch
It will output all changes made to the branch, including it's creation, for example (I created branch xxx from master branch):
Related
I need to merge my master branch code to current branch before building. We don't have access to Git Publisher. I wanted to know what my options are.
I looked into an advanced feature to "Merge before Build" but that seems to merge current branch to master?
Thanks for your help!
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)
I am using git for 1st time. I had created a branch on git, after creating branch I had not work on that branch, I did work in master. now I want that changes in my branch also so how can I pull these changes in my branch.
I am using source tree.
In SourceTree you can easily merge these changes into "your branch":
Make sure to checkout master, e.g. by double-clicking on it in the "BRANCHES" section on the left-hand side.
Select the commit of your branch and press the Merge button in the icon bar. You will be asked if you want to merge that branch into the current branch (which is master).
After doing so your branch should be on the same commit like master.
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!
Can one rebase to integrate changes from one branch to another from within Xcode? I know Xcode supports merge but I couldn't find anything for rebasing.
It does not since it tries to provide an abstraction over the version control system in use. If want a Mac GUI for git you could use gitx or sourcetree
While there isn't a git rebase function, you can still sort of rebase.
Checkout the branch you want to rebase
Click Source Control -> Pull
select the branch you want to rebase onto
check off "rebase local changes onto upstream changes"
This should rebase your current branch onto the target branch. Merge conflicts need to be handled manually (deleting the merge conflict annotations in the code).