Scenario: I'm mostly working with Eclipse to develop plugins. We have our repo that represents our development activities. Now I sometimes need to make some changes to a number of Eclipse or other 3rd party plugins, which are themselves hosted on Git. Then I need to have those modified plugin projects available as part of my codebase.
What I would like to do is to integrate all the remote repositories into a coherent local version where I can pull updates from those other read-only repos, but the changes that we make can be seen in our own repo, just like any other local working directory.
It sounds like you want to use the git subtree command http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
"The command to update the sub-project at a later date becomes:"
git fetch tpope-vim-surround master
git subtree pull --prefix .vim/bundle/tpope-vim-surround tpope-vim-surround master --squash
"When it’s time to contribute back to the upstream project we need to fork the project and add it as another remote:"
git subtree push --prefix=.vim/bundle/tpope-vim-surround/ durdn-vim-surround master
Related
We are using one of the project from Github. We need to check-in code of this project in our TFS.
We need to automate this process. Else everyday we need to download the code and then check-in.
Is there some plugin or some tool to automate this?
If you are using a TFVC repository in TFS then you'll probably want to build some scripts and a process around Git-TF to help automate some of this work.
If you are using a Git repository in TFS then you can create set up two remotes in a local Git repository, i.e
git remote add upstream https://github.com/foo/bar.git
git remote add origin https://tfsserver/DefaultCollection/_git/bar
And then simply do a git pull upstream master followed by a git push origin master assuming that master is the branch that you want to keep in sync.
With either version control system, you probably want to keep a branch in version control in your TFS repository to match what is in your upstream GitHub project so that you can easily see change coming in the one place and then handle your merges inside your local repository.
My buddy gave me his git address for the project we are going to work on. In Eclipse using egit I cloned his branch.
So now in my Git view I have my own repository I created of an existing project. I want this existing project to be on my buddies branch so we can both check it out and have it in our repo.
Unfortunately I am using Windows to do this because we are developing a game and I do all of the art & animation in addition to programming. I would feel much more comfortable on the cmd line than using this plugin..
Any help is much appreciated!
The notion of repo and branch are quite different.
If you have a clone of our buddy's repo, you can work on a branch named like the one your buddy uses (by default 'master' if he hadn't created any other), and everything you will push will be added/merged to the remote branch in the remote repo.
For more on Egit, see this "Git with Eclipse (EGit) - Tutorial", and check if yuo can push at least one file, that your colleague will be able to pull from the remote repo and see directly in his branch.
I'm new to git and am wrapping my head around how I'm supposed to be using git and egit. From the egit tutorial, I have setup a respository on GitHub, pushed my Eclipse projects to the remote GitHub repository from my local workspace, I can push changes to GitHub, switch branches, see the updates on GitHub, etc. This all makes sense.
Looking at the Git Repository explorer, I have a listing of "Local" branches and have no "Remote Tracking" branches and I have no "Remotes" listed. When I create a branch from a local branch, the egit dialog indicates "You are creating a branch based on a local branch" and suggests that I should be making a branch from a remote tracking branch.
So my question is, am I correctly using egit?
Should I just continue pushing changes to the remote GitHub repository? If so, what happens once I share the project and other developers clone the repository and start making changes to the remote repository?
Or should I now ditch the local repository and setup a new remote repository by cloning the existing GitHub repository that I initially created from my workspace?
Or do I create a new Push and Fetch "Remote" for my existing git repository?
Or something else?
Confused.
Since you created the repo on your local system and then pushed it to github without creating a remote you don't have a remote at hand. A remote is simply a short alias for the remote repository's URL. To fix this create a remote and a push and fetch configuration from the repositories view. In order to populate remote tracking branches in your local repo you need to run fetch once. As soon as this is done you can use "Push to upstream" instead of the more complex Team > Push... dialog which allows to define all parameters on the fly. When using native git command line you'll find the same concepts implemented there:
with
"$ git push [url] [refspec]" (e.g. "$ git push https://github/user/myrepo.git master:master")
you pass all parameters explicitly, this is similar to Team > Push... in EGit
with
"$ git push [remote]" (e.g. "$ git push origin")
you push to the repository defined by the configuration parameters of the given remote (check .git/config to see these parameters or open repository configuration from egit preference in Eclipse), this is similar to Team > Push to upstream in EGit. Usually the refspec used in this way is implicitly configured when creating a local branch based on a remote tracking branch. It's also possible to add this configuration later but since this is more
tedious manual configuration the other way is more handy.
If you clone a remote repository the repository you cloned from is stored as remote "origin" in your clone. This way you can skip configuring the remote manually. This is only needed if the repository is born when you create it from scratch.
The "Branching" section of the Egit User Guide can help:
There is no obligation to create a local branch which would be named like a remote tracking branch (see "Having a hard time understanding git-fetch" to have a good understanding of "remote tracing branches).
You can create as many local branches (i.e. branches that you won't necessary push anywhere) as you want/need.
But if you don"t see any remote branch, maybe you didn't fetch that GitHub repo in the first place: see Fetching.
If I fork a project that's hosted on github. Do I fork all the branches? How do I know which branch my fork is based on? In other words which branch will be downloaded to my PC?
Think of it this way:
The repo[sitory] corresponds to the collaborated work of the team across one or many branches. All contributors have their own copy of it.
Each fork of the main repo corresponds to a contributor's work. A fork is really a Github (not Git) construct to store a clone of the repo in your user account. As a clone, it will contain all the branches in the main repo at the time you made the fork.
Each branch within the fork and/or in the main repo can correspond to several kinds of things, depending on how you want to work. Each branch could refer to a version of the project but can also correspond to different channels of development, like hotfixes or experimental work.
The pull request (in the GitHub ecosystem) corresponds to the task. Every time I want to contribute an isolated finished task to the main repo, I create a pull request corresponding to the commits made in that task. These commits are pulled from either my fork or my branch to the main repo.
A commit is a set of changes to the code. This is one of the most interesting things about Git. You don't transfer files, you transfer logs of changes.
All branches on GitHub will be copied in a fork. (Obviously, this doesn’t include branches that were never pushed to GitHub in the first place.)
But a fork is a GitHub-to-GitHub operation; nothing is copied to your PC. It’s not quite the same as a Git clone. If you mean to ask “what’s copied when I clone a project?”, see the manual for git-clone(1).
Fork is a clone on the GitHub side (it clones everything).
When you are cloning a repo, you are getting the all history of said repo, with all its branches.
Even though you can in theory change the default branch of a remote repo, a clone from a GitHub repo mainly look for the master branch. Meaning to change the "default" branch a GitHub clone will get, you need to rename the master branch.
If you fork a project, you are making a copy of the whole project to your git hub account. you are not coping anything to your PC
To make a copy in your PC you have to clone it and pull all the stuff and you will got all branches & code of that project
This can be explained very well. You have a central repository at GitHub. Whenever you take a clone of it on your personal computer to do some changes, this local clone of the main repository is called a fork.
The branch is something different and is included in the fork/repo. Actually the branch is your work at different stage of development. They are created as and when required to save a set of functionalities, to give access to different users, to demonstrate the site to client, etc.
If you create a fork of a project from the Github website, you get all the branches from the upstream project.
If you clone from your newly minted fork to your local PC, you will have the origin remote on your PC pointing to the master branch of your fork on Github.
I would like to share a real life example of when we use Branches and when we use Forks
We have GitLab at our shop and sometimes we have to work on packages from a Laravel project. We normally create a branch and push changes to the branch that we have been testing in our local VM dev environment when working with the actual Laravel project.
Let's say our project is located at
https://github.com/yardpenalty/mainproject.git
Branch usage:
Lets say the branch is called It_doesnt_matter
Once we have our branch the way we want for production we then make our final push to this branch and create a merge request which then goes into UAT for testing.Once the test has went through QC the changes are merged into production.
The merge from the It_doesnt_matter branch is now pushed to the master project
at https://github.com/yardpenalty/mainproject.git
Let's say the package project is located at
https://github.com/yardpenalty/mypackage.git
Keep in mind the mainproject uses this package in production so we can't make changes by simply pushing them to this package (among other reasons). Let's say a web dev has to edit this package to make changes on production.
A simple branch wont work either because we can't see our changes without publishing the package etc.
Fork Usage:
Now is when we have to do a little bit of trickery with our package so we create a clone of the production package via a fork. The composer.json files can be updated to point to the fork which is now located at a User or Group path
So we will create a fork in https://github.com/yardpenalty/mypackage.git
and call it https://github.com/yardpenalty/yards/mypackage.git
Now we can update our composer.json file to point to this package in our "repositories":[ array like such such and away we go!
{
"type": "github",
"url": "https://github.com/yardpenalty/yard/mypackage.git"
}
]
I have read :
"Best practices for using git with CVS"
"How to export revision history from mercurial or git to cvs?"
, and neither suit my needs.
At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.
However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:
Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.
My plan is something along the following lines:
Copy the checked out files to another folder [gitRepo].
Create a master git repo in gitRepo
Branch in gitRepo and make changes.
Commit to gitRepo
Copy gitRepo back to checked out files
Sync with remote cvs.
I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.
Are there any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.
The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.
It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.
~Thanks for reading.
You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.
Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.
The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.
I have done exactly this at work and I found the following practices helpful:
Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.
When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!
You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.
Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.