Right now I stay on branch 4.8.2_343
I don't want to merge into default branch but I want to replace default content with 4.8.2_343.
How can I achieve that?
this link may help you Link
Question:
I have two branches, email and staging. staging is the latest one and
I no more need the old changes in email branch, yet I don't want to
delete them.
So I just want to dump all the contents of staging into email so that
they both point to the same commit. Is that possible?
Answer:
You can use the 'ours' merge strategy:
$ git checkout staging
$ git merge -s ours email # Merge branches, but use our branch head
hth, Martin
Related
I have the following branches :
I wish to make my client-rework branch the master branch. I dont want to merge it, I want to entirely replace the master branch with the newest i created. I also dont want the master branch remove, ideally it would be renamed to something like master-old or something. Is this possible or am i asking something dumb here.
you can set your client-rework to be the default branch in setting, tab branches. like in my case below, i set develop as the default branch
First thing master branch is by default protected. You have to remove that from settings, it depends which git flavor you are using. and you should not delete because that is how industry practices work. you may try git checkout master or some other branch
Assuming you are using Github you have to change the default branch first.
After that you need to rename the local client-rework branch to master:
$ git branch -m master master-old
$ git branch -m client-rework master
Now push the branches to origin remote:
$ git push origin HEAD
I have created a Template Repository in GitHub and then created some repositories based on the template. Since they were created, there have been updates to the template that I want to pull into those repositories.
Is this possible?
On the other repositories you have to add this template repository as a remote.
git remote add template [URL of the template repo]
Then run git fetch to update the changes
git fetch --all
Then is possible to merge another branch from the new remote to your current one.
git merge template/[branch to merge] --allow-unrelated-histories
https://help.github.com/en/articles/adding-a-remote
I will link to the same location as HRK44 but my answer is very different.
https://help.github.com/en/articles/creating-a-repository-from-a-template
Although forks and templates are mentioned in the same section, they are very different.
One of the differences mentioned in the link is:
A new fork includes the entire commit history of the parent repository, while a repository created from a template starts with a single commit.
This basicly means that you will not be able to pull new changes from the template as your git histories are very different and are not based on the same thing.
If you do use the method mentioned in the accepted answer, you will have very hard manual merges that will result in changes to all of the files received from the template, even if they werent changed since the first time you created that repo from that template.
In short, creating a repo from a template (using only master branch) is the same process as:
git clone template
cd folder
rm -rf .git
git init
git remote add origin <new repo url>
git add .
git commit -m "Initial Commit"
git push -u origin master
A few other things that are not (surprisingly) copied when creating a repo from a template:
(Unless github fix this at a later point)
Repo configurations (allowed merge types, permissions etc)
branch rules
So when using this at your organization, make sure to set all repo configurations on the newly created repo.
If you want to merge changes from a template into your project, you're going to need to fetch all of the missing commits from the template, and apply them to your own repo.
To do this, you're going to need to know the exact commit ID that you templated from, and you're going to need to know the commit ID of your first commit.
ORIGINAL_COMMIT_ID=<commit id from original repo you templated from>
YOUR_FIRST_COMMIT=<first commit id in your repo>
YOUR_BRANCH=master
Next you're going to need add the template as a remote, and fetch it.
git remote add upstream git#github.com:whatever/foo.git
git fetch upstream
And finally, you need to rebase all of the commits you're missing onto your branch
git rebase --onto ORIGINAL_COMMIT_ID YOUR_FIRST_COMMIT YOUR_BRANCH
What this is doing it basically creating a branch off of ORIGINAL_COMMIT_ID, then manually applying all of the commits on your original branch, onto this new branch.
This leaves you with what you would have had, if you had forked.
From here, you can git merge upstream/master just as if you had forked.
Once you've completed your merge, you'll need to use git push --force to push all of the changes up to the remote. If you're working with a team, you'll need to coordinate with everyone when doing this, as you're changing the history of the repo.
Note: It's important to note that this is only going to apply to one branch. If you have multiple feature branches, you'll need to perform the same steps to each one.
#daniel's answer also did not work for me because of the unrelated histories problem mentioned in #dima's answer. I achieved the desired functionality by doing the following:
Copy the URL for the template repository you wish to use to create a new repository. (ex: https://github.com/<username>/my-template.git)
Use GitHub Importer to make a new repository based on the template repository.
This solves the unrelated histories problem because it preserves the entire commit history of the template repository.
You need to use the Importer because you cannot fork your own repository. If you want to use someone else's template repository, you can just fork theirs.
Then, add the template repository as a remote.
git remote add template https://github.com/<username>/my-template.git
After you make new commits to the template repository, you can fetch those changes.
git fetch template
Then, merge or rebase. I recommend to merge on public repos and rebase on private repos.
To merge
git checkout <branch-to-merge-to>
git merge template/<branch-to-merge>
To rebase
git checkout <branch-to-merge-to>
git rebase upstream/<branch-to-merge>
NOTE: When rebasing, you must
git push origin <branch-name> --force
in order to override your old commits on your remote branch. This is why I recommend to rebase only on private repos.
I approached this differently as fetch & merge was not ideal as lot of files diverge across template and downstream projects. I only needed the common elements to sync.
lets says we have the below folder structure locally:
repos
├── template_repo
└── downstream_repo
1. Now create a git patch from the parent folder (repos):
git diff --no-index --diff-filter=d --output=upstream_changes.patch -- downstream_repo/some_common_path template_repo/some_common_path
NOTE - the order of the paths matters!, downstream_repo comes first! (interpret this as "what are the changes we need to make to downstream_repo to make it same as template_repo"; look at the --name-status output, it will hopefully make sense.)
--no-index option generates git diff based on filesystem paths. Path can be a single file or a folder.
--diff-filter=d will ignore any files that are in the downstream_repo but not in the template_repo. This only applies when diffing folder paths.
You can use --stat, --name-status to see what the patch will contain.
Review the generated patch.
2. Change to downstream_repo folder and apply the patch
git apply -p2 ../upstream_changes.patch
explanation for -p<n> option from the official doc:
Remove leading path components (separated by slashes) from
traditional diff paths. E.g., with -p2, a patch against a/dir/file
will be applied directly to file. The default is 1.
Using -p2 will drop a/downstream_repo and b/template_repo from the diff paths allowing the patch to apply.
This is the reason for starting with above illustrated folder structure.
Once the patch is applied, rest of the process should be familiar.
All of these options are clearly explained in git diff and git apply official docs.
Another option is to create a patch from the necessary commits and move the patch to a new project
git format-patch -1 HEAD
Insert a patch
git am < file.patch
details are here
I ran into this same issue. I have 10+ projects all created from the same template project (react-kindling) and using git alone wasn't sufficient, as it would pull in changes to the template that I didn't want in my child projects.
I ended up creating an npm utility for updating child projects from template starter projects. You can check it out here:
LockBlocks
It's been a real life saver. Pulling changes from the template is a heck of a lot easier now.
This works too:
git remote add template git#github.com:org/template-repo.git
git fetch --all
git merge template/main --allow-unrelated-histories
I have a repository in Github with two branches, master and dd. I gave the name dd by mistake and I want to change this name to something else from the Github GUI.
I didn't find a way to do so in the branch webpage:
https://github.com/user/repo/tree/dd
nor in the branches option page (I do have an option to change what will be the default branch):
https://github.com/user/repo/settings/branches
How could a branch name be changed in Github?
I work with the command line but yet to have learn Git in a serious way.
Don't know exactly how to solve it in GitHub, but locally you just can:
(Assuming that same repo is locally cloned)
Rename locally:
repo (master)$ git branch -m dd new-name
Delete remote branch:
repo (master)$ git push origin :dd
Push all branches again (including the renamed one):
repo (master)$ git push --all
git branch -m old-name new-name
look at this link for more details:
https://multiplestates.wordpress.com/2015/02/05/rename-a-local-and-remote-branch-in-git/
You could create a new branch from dd via the Branches dropdown:
And then delete the old dd branch afterwards from the Branches page:
What I did in the end was this:
First, I duplicated all the data from the wrongly named nonmaster branch to a new, rightly named nonmaster branch, and committed. I double checked that data was committed successfully and indeed there.
Second, after making sure the data was backed up, I navigated to:
https://github.com/user/repo/branches
I then used the bin icon near the name of the relevant branch and did the rest of the short deleting process from there.
I am new to managing code revisions and need guidance on how to merge to code sets. I have a MASTER branch with my latest UI and I have a branch called "Feature-A" with lots of Django additions + template additions to the previous UI files.
Since I am new to Github, I want to take the safest approach incase I need to revert mistakes. Should I make a new brach of master and merge Feature-A into that branch or should I merge Feature-A directly into the MASTER?
Since you're new, I would say the best approach would be to create another branch (clone of master branch) and then merge feature A into that, and see if it works. If not, keep testing feature A to make it compatible. If it works, great! Just remove that extra branch and merge feature A into the master.
I.e.,
git checkout master
Then, create a new branch (git checkout -b 'featuretest')
Now, git branch shows
* master
* featureA
* featuretest
Then, do git checkout featuretest, and git merge featureA to merge it.
If the feature works, great! Remove the branch (git checkout master; git branch -d featuretest)
and do it for real (git merge featureA)
If the feature doesn't work, go back to the feature branch (git checkout feature) and keep testing.
I made two changes on a project in GitHub (two commits). How can I create two different pull requests from my changes?
I only found a way to create one big pull request that includes all my changes: https://github.com/tcatm/ffmap-d3/pull/22
You can easily solve this with the SmartGit/hg GUI:
open the log of the master branch
right-click on the first revision from the time, you forked the main project and create a new branch from there
switch into that branch in the left bottom corner with right-click
cherry-pick the revisions you want to make a separate pull request and commit them as one commit
push your new branch up on GitHub
there you can create a pull request from just that branch
for the second pull request, you create a new branch and do the same with it
Here are some screenshots taken from the Mac OSX version of the GitHub desktop program.
Here I am making the first commit, but you can see both changes have been made prior to the commit:
Here I am making the second commit:
Here you can see that each commit was accepted individually:
Note: Some names have been blanked out for privacy.
Assuming that the Windows version of GitHub has the same options, I would download the desktop program and try that.
Create a new branch:
git checkout master
git checkout -b mybranch
... make changes ...
git add myfile
git commit
git push -u origin mybranch
Then create a pull request and change the last compare button on github to mybranch