![]() For lots of commits it would probably be better to do an interactive rebase instead of cherry-pick to achieve the same effect. ![]() Off the top of my head I believe the syntax is git cherry-pick a.b where commit a is exclusive and commit b is inclusive. You can cherry pick with a range of commits to make it easier. Then you can pull upstream and cherry-pick/rebase the commits onto your fork branch. What I would do is add multiple remotes to your local repo, 1 for your fork and 1 for the upstream. I think the best way to handle this is to not use the sync button in github ui. If you're forking for the purpose of actually making a different project then it doesn't really work. At least on github, I think the forking feature is more aimed at people who always want to sync their fork with the upstream so they can make changes and submit pull requests. It's probably a very basic question, but I have not yet stumbled upon a clear answer, so thanks for your help !įorking isn't technically a git thing, it's a feature that the hosting services (github/lab/etc) implement on their own. Should I use another git command (I've heard about rebase, not sure if adapted in that case).Should I just cherry pick the desired commits and ignore the others (but on the given example, I have to cherry pick 45 commits just to ignore 5 commits ?).Is it possible to merge with upstream but excluding some commits of the original repo ?.I want to sync with original repo at the exception of 5 commits. I want to sync with 90% of original repo's commits, but about 10% of the commits don't interest me : what is the best practice in that case ? Say I haven't synced for a week, there have been 50 commits to the original repo. My clone has a dedicated branch for features I implement, and main branch which is just a clone of the upstream. I fork a repo on Github to develop my own features (and clone the fork to my computer, setting its upstream to the original repo). If the default branch is one that you don't wish to keep, go into the settings for that repository in GitHub or whatever Git hosting platform you use and change the default branch before attempting to delete the branch in question.Beginner here, I was wondering what would be the best practice for the following use case : ![]() ! master (deletion of the current branch prohibited)Įrror: failed to push some refs to ' :/.git' I don't think git will let you delete the default remote branch with the syntax provided above ( as someone has tried here): remote: error: refusing to delete the current branch: refs/heads/master Rebase is a good choice when no one except you has. I won't go into much details here, but merge is kinda safer and creates an additional commit that contains merged commits, whereas rebase is good for git log purists since it doesn't create a commit upstream is merged. In a nutshell, it would be advisable to keep the default branch. Yes, it's git merge There's a lot of debate on git rebase vs git merge. Step 2: Run the following command in your terminal to see the current configured remote repository in your fork: git remote -v. The text This will merge 14 commits from upstream/master into. More information on deleting local and remote branches here.ĭo I at least still need the default branch from upstream repository? Following are the steps to Sync your fork with the master: Step 1: Open your command line or terminal in git bash. The text 20 hours ago tells you when the last change was made to the upstream/master branch. In any case, the command to delete a branch on the remote (this does not delete the corresponding branch locally, if it exists) is git push origin :branchToBeDeleted.ĭeleting a local branch (just on your local repo, not the remote fork) can be achieved with git branch -d branchToBeDeleted. The only benefit I can think of is that it may be easier to find a branch of interest if there are fewer branches to sift through. In other words, there will not be a significant improvement for your workflow from deleting these upstream branches. The history of other branches will not even exist locally unless you git fetch the particular branch you want or git fetch -all. When you git clone the forked repository, it will only clone the default branch (unless you specify a branch name, and it will clone that instead). It is most certainly possible, although not really necessary to remove upstream branches from the fork. Is it possible (and even advised) to remove upstream branches from my fork to make things simpler/cleaner for me and my team (i.e., the only branches in our fork are branches we are working on)?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |