Is it possible to reference a 2nd Git repository to utilize files from it if I'm using a different project within Katalon studio, which was created from a separate Git repo?
I have 2 Git repos, one with my web UI test cases and another with the Object Repositories (I kept them separate so test cases from different projects could all reference the same object repo). Is it possible within Katalon Studio, when I have my test cases project open, to somehow reference the object repo from the separate Git repo? I'm just trying to avoid having to duplicate the objects within each project which may use an object on a particular page.
It will be a complicated setup
1 - Items in Test cases and Object repository are not saved in a single folder, but many folder instead. The relationship between them has an ID, so saving them separately easily break the reference.
2 - In git, you have to specify as main git and sub module. http://www.vogella.com/tutorials/GitSubmodules/article.html
Related
how is it possible to commit all selected projects from Eclipse to one github repository(as imaged below)?
Currently when I commit my new project to github, a new repository will be created.And I'd like to avoid creating massive number of new repositories.
Thank you in advance!
p.s.I found other related topics for this question, but don't know what I should do exactly.
need your help please.
There shall be an Eclipse plugin that'll do your git job but I'll tell you a generic solution in case that plugin is not helpful. Well, all these selected projects are directories basically and if they're residing inside the same directory, let say <dir-1>, then you can add the remote repo path to <dir-1> using git remote add origin <git-path> and then add all your directories i.e. projects which will be part of the git repo. Best case would be to create separate branches for each of these projects and then merge those branches to master when they reach a logical state without any breaking changes. Now, in case, if all these directories are not residing inside <dir-1> then create a symbolic link inside <dir-1> to all those projects (possibly with same names) so that whenever the original directories are updated these directories are also changed respectively. Check more about symbolic links.
I am using CVS and I have this hierarchy:
/ROOT
/JAVA
/JavaProject1
/JavaProject2
.project
/PHP
/PHPProject1
/PHPProject2
.project
In Eclipse > CVS Repository Exploring, I can see this hierarchy and I can Check Out only the project that I want.
Also I can check out (import) JAVA and PHP folders (I created them as Eclipse General project for import) to Eclipse Package Explorer and can synchronize and commit all together.
When I want to use Git, it only supports one project.
I don't want a flat hierarchy (near all JAVA and PHP project together), I want to use tree hierarchy and I want to check out only the project that I want as with CVS.
Is my CVS hierarchy possible in Git or what technique should I use?
I think you're mixing what you want to do locally with how you want
to arrange things remotely. All git commands access only the local
repository. The 'push' and 'fetch' commands appear to access a remote
repository, but in fact they effectively start each other on the remote
machine running against the local repository on that machine. So the
tasks you can do remotely are very limited. Specifically, copying "branch"
and "tag" references and the commit histories those references point at.
This means for the simple case there is ONLY the local repository,
it exists in the .git directory in the working directory.
You can arrange working directories, with their .git directories however
you wish on your local machine. Likewise, you can arrange the the remote
repositories in any way allowed by the remote hosting service. The
layouts do not have to match. If the remote is your own Linux server you
can make the layout just like your local. If the remote is (for example)
Github you're more limited.
You'll need to backup the .git directory to backup
the repository; the rest of the working directory is probably not significant. You can use git push to do this backup, as long as you never use '--force'.
Git isn't really very keen on you having multiple working directories
for one repository. It is possible, however, in the simple case they
will each have their own copy of the repository and you will need to
push/pull the updates individually either to a "central" repository
or more "randomly". None of these repositories have to be physically
"remote".
Git much prefers you to switch between branches in one working directory
and use make install style processes to send builds out.
It is also possible to have unrelated branches in one repository, but most people find this too confusing as you still only have one working directory.
I'm using built-in git of Xcode.
I think my project directory is just a working copy of repository.
How can I know where repository is stored?
And when I copied a project directory, a new different repository is automatically created for new project directory instead of sharing the repository of old project directory.
That is convenient but why that happend?
Git stores the repository in the top-most .git folder of your working directory. So, if your code is in /Users/js/Code/MyProject, then the repository is in /Users/js/Code/MyProject/.git/.
Git encourages every repository to contain a single "project". Although it's possible to store unrelated branches that don't share any history in a single repository, that is very nonstandard and might be confusing to other people.
It's also possible, but discouraged, to store unrelated projects as subdirectories within a single working directory. This would make it difficult to see the history of each individual project, since you'd have to inspect each individual commit to figure out which project it affected, and merges would be downright painful.
We have a Hg repository set up for the root of our webserver. There are a number of projects which have their own directories and there is a common C directory for components.
In CFBuilder, I have a project set up for each of them and I'm using linked folders to make it easier to access the components.
CFBuilder and the plugin correctly show that both are under version control, and update properly when changes are made -- but when select that I want to commit from the Project > Team > Commit, none of the changes from the C directory are shown in the changes which will be committed.
Is it possible to have it work this way, or is there a preferred way to work with linked folders?
You need to set up a separate project for the Components, and do your commits from there. Changes made in your linked folders should be reflected in the C project, but if the C project is part of a different repository (which it would seem is the case, given your linked folders), you'll need to commit from that project.
I've got a project in a git repository that uses some custom (and so far unversioned) setup scripts for the build environment etc. I'd like to put these under version control (hopefully git) but keep them versioned separate from the project itself, while still living in the base directory of the project - I've considered options like local branches but these seem to have the problem that switch back to master (or any other "real" branch) will throw away the working copies of the setup scripts.
I'm on Windows using msysgit so I've got a few tools to play with; does anyone have a recommendation or solution?
If you really need them separate from your main git repo while still living directly within it, you could try:
creating a new repo with those script within it
and:
adding that new repo as a submodule to your repo. Except:
a/ those scripts won't live directly in the base directory, but in a subfolder representing the submodule
b/ you need of course to not publish (push) that new repo, in order for other cloning your main repo to not get those setup files
or:
merging that new repo into your main repo (with the subtree project), but:
you need to split back your project to get rid of those files
for a project with a large history, and with frequent push, that step (the split) can be long and cumbersome.
I would consider a simpler solution, involving some evolution to your current setup files:
a private repo (as in "not pushed") with those setup files
environment variables with the path of your main git repo in order for your setup files (which would not be directly within the base directory of said main repo) to do their job in the right directory (like beginning for instance with a 'cd right_main_git_repo_dir').
I want to share an additional solution and some samples from which to start.
I've has a similar problem in attempting to build Mozilla Firefox with Buildbot -- I need to have some files in the root folder (namely the .mozconfig file and some helper scripts) and I wanted to version them separately.
My solution is as follow:
checkout the Firefox code from the Mercurial repository;
checkout an additional repository with the additional file I need;
before starting the build, I copy these file to the folder with the Firefox code.
This approach is implemented in the following repositories:
buildconfig-mozilla-central: it contains the Buildbot configuration, which
pulls both repositories
copies the files from the scripts repository
and start the build;
buildscripts-mozilla-central: the repository with the build configuration and helper scripts.
Please note that the code might not be well factored (for example the paths) but it should be a good starting point.
This procedure is tailored for Firefox, but it can be applied to any repository.