Related
I have a CMS theme installed on my machine. I'm tracking changes to it via git
and decided to back it up on GitHub so I could share those changes.
The theme as provided is also available on GitHub. On my machine I have added
this as a remote upstream. Now I can easily see the changes between my master
and the remote upstream by using the following command:
git diff --color master upstream/number
If I could add the remote upstream on GitHub I could easily share these changes.
Is it possible to set this relationship on GitHub?
I have tried the following:
git push -u origin upstreambranch
which adds an upstreambranch to the master on GitHub. However trying to
compare both branches doesn't work, the result I get on GitHub is that: "There
isn't anything to compare"
Is there an alternative way to compare these?
If the problem is "main and master are entirely different commit histories.", the following will work
git checkout master
git branch main master -f
git checkout main
git push origin main -f
The Short Answer
It looks like GitHub won't let you compare the branches because they don't
actually share any of the same history at all, even though they may share
much of the same files and code.
Here is a screenshot of the temporary fork I made of your repo, where I tried to
compare master with the upstreambranch, like you described. Notice the error
message:
It says:
There isn't anything to compare.
master and upstreambranch are entirely different commit histories.
The Long Answer
You probably downloaded the original source and added it to a completely new
repo instead of cloning the original repo, right? Doing that will make it so
that the history of your repo will be completely different from the
history of the original repo, since your new repo won't have any of the same
commits with the same sha IDs.
You can see that by doing a reverse log of your master branch and the
upstreambranch:
# Your first commit, see commit sha
git log --reverse master
commit c548d7b1b16b0350d7fbdb3ff1cfedcb38051397 # <== HERE
Author: Padraic Stack <padraic.stack#nuim.ie>
Date: Wed Apr 2 15:11:28 2014 +0100
First commit of everything
# First commit sha of the original repo
git log --reverse upstreambranch
commit 105a12817234033c45b4dc7522ff3103f473a862 # <== THERE
Author: Jeremy Boggs <jeremy#clioweb.org>
Date: Mon Feb 22 16:00:53 2010 +0000
Creates repo directories for the Seasons theme.
Solutions
If you redo your commits on top of the original history, you should then be able
to compare the branches. There are several different ways that you can redo your
commits, including
git rebase --onto
and
git cherry-pick
You also can redo each commit manually, if you have to.
I had a similar situation, where my master branch and the develop branch I was trying to merge had different commit histories. None of the above solutions worked for me. What did the trick was:
Starting from master:
git branch new_branch
git checkout new_branch
git merge develop --allow-unrelated-histories
Now in the new_branch, there are all the things from develop and I can easily merge into master, or create a pull request, as they now share the same commit hisotry.
I solve my issue using these commands
git checkout [BRANCH]
git branch master [BRANCH] -f
git checkout master
git push origin master -f
You can force update your master branch as follows:
git checkout upstreambranch
git branch master upstreambranch -f
git checkout master
git push origin master -f
For the ones who have problem to merge into main branch (Which is the new default one in Github) you can use the following:
git checkout master
git branch main master -f
git checkout main
git push origin main -f
The following command will force both branches to have the same history:
git branch [Branch1] [Branch2] -f
From the experiment branch
git rebase master
git push -f origin <experiment-branch>
This creates a common commit history to be able to compare both branches.
This looks like undesirable behavior on github's part, but it's fairly easy to fix. What you want to do is to rebase your branch on a reasonable (any reasonable) commit in the existing history. What you can do is to fetch the github repo and find which tree in its history is most similar to the one you started with. Start this way:
git remote add github u://r/l
git fetch github
myroot=`git rev-list master --max-parents=0`
root_tree=`git rev-parse $myroot^{tree}`
github_base=`git log --pretty=%H\ %T github/master | sed -n "s/$root_tree//p"`
With any luck, that will find you a commit in the github history that has the exact tree you started with. Assuming it does,
git rebase --onto $github_base $myroot master
and you're done.
If that doesn't find a matching tree, you get to find a nearest approximation. Here's one way to get a rough estimate of the differences:
git log --pretty='echo %H $(git diff-tree -p -b -U0 '$myroot:' %T|wc -l)' github/master \
| sh
which will count the lines in a minimized diff between the tree of each commit in the github/master history and your root tree. It seems reasonable to hope for a nice small difference, you could eyeball the actual diffs on it before calling that the github_base commit and doing the rebase above.
Terminology
First, let's get some terminology out of the way...
upstream <= The remote git repo (likely whose master or release branch is in production)
forked-repo <= The remote [experimental git repo] (https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) also known as "origin".
local repo <= The files and directories that you work with on your local workstaion, which you likely got by running a git clone my-forked-repo.git command
local index <= Also known as your local git "stage", i.e., where you stage your files before pushing them to you remote repo.
Github workflow process
Next, let's talk about the process of getting your changes to the upstream repo:
The process is generally to work on a feature branch and then push said branch, and open a Pull Request, either to your forked-repo's master branch or to the upstream's master branch
Create a feature branch by running git checkout -b FEATURE_BRANCH_NAME
Add/delete/modify files project files.
Add files by running git add .
Commit your files to your index by running git commit -m'My commit message'
Push your staged files by running git push origin FEATURE_BRANCH_NAME
Solution for entirely different commit histories
The master and upstreambranch are entirely different commit histories message can occur when you've forked a git repository and have changed your git history.
For example, if you fork a repo and pull your forked repo to work on it locally...
If then you decide to rewrite the entire application and then decide it's a good idea to deleting all existing files, including the forked-repo's .git directory. You add new files and directories to recreate your app and also recreate your .git directory with git init command.
Now, your application works great with your new files and you want to get it merged into the upstream repo. However, when you push your changes you get that "...entirely different commit histories..." error message.
You'll see that your original git commit will be different in your new local directory and if in your remote fork (as well as your upstream). Check this out by running this command in your current directory: git log --reverse master. Then running the following: pushd $(mktemp -d); git clone https://github.com/my-forking-username/my-forked-repo.git; git log --reverse master; popd
You must fix your local .git repo to match your remote my-forked-repo if you want to push your commits and subsequently perform a pull request (in hopes of merging your new updates to the upstream/master branch).
git clone https://github.com/my-forking-username/my-forked-repo.git
cd my-forked-repo
git checkout -b my-new-files-branch-name
# Delete all files and directories except for the .git directory
git add .
git commit -m'Remove old files'
# Copy your new files to this my-forked-repo directory
git add .
git commit -m'Add new files'
git push origin my-new-files-branch-name
Create a PR on GitHub and request to merge your my-new-files-branch-name branch in your my-forked-repo into master.
Note: The "...entirely different commit histories..." error message can also occur in non-forked repos for the same reasons and can be fixed with the same solution above.
A more simple approach where you can't mingle with the master.
Consider i have master and JIRA-1234 branch and when i am trying to merge JIRA-1234 to master i am getting the above issue so please follow below steps:-
From JIRA-1234 cut a branch JIRA-1234-rebase (Its a temp branch and can have any name. I have taken JIRA-1234-rebase to be meaningful.)
git checkout JIRA-1234
git checkout -b JIRA-1234-rebase
The above command will create a new branch JIRA-1234-rebase and will checkout it.
Now we will rebase our master.
git rebase master (This is executed in the same branch JIRA-1234-rebase)
You will see a window showing the commit history from first commit till the last commit on JIRA-1234-rebase. So if we have 98 commits then it will rebase them 1 by 1 and you will see something like 1/98.
Here we just need to pick the commit we want so if you want this commit then don't do anything and just HIT Esc then :q! and HIT ENTER.
There would be some changes in case of conflict and you need to resolve this conflict and then add the files by
git add <FILE_NAME>.
Now do git rebase continue it will take you to rebase 2/98 and similarly you have to go through all the 98 commits and resolve all of them and remeber we need to add the files in each commit.
Finally you can now push these commits and then raise Pull Request by
git push or git push origin JIRA-1234-rebase
This happened for me because I created a repo from GH, but then I also added a README. In doing so I created a commit on my remote.
Then I went and created a new repo locally, made some changes and committed. Then I pushed it to the đrepo and tried to make a Pull Request.
But my remote's initial commit was different from my local's commit, hence this error message. GitHub itself even warns you against this:
Create a new repository on GitHub.com. To avoid errors, do not initialize the new repository with README, license, or gitignore files. You can add these files after your project has been pushed to GitHub.
GitHub Docs
Similarly if you're creating a new repo, GitHub will quietly suggest that you skip initializing the repo. Rather just define the repo.
tldr the very first commit has to be identical, you can't merge 2 commits that don't have an identical initial commit.
If you know from which commit issue started, you can reset your branch to that commit and then merge them.
this is 100% works in any situation :
1)create new folder in your machine
2)clone the remote repository to the new folder
3)delete all files and folders except for the .git folder
4)add your project files that you are working on to this new folder you created
5)open terminal
6)cd new_folder_path (path to the new folder you created)
warning : don't type > git init
7) > git add .
8) > git commit -m "write anything"
9) > git push URL(url of the remote repository)local_branch_name:remote_branch_name
This happened with me yesterday cause I downloaded the code from original repo and try to pushed it on my forked repo, spend so much time on searching for solving "Unable to push error" and pushed it forcefully.
Solution:
Simply Refork the repo by deleting previous one and clone the repo from forked repo to the new folder.
Replace the file with old one in new folder and push it to repo and do a new pull request.
I solved that problem. In my case when i did âgit cloneâ in one directory of my choice without do âgit initâ inside of that repository. Then I moved in to the cloned repository, where already have a â.gitâ (is a git repository i.e. do not need a âgit initâ) and finally I started do my changes or anything.
It probably doesnât solve the problem but shows you how to avoid it.
The command git clone should be a âcdâ command imbued if no submodule exists.
I got this error when initializing a GitHub repository with a README file, and then trying to push my existing local git repository to it. This resulted in a main branch with the README file, which was the Default branch, and a master branch with my code, and they couldn't be merged.
But since I didn't actually have anything important in my main branch (if you need to keep the data from both your branches, check out PaianuVlad23's Answer instead), I managed to solve the problem by changing the Default branch to the master branch, and then delete the main branch, like this:
When in GitHub, click your user icon in the top right of the window.
Choose "Your repositories", and then click your repository name.
Under the repository name, choose the tab "Settings".
From the pane on the left, choose "Branches".
Under the headline "Default", change the default branch from the one you want to delete (in my case main) to the one you want to keep (in my case master).
Now, click the tab "Code" under the repo name.
Under the tab line containing "Code" etc, you'll see a place where it says "2 branches". Click it.
Find the branch you want to delete, and click the trash bin icon on the right on that line.
Now, your repository has only one branch, which is the one you want to push your local changes to! đ Just as if you hadn't initiated your repository before pushing to it, as #mfaani's answer in this thread suggests you do it.
I found that none of the answers provided actually worked for me; what actually worked for me is to do:
git push --set-upstream origin *BRANCHNAME*
After creating a new branch, then it gets tracked properly. (I have Git 2.7.4)
I don't think we have same case here, but still someone else may find it helpful.
When similar error occurred to me, it was going to be the first merge and first commit. There was nothing in on-line repository.
Therefore, there was no code on git-hub, to compare with.
I simply deleted the empty repository and created new one with same name.
And then there was no error.
I got this error message, because I was migrating an application from SVN to GitHub and it's not enough to invoke a git init in the location of the source code checked out from SVN, but you need to invoke a git svn clone in order to have all the commit history.
This way the two source codes on GitHub will have a mutual history and I was able to open pull requests.
I had an issue where I was pushing to my remote repo from a local repo that didn't match up with history of remote. This is what worked for me.
I cloned my repo locally so I knew I was working with fresh copy of repo:
git clone Your_REPO_URL_HERE.git
Switch to the branch you are trying to get into the remote:
git checkout Your_BRANCH_NAME_HERE
Add the remote of the original:
git remote add upstream Your_REMOTE_REPO_URL_HERE.git
Do a git fetch and git pull:
git fetch --all
git pull upstream Your_BRANCH_NAME_HERE
If you have merge conflicts, resolve them with
git mergetool kdiff3
or other merge tool of your choice.
Once conflicts are resolved and saved. Commit and push changes.
Now go to the gitub.com repo of the original and attempt to create a pull request. You should have option to create pull request and not see the "Nothing to compare, branches are entirely different commit histories"
Note: You may need to choose compare across forks for your pull request.
Top guy is probably right that you downloaded instead of cloning the repo at start.
Here is a easy solution without getting too technical.
In a new editor window, clone your repo in another directory.
Make a new branch.
Then copy from your your edited editor window into your new repo by copy paste.
Make sure that all your edits are copied over by looking at your older github branch.
I had mine solved by overriding the branch:
My case: I wanted to override whatever code is in the develop with version_2.
delete the local copy of conflicting branch:
git checkout version_2
git branch -D develop
checkout a fresh branch from the version_2 and force push to git:
git checkout -b `develop`
git push origin `develop`
I didn't need to rebase. But in my case, I didn't need to take code from my old code.
first: pull from remote repo
merge or rebase
finally: push to remote repo
finish
When you are pull/merging feature to main and are in the main branch in the terminal, I successfully used 'git pull origin feature --allow-unrelated-histories'.
Before using this command, I had the same message about completely different commit histories, and I think it's because I accidentally pushed to main after committing to the feature branch. Then I tried some of the solutions offered here like rebase, which allowed me to merge my code, but I still had the compare and pull notifications through git, and it was a one time fix. By one time fix I mean I still got the different commit history message the next time I tried to merge a feature branch's code to main.
Another source from a google search offered the --allow-unrelated-histories fix, and it permanently works exactly how I wanted it to. The branches were merged and now I can merge without error messages and the compare and pull notifications work through git.
I'm sure there are consequences for people who didn't have the same problem as me, but I didn't lose any code and now my repo is clean. Also, I'm also an amateur coder and the question is older so maybe this command wasn't available when the question was asked or I'm not understanding the issue correctly.
I wanted to copy commit history of "master" branch & overwrite the commit history of "main" branch .
The steps are:-
git checkout master
git branch main master -f
git checkout main
git push
To delete master branch:-
a. Locally:-
git checkout main
git branch -d master
b. Globally:-
git push origin --delete master
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
The normal GitHub flow to contribute to a repo is to create a fork of the upstream, clone a local copy where you make changes, then push back up to your fork and then create a PR to have your changes merged into upstream.
But if upstream changes after that, how do you update your fork without creating a merge commit (and also without using the git CLI)?
I already know how to do this in a way that will create a merge commit or which depend on the git command line interface. This question is specifically about using the GitHub.com website or GitHub Desktop application only (no CLI).
Since this is a very common workflow it seems like there should be some simple way to do it using the GitHub GUI.
To reiterate: any answers that use the CLI or create a merge commit (e.g. this way) will not be answering this question since I'm explicitly looking for a non-CLI solution.
without a merge commit or using CLI?
Not directly with GitHub web UI alone, since it would involve rebasing your PR branch on top of upstream/master
So in short: no.
But in less short... maybe, if you really want to try it.
Rebasing through GitHub web UI is actually possible, since Sept. 2016, ...
if you are the maintainer of the original repo, wanting to integrate a PR branch
if none of the replayed commit introduces a conflict
(This differs from GitHub Desktop, which, since June 5th 2019 does support rebasing. But that is a frontend to Git CLI, like other tools provide. For example GitKraken and interactive rebase)
So a convoluted workaround would be:
to fetch, then push upstream/master to the master branch of your own fork (a CLI operation, but more on that below)
change the base branch of your current PR to master (so a PR within the same repository: your own fork), provided you haven't pushed to master.
Meaning: master in your fork represents the updated upstream/master, with upstream being the original repository that you have forked.
Since you are the owner of that repository (your fork), GitHub can then show you if you can rebase said branch to the base branch of the PR (master), but only if there is no conflict.
finally, change the base branch again, to <originalRepo>/master (which is the intended target of your PR)
The very first step is typically done through command line, but... there might be a trick to do it (update upstream master in your fork) through web UI: see "Quick Tip: Sync a Fork with the Original via GitHubâs Web UI" by Bruno Skvorc
In short, it involves:
creating a new branch from your current master (which would be at upstream/master at the time you forked the original repository)
Making a PR with that new branch and <originalRepo/master>
doing a base switch before creating the PR
That is the step which artificially forces upstream/master to be refreshed
You can the create and merge it with the âMerge Pull Requestâ button (and âConfirm Mergeâ afterwards): the merge will be trivial: no merge commit.
The end result is: your own master branch (in your fork) updated with upstream/master (the master branch of the original repository)!
You can then resume the steps I describe above, and change the base of your current PR to your own (now refreshed) master branch, and see if you can rebase it!
This is feasible with GitHub Desktop since version 1.0.7 considering the following:
If the current branch does not have any commits ahead upstream (the original repo of the fork), the new commits can be pulled without creating a new merge commit
In GitHub Desktop:
Clone your repository from File > Clone Repository
Fetch origin, which will automatically fetch the upstream as well
Go to Branches by clicking on where it says Current Branch
Click on Choose a branch to merge into <branch> at the bottom
Search for upstream/<branch>, then click Merge upstream/<branch> into <branch>
Push to origin, et voilĂ !
Otherwise, ff the current branch has commits ahead of the fork, then of course one has to create a merge commit or rebase and force push. For rebasing which might be more preferable, do the following:
In GItHub Desktop, go to Branch from menu, then Rebase Current Branch
Search for upstream/<branch>, then click Start Rebase
Solve any conflicts that have occurred from the rebase
Force push to origin. You will get a warning for this for obvious reasons.
For avoiding force-pushing to your work when your current branch is both ahead and behind its upstream counterpart, either create a new merge commit or:
Make a new branch based with all your changes
If needed, reset the original branch to its original state (before it diverged from the original repo)
Perform the steps from the first scenario and merge your changes into your branch.
And yes, it seems that pulling via the GitHub website from the original repo without creating a pull request and merge commit is not possible at this moment.
Demo GIF for first scenario: https://imgur.com/a/8wci2yf
Some GitHub issues related to this:
Add an upstream to forked repositories
multi-remote support in Desktop
Update
Note: Non-CLI based approach that might help:
Is there a way to make GitHub Desktop rebase a branch against master?
The only key here is doing a rebase, so the above answer should help.
CLI way (which is easier and using git, so it should be more comprehensive by default)
There are some practices that you should use to avoid this.
Don't work on the master branch in your fork.
$ git clone <your fork>
$ git checkout -b feature_branch
You can work in your feature_branch and then raise a Pull Request.
Once your changes are merged in the upstream master, you can pull from upstream to your origin. Since the master on upstream will have your commits sitting neatly on top of it, there won't be a merge commit.
$ git checkout master
$ git pull upstream master
$ git push origin master
In the case, where the maintainer has diverged from the master that you have in your fork, that is, it's not linear any more, you need to pull a fresh copy of it. That should not be a problem as your changes are already in the upstream.
If the master in upstream has moved ahead while you were working on your PR, then you can rebase on you feature_branch.
$ git checkout master
$ git pull upstream master
$ git push origin master
$ git checkout feature_branch
$ git rebase master
Please refer to this document for detailed reference: Fork and pull request workflow
I'm new to GitHub, but I read every possible help section and many StackOverflow posts and I still don't have the answer I'm looking for. (Btw I removed the https:// in front of the links because of lack of rep points, but in the original they are present).
There is the repository I want to sync my files with - github.com/Something/project.git
I forked it. Then I cloned my fork to my computer using Git Bash:
git clone github.com/MY_USERNAME/project.git
I opened the folder:
cd project/
I added as a second remote the repository:
git remote add upstream github.com/Something/project.git
I downloaded its files:
git fetch upstream
Now I have:
git remote -v
origin github.com/MY_USERNAME/project.git (fetch)
origin github.com/MY_USERNAME/project.git (push)
upstream github.com/Something/project.git (fetch)
upstream github.com/Something/project.git (push)
And here comes the problem. Let's say I deleted some files from my computer and from my fork. And the main repository doesn't have new updates meanwhile. I try to download original files again and to update my fork using:
git fetch upstream master
git merge upstream/master
But NOTHING updates. I get only Allready up-to-date all the time!!! I tried many different "ways" including pull. I tried to "change" the branch with checkout, but I don't have any others, so nothing happens again. There is only one branch in the original repository and only one in mine, so it's not the problem. Btw I push my files to the fork without any problem!
So the question is: What does it mean to sync the fork, when it doesn't even download. Is it possible to directly update my fork, without having to update first my local files and then upload to my fork?
It won't update because you already have every commit from upstream in your hostory. If you deleted some files and commited the changes that means you are ahead.
Is there a way to fork from a specific branch on GitHub? ⌠For example, moodle has many branches (1.9, 2.0 ⌠and so on). Can a clone be performed of just branch 1.9 and not the master branch always? Is it possible to clone a specific branch onto my PC?
I donât know a native way yet, but you can do it following this recipe:
Fork the repository in question (called âupstreamâ) on the GitHub website to your workspace there.
Run the GitHub desktop application and clone the repository onto your PC.
Use the GitHub desktop application to open a shell in the repository. (The git commands are not available from the default PowerShell unless you configure that manually.)
Set the source repository as upstream:
git remote add upstream https://github.com/{user}/{source-repo}.git
Fetch the full upstream repository. (Right now, you only have a copy of its master branch.)
git fetch upstream
Make your file system copy the branch you want and give it any name:
git checkout upstream/{branch-in-question}
git checkout -b temporary
Publish your repo using the GitHub desktop application.
On the GitHub website, open your repository and click âsettingsâ.
Change the âDefault branchâ to âtemporaryâ. (Just change the drop-down menu, you donât need to click the âRenameâ button.)
Go back to your repository, go to the âbranchesâ tab, now you can delete the âmasterâ branch.
Delete the master branch on your shell and make a new master branch:
git branch -d master
git branch master
git checkout master
git -d temporary
Once more, publish your repo using the GitHub desktop application.
On the GitHub website, open your repository and click âsettingsâ.
Change the âDefault branchâ back to the (new) âmasterâ branch.
Go back to your repository, go to the âbranchesâ tab, now you can delete the âtemporaryâ branch.
This should be what you were looking for. Perhaps GitHub will provide a more convenient way to do this in future (e.g., clicking âForkâ from a projectâs branch results in exactly this behaviour).
Cloning means that you create a copy of the whole repository in your account including all branches and tags. However you are free to switch and track branches however you like.
No command line needed. Just create a new branch in your forked repository in GitHub. GitHub will ask you if you want to clone/mirror this new branch from the upstream repository. You can give any name to the new branch.
Yes, you can clone the single branch. For example, you have a branch named release1.0. If you would like to clone this branch into your pc then use the following line of code:
$ git clone git#bitbucket.org:git_username/git_repository_example -b release1.0 --single-branch
For those who don't like working with command-line. Here is a simple guide using the desktop client for GitHub:
Click the fork button of the repo on GitHub.com:
Make sure you have the desktop client installed
Click this button:
Clone the repo
In the desktop client, select the desired branch
Select the branch you'd like to work on and you're done
I'm posting here the method I've used.
Like the OP I wanted to only copy/fork one branch. But couldn't find an easy way.
in your repo create a new branch. It doesn't need to have the same name as the branch you want to fork
once created, verify that it is the selected branch, and click "Compare"
reverse the order of comparison (I have a userscript for that, see my profile if it's something you want to test).
the "base" repository must be yours, with the branch you've created
the "head" repository is the original, and the branch is the branch you want to fork
hit "create pull request" and continue until the PR is applied
That's it. You have the branch forked.
I'm using bitbucket but I'm sure this would work for GitHub as well.
Create a new repository
Checkout the branch using GitExtensions
Click Push to open the Push dialog
Set the destination URL to the new repository
Set the destination branch to "master"
Push
Your new repository will have the full history of the one branch only (not all branches like forking will have).
A fast, alternative approach is to create your own new repo.
Go to https://github.com/new and make a new repo. Do not initialize with README.
Scroll down to get your git remote
Then:
git remote rm origin
git config master.remote origin
git config master.merge refs/heads/master
// Run code from above image
git push --set-upstream origin yourbranchname
You will have a new repo with the original repo's code and a branch that can be made into a pull request.
SOLUTION:
For remote repository on GitHub and local repository
After fork all branches to your GitHub repository, you can delete Redundant branches in your GitHub repository.
And then you can only clone the branches you need to local.
Step One
Step Two
Only For local repository
git clone -b <branch name> --single-branch <repository>
If you want to further save your disk space, you can clone remote repository without history:
git clone -b <branch name> --depth 1 <repository>
notice: --depth implies --single-branch unless --no-single-branch is given.
https://git-scm.com/docs/git-clone
Switch to the branch you need in source repo
Click "Fork". You'll get forked master and the branch you're in.
I don't know how it works with more branches, but for my needs worked pretty well.