I was looking into what options there were for pointing bundler/Gemfile to local forks of repos and came across "Local Git Repositories" on the bundler.io site but it appears since you have to specify a branch, if you're working off a specific feature branch such as ticket###-some-task then you would have to go into the Gemfile and update the branch: parameter to point to that instead otherwise bundler will complain that a different branch is checked out.
Is there a simpler way to point at a feature branch if you're working on 2 or more projects at the same time? Here's an example:
# project-1 Gemfile
gem 'project-2', git: 'git#local.repo.com:org/project-2', branch: 'master'
# project-2 is checked out to a branch called 'new-changes'
I then run: bundle config local.project-2 /path/to/project-2
Do I have to go into project-1 Gemfile and change the branch to new-changes every time I encounter something like this? Then when I'm done with the code change in project-2 and it's been merged into master, I would have to remember to go back into the Gemfile and change new-changes back to master?
It seems like you could run into the issue where developers would forget to change the branch back to master in the project-1 Gemfile?
Related
I finished an Xcode project and pushed it to github from Xcode 'Source Control' Menu. Then I changed the project name CountryBook to Countries. I Built project and ran. Everything was okay. Then I coiped project folder to desktop as a backup. Then pushed project again. Everything has messed up. Some old named folders and files still exist in repo. Then I deleted every directory and file from github repository. Now, backup version of project is working. But when I try to push it to repo, old files are still exist. I deleted 'origin' from 'Remotes' and created a new repo named 'Countries'. I pushed project again but it was same. A mixed version of old files and new files. When I clone the github version of project, of course it is not runnable. What sould I do and how can I push clean version of my project? I don't want to lose project.
This is Countries repo now:
This is my working project folder with correct content:
I would fix it via command line, lets assume you start from scratch:
Step 1 - prepare the working branch:
Clone the project
Navigate to root folder of the project
Checkout the main branch ("main", "master", or whatever it is)
Create a new branch you will be working with
git clone https://github.com/yourorg/yourrepo
cd yourrepo
git checkout main # or master
git checkout -b fixprojectstructure # branch name can be anything
Step 2 - clean project locally
Delete old project, old workspace, ensure the names in Podfile and Podfile.lock are fine
Build the project and ensure it's working
Step 3 - commit your changes:
# assuming you are in the root of the project
git add .
git commit -m "Some explanation"
Step 4 - push your changes:
I usually do it the lazy way: just run git push, which will show you the proper syntax to push remotely, something like
> git push
fatal: The current branch fixprojectstructure has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin fixprojectstructure
> git push --set-upstream origin fixprojectstructure
Enumerating objects: ...
...
remote: Create a pull request for 'fixprojectstructure' on GitHub by visiting:
remote: https://github.com/.../pull/new/fixprojectstructure
remote:
...
Branch 'fixprojectstructure' set up to track remote branch 'fixprojectstructure' from 'origin'.
Step 5 - merge your changes:
Basically just do what the line above is saying:
Navigate to https://github.com/.../pull/new/fixprojectstructure
Create pull request
Merge pull request to main (or whatever the initial branch was)
Note on the side: configure the gitignore file properly for your repo as well. For starters, follow the gitignore template to create a proper gitignore file, and then change it the way you need to.
For instance:
Usually, if you use cocoapods, you do not store .workspace folder and its contents in the repo. Instead it's generated using pod install command on each machine that needs it.
It's also common to exclude Pods directory from storing in the repo, although there are pro / cons arguments both ways.
I always use composer packages in Laravel but I never changed one. This is my first time and I don't want to do it incorrect.
I need to use and change a packages foo/bar. Everything that follows now is just guessed:
I forked the repo
I created a develop branch
I added a vcs to my composer.json
"require": {
//...
"foo/bar": "dev-develop",
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/thisisme/bar"
}
],
composer update
Now I have the thisisme/bar fork in my vendor folder in foo.
So far so good. Now I can use my own fork.
But currently, as I don't know what is good practice to modify the repo, I cloned the repo to a completely different location. Then I push my changes there and run composer update in my project to get the changes. But this is a pain.
Do I need to have a sub git in my project in vendor/foo with
git remote add origin https://github.com/thisisme/bar.git. Because "git in git" feels wrong and finally is not really working as git commands seem to interact with the "parent git".
While VonCs answer is correct regarding git, I'm not certainly sure that git submodule support is well aligned with composer(1) vendor dir for packages from a VCS repository. At least I have not experimented much with it and when I use a composer configuration with a VCS git repository, I normally don't need that1.
While composer(1) has support for git for vendor packages, it is on repository level, that is, you can have your own repository for your package (as you have configured it shown in your question) and then composer takes care of updating (or giving a warnings about local changes).
composer(1) supports this with its own remote for the packages (non-bare) clone (in the source install, read on).
So yes, what you describe ("But this is a pain."), is as long as you don't use it to your benefit. While you develop your (cloned) package, you don't need to run composer update all the time.
.git
composer.json
vendor/foo/bar/.git
A Composer project with two Git repositories
This is why IMHO "git in git" must not feel wrong. Similar to git sub-modules, git supports this very well. By default it even keeps track in the parent project of the current revision (changes) of the sub-project but without having the information of the remote - as it is local (gitlink).
You won't see this thought as within the tree, the gitlink would be at vendor/foo/bar and commonly (& given that) vendor is git ignored, no version tracking in the main project for vendor/foo/bar/.git - but there in the sub-project.
This is not a problem as Composer manages that git sub-project for you (the initial clone and further checkouts) in terms of your main project.
And git realizes it is a different project.
You should be able to cd into the package directory within the vendor folder (vendor/foo/bar) and configure your remote(s) there. You can then work within that project and git(1) will work there and not within the parent repository.
To have this work with composer(1) it is important that you configure composer to prefer the source install variant for that repository. This is the preferred-install option and you can configure it for your repository specifically.
{
"config": {
"preferred-install": {
"foo/bar": "source"
}
}
}
From the wording in your question, I assume that you have not yet configured it.
And this is somewhat important as only with the source install, there will be a (non-bare) git clone in vendor/foo/bar and therefore the git checkout with the overall git configuration within the packages folder in the vendor directory (as you have Github configured as the repository source and composer optimizes to take the dist version by default IIRC).
After you changed your configuration to the source install and updated it, cd into vendor/foo/bar and then run git remote -v. It now should show you the "composer" remote(s) for that package.
As you use the develop branch, you can add changes locally but mind the gap that you would also need to push them to the remote repository (Github) before you use composer again to update (at least) that foo/bar package - as while you use git for the development of the foo/bar package now, in your main project you use composer to manage the dependency.
This is the price you have on the payroll using Github instead of a configuration that is more near to the place of work, but at least locally, you can handle the package with "git in git".
This is normally straight forward. One overall price remains thought, due to managing two instead of one repository but that you can't prevent with this kind of composer project [composer only versioned vendor folder]).
Note: If development takes longer than a few hours, it may also make sense to include the new Git sub-project in the backup routine of your parenting project, so that when you remove the folder vendor/foo/bar you have a backup of the (local) Git repository and working tree in it. However, this depends on the project configuration and is your own responsibility.
A bit of a workflow with some hints is also outlined in the composer documentation in Loading a package from a VCS repository.
1 There is a type of setup for a composer project where vendor itself is under git version control, with that git sub-modules can work (very well), but this is most likely not the kind of setup you have for your project, so I skip it for this answer.
If you're working with sail or docker-compose and linking the foo/bar project in the vendor dir is only a temporary until 'it works' solution you could just add it as a volume link. This is what I usually do.
Eg: I'm working on my-project in ~/projects/my-project, I clone the foo/bar repo to ~/projects/bar
Then in the docker-compose.yml I can add the volume:
volumes:
- .:/var/www/html
- ../bar:/var/www/html/vendor/foo/bar
Again, this has a huge assumption on docker being used, but I like to think that everybody is using it these days.
Do I need to have a sub git in my project in vendor/foo with git remote add origin https://github.com/thisisme/bar.git.
That could be achieved with a submodule which allows for your parent Git repository to only store a reference to another repository.
You would use git submodule add for that.
A git clone --recurse-submodule would therefore clone your project with the submodule Git repository in it cloned as well, and checked out to the exact reference you previously committed.
I want to set an opensource project where users can be sure that the deployed version .heroku.com corresponds with the actual source code in github master branch github.com/
Is there any way to prove a heroku deployment corresponds to a github repo?
Your app can spit out the latest deployed Git SHA if it has the "Dyno Metadata" feature turned on: https://devcenter.heroku.com/articles/dyno-metadata
Using that, you can show the latest SHA and compare it against the public repo.
Also, to add to what Jon said, you can do this via the heroku releases command. Every release, be it a code deployment, config var is 'tagged' - the command will show you everything that has changed on your app and a deploy will show the short git SHA, you can copy the SHA and then use the git command to search the repo for it.
eg.
assuming heroku releases returns
v10 Deploy 33f21247 foo#bah.com 2018/09/03 10:01:38 +0100
then you could do:
git cat-file commit 33f21247
which will then output the corresponding match, or a message saying it's not found. Obviously, this assumes your local repo is in sync with GitHub. To check it against GitHub you'd need to open your repo on GitHub like:
https://github.com/heroku/{projectname}/commit/{sha}
which will show the same commit on GitHub.
Trying to move to the officially supported Golang vendoring solution from legacy Godeps workflow.
Scenario:
Repo A===
\
========> Repo C (shared library code)
/
Repo B===
What is the best workflow I can choose for a mid-size (roughly 5-10 member) team of engineers to vendor Repo C for both Repo A and Repo B? Engineers of varying abilities, most of which probably shouldn't need to know the details of this at all?
I'm currently using govendor for this. I'd prefer not to switch but would if there is a tool that provides a better workflow.
This needs to integrate with a CI server running the builds. I can think of 3 scenarios:
Vendor Repo C into A & B:
Pros:
Reproducible Builds
Easy integration with CI
Cons:
Manual and Error Prone - Can easily vendor incorrect code
Engineers need decent knowledge of vendor tool and methodology
Symlink Repo C trunk branch into vendor folders of A & B:
Pros:
Engineers need no knowledge of vendor tool
Low Developer Maintenance
Cons:
Builds not (easily) reproducible
Possibility of including code in build that shouldn't be released
Less Flexible (Repo A and Repo B can't have differing versions of C)
Include Repo C as a git submodule or subtree in Repo A and Repo B (either utilizing vendor or not):
Pros:
Engineers need no knowledge of vendor tool
Easy Setup
Less Maintenance
Reproducible Builds
Cons:
Having to use git submodule or subtree
Finding surprisingly little about this question on the internet. Is there some idiomatic way of doing this? I'm sure there are other ways of doing this; what am I missing?
i suggest to use a manifest based approach with version constraint.
Project A == Manifest
|- Repo A#~1.0.1
|- Repo B#~1.0.1
Repo A == Manifest
|- Repo C#~1.0.1
Repo B == Manifest
|- Repo C#~1.0.5
Repo C == Manifest empty
Which will resolve into
Project A == Resolved Manifest
|- Repo A#1.0.1
|- Repo B#1.0.1
|- Repo C#1.0.5
where ~1.0.1 means >=1.0.1 <1.1.0.
As you see B and A dependency to C are independent, yet within project they are resolved correctly.
In the event A and B would define incompatible dependency to C, an error should occur as the project should not be build-able.
You may prefer to use caret ^ rather than tilde ~, ^1.0.1 -> >=1.0.1 < 2.0.0.
Note that you are not forced to use those 'helpers' such tilde and caret, you may define explicit version range.
You shall decide which constraint to apply given the level of confidence you give to the remote author to correctly upgrade its version number.
Finally,you can use glide to solve that for you.
Starting with Repo C, assuming you already tagged the repos, run glide init, git commit -am 'glide init', git push
Repo A, glide init, glide get git#repo.com/repoc, git commit -am 'glide init', git push
Repo B, glide init, glide get git#repo.com/repoc, git commit -am 'glide init', git push
Finally, Project A, glide init, glide get git#repo.com/repoa, glide get git#repo.com/repob, git commit -am 'glide init', git push
To re install the project, glide install, go build.
Nothing prevent you to tarball ProjectA with its vendor folder, in order to skip the glide install command when you execute the remote installation.
But you normally don t want to commit the vendor folder for a development environment. You d usually add vendor/ to your .gitignore file and run glide install or glide update.
Expect some difficulties in the begin, passed that step, things will work.
Once you jumped to that workflow, note that you ll have to bump every changes on your repos.
That is bloatware when you work both project A and repo B to reach a viable change, so in that case, rather than vendoring repoB into project A (you can leave the manifest definition, but get ride of the repoB folder into vendor/), install repoB as a go module with the go get command.
Doing so the changes are taken in effect immediately on re-build. Once the change set is completed, browse into each repos and bump them appropriately.
Finally you may want to use a version bumper to help you to get it done quick and fast, it happens i did one for my personal usage.
hope this helps.
I've gone through the Octopress setup and deploy instructions, and I have Octopress running on Github: http://wmerydith.github.com
My repo is set to the default branch of Master.
I now want to push changes to the config file, like changing the url:, title: and subtitle:. I made these changes, committed them, and then did a rake deploy, but the changes are not showing up.
What's unclear to me is the difference in process for pushing config changes, content changes and at some point, new updates to the Octopress blog.
For instance, will I use rake deploy to push config and content changes?
Will I ever need to run rake generate or rake deploy again? How do I push source changes when Octopress updates?
From the documentation, you might want to do a:
rake generate
before the rake deploy.
This will:
generate your blog,
copy the generated files into _deploy/,
add them to git,
commit and push them up to the master branch.
In a few seconds you should get an email from Github telling you that your commit has been received and will be published on your site.
The OP Will Merydith comments:
I am unclear on is if 'rake deploy' is enough to push content changes to the blog.
I'm seeing some issue with content not making it to the blog and am unclear if the error is how I am deploying or something else
I confirm the Rakefile task :deploy will execute default_deploy which will execute task :push.