I start using Github 2 days ago, and it's in a private repository.
So I with my friend (I appointed him as Collaborator) working a project together, but what is the best setting for .gitignore file when you're working with a team?
Because what I'm thinking is, if Github ignore file such as .env (the app key) & /vendor, the program wouldn't work as what it must to be right?
for now I using the default setting of .gitignore files.
/node_modules
/public/hot
/public/storage
/storage/*.key
/vendor
/.idea
/.vscode
/.vagrant
Homestead.json
Homestead.yaml
npm-debug.log
yarn-error.log
.env
Please help, I already search about it but I can't get the answer.
It is easier to start with the recommendation form gitignore.io.
See gitignore.io/api/laravel
Laravel
/vendor
node_modules/
npm-debug.log
# Laravel 4 specific
bootstrap/compiled.php
app/storage/
# Laravel 5 & Lumen specific
public/storage
public/hot
storage/*.key
.env.*.php
.env.php
.env
Homestead.yaml
Homestead.json
# Rocketeer PHP task runner and deployment package. https://github.com/rocketeers/rocketeer
.rocketeer/
Note that ignoring folders should be specified as aFolder/, with a trailing slash.
Any folder with generated content should be ignored.
If vendor/ is *not generated (but includes sources that you need to compile), then you should not ignore it.
Related
We have an internal discussion going here and we are somewhat torn on the best practice for using .gitignore on projects that contain a lot of files (like a CMS).
Method 1
Method 1 would be to purposefully .gitignore all files that come standard with your build. That would generally start like:
# ignore everything in the root except the "wp-content" directory.
!wp-content/
# ignore everything in the "wp-content" directory, except:
# "mu-plugins", "plugins", "themes" directory
wp-content/*
!wp-content/mu-plugins/
!wp-content/plugins/
!wp-content/themes/
# ignore these plugins
wp-content/plugins/hello.php
# ignore specific themes
wp-content/themes/twenty*/
# ignore node dependency directories
node_modules/
# ignore log files and databases
*.log
*.sql
*.sqlite
Some staff members like this approach since if you create something outside of the standard files, for example like a /build folder, then it would automatically be detected for inclusion. However, writing custom theming and plugins require you to add a few layers to this file to "step in" to the folders you want to keep, and generally, the file is a bit messier to read.
Method 2
Method 2 ignores everything, and then you whitelist what you want in the repo. That would look like
# Ignore everything, but all to descend into subdirectories
*
!*/
# root files
!/.gitignore
!/.htaccess.live
!/favicon.ico
!/robots.txt
# theme
!/wp-content/themes/mytheme/**
/wp-content/themes/mytheme/style.css # Ignore Compiled CSS
/wp-content/themes/mytheme/js # Ignore Compiled JS
# plugins
!/wp-content/plugins/my-plugin/**
# deployment resources
!/build/**
Some staff like this since it's cleaner, you have to purposefully add something (which makes accidental adds harder), and it also in effect shows you your .git folder structure.
What is the best practice? Which method do you enjoy and would you recommend doing one over the other?
The second method is the best practice, when it comes to exlude some folder contents of gitignore rules.
It better reflect the following rule:
It is not possible to re-include a file if a parent directory of that file is excluded.
To exclude files (or all files) from a subfolder of an ignored folder f, you would do:
f/**
!f/**/
!f/a/sub/folder/someFile.txt
Meaning: you need to whitelist folders first, before being able to exclude from gitignore files.
It is clearer, shorter (unless you have a large number of folder to whitelist)
What if it is a Joomla install with a large amount of directories and files?
Or what if a core upgrade adds new files or folders
Don't forget you can have multiple gitignore files, one per folder.
That means you can mix and match both approaches.
And you have:
http://gitignore.io/ (which does blacklist when it comes to Joomla application)
github/gitignore (same approach for Joomla)
The ideal .gitignore file, is the one that does not exist.
For some reason, you're deeply intermingling files you want to track via source control, with files you DON'T want to track.
This, I think, is the source of your sadness.
You are mixing git's intended purpose, which is versioning of programmer-edited files, with deployment, which is intended to get the files where they belong in the correct directories.
Your question is not clear, as to whether you think the Wordpress core files should be versioned. I'm assuming not, since that's how you've set up your .gitignore.
Your question is also not clear, as to whether you are deploying a web site, or shipping plugins as a product. Those are both different use cases, and they require different types of versioning. If this is a deployed web site, you SHOULD be versioning Wordpress along with everything else. If you are shipping a plugin or a theme, then you should have a test suite of plenty of different Wordpress versions to test against.
I think your source control system should be set up, solely to track just the plugins/* and/or themes/* files that go into your distribution. Zipping that folder should give you the plugin asset that your customers download.
To debug your plugins, there should be a deploy step in your IDE that copies each of those tracked files, into a Wordpress install at a location you choose. This permits you to more easily test against different Wordpress versions.
You're reducing workflow problems, to trying to choose a .gitignore. Fix the problem at the root by getting the workflow right.
I want to deploy some front end assets to the local web root of a site using file replacement. I can't seem to get it to work with a relative path in the target location field though. Is it possible to do this though tds or should I use a post build event instead?
The reason these assets aren't included in a project is that they are part of a third party solution but we still want this tracked in source control to try to make the project setup easier.
Most developer machines will be set up the same way for this project with the same file structure but I think it's a little more flexible if I can make the target a relative path so I don't need to worry about differences like drive letters and such.
The folder structure is as follows:
repo
folderToCopy
sitecore
webroot
I have tried the following using ..'s based on what tds changed my source location to be while using the "Make selected Source Location relative" option (changed it from an absolute path to ..\folderToCopy\):
../../Sitecore/Website
/../../Sitecore/Website
..\..\Sitecore\Website
\..\..\Sitecore\Website
From my understanding, TDS does the file replacement based on the files published from the associated Website project.
You can then have relative replacements such as the following:
<Replacement Include=".\assets\folderToCopy\myFile.txt">
<TargetPath>.\assets\targetFolder\myFile.txt</TargetPath>
<IsFolder>False</IsFolder>
<IsRelative>True</IsRelative>
</Replacement>
I have not been able to successfully get TDS to use the file replacement with files that are in source control but not in the project.
My suggestion would be to set up a build event that will copy these files to the correct location, or to create a nuget feed for them and pull them in as nuget references.
I'm trying customizing the webstatus templates for my buildbot 0.8.8 installation
According to the documentation:
Buildbot uses a templating system for the web interface. The source of these templates can be found in the status/web/templates/ directory in buildbot's library area. You can override these templates by creating alternate versions in a templates/ directory within the buildmaster's base directory.
Here what I did:
copied all html templates from my buildbot installation folder (/usr/lib64/.../status/web/templates) into the templates folder I found inside my buildmaster installation root folder (the templates was already there, and it contains a README file that seems to confirm what the documentation states)
modified the root.html templates
Unfortunately I cannot see any changes in the webstatus page.
Another test I did is to directly change the original template file in the buildbot installation path. The changes are now displayed. It seems like the buildmaster is not "seeing" the new template in the local configuration path.
I checked the file/dir permissions and I cannot spot any issue on that side.
Tried cleaning up the browser cache without luck as well.
Have I done something wrong?
As per source code, templates are retrieved from the WebStatus objects, i.e.
builder.py:573 ([1]) :
template = req.site.buildbot_service.templates.get_template("builders.html")
This property is created in baseweb.py:465 ([2]) :
self.templates = createJinjaEnv(revlink, self.changecommentlink,
self.repositories, self.projects, self.jinja_loaders)
The template lookup algorithm can be found in createJinjaEnv function, around base.py:506 ([3]) :
all_loaders = [jinja2.FileSystemLoader(os.path.join(os.getcwd(), 'templates'))]
if jinja_loaders:
all_loaders.extend(jinja_loaders)
all_loaders.append(jinja2.PackageLoader('buildbot.status.web', 'templates'))
loader = jinja2.ChoiceLoader(all_loaders)
As per documentation [4], jinja will return the first existing file in specified list, so while trying to load your template, Jinja will lookup sequentially in :
cwd
jinja_loaders property, that can be defined in WebStatus constructor by jinja_loaders param in your master.cfg
files from python package
IMO the easiest option is the second.
Hope it helps
[1]https://github.com/buildbot/buildbot/blob/2ab0e16ed0c46249f1d33308fd6878a1fc953f6e/master/buildbot/status/web/builder.py#L573
[2]https://github.com/buildbot/buildbot/blob/2ab0e16ed0c46249f1d33308fd6878a1fc953f6e/master/buildbot/status/web/baseweb.py#L465
[3]https://github.com/buildbot/buildbot/blob/2ab0e16ed0c46249f1d33308fd6878a1fc953f6e/master/buildbot/status/web/base.py#L506
[4]http://jinja.pocoo.org/docs/dev/api/#jinja2.ChoiceLoader
Is there any way to exclude a folder while creating an xpi file using cfx xpi. The documentation doesnt provide any info on this.
I am asking this because in the directory created by cfx init i also have a directory as HTMLTestPages in which i have some test JavaScript since we cannot debug the add-on sdk JavaScript.
Every time i have to create an xpi file i have to remove the folder and again place it. furthermore, if we has this folder on svn this is more problematic.
searching on google shows this bug listed to exclude vim temporary files and in the comments they are also discussing excluding any files starting with .(period). So is there any way to check if this is working in add-on sdk 1.6.1?
The current Add-on SDK version will only add very specific subdirectories to the XPI package, namely data and lib. If your project also has a subdirectory foo or files at the top level with names that the SDK doesn't recognize - these will be simply ignored.
Now if your files are located inside a known subdirectory like data - in this case they will be included in the package. The Add-on SDK has hardcorded rules concerning files and directories that should be excluded, you can see them under python-lib/cuddlefish/util.py:
IGNORED_FILE_PREFIXES = ["."]
IGNORED_FILE_SUFFIXES = ["~", ".swp"]
IGNORED_DIRS = [".git", ".svn", ".hg"]
This means that file names starting with a period or ending with either ~ or .swp will be ignored. But as far as directories goes - only .git, .svn and .hg will be ignored (and this definitely works). If you want an additional directory to be ignored then the only way will be to edit python-lib/cuddlefish/util.py and add it to IGNORED_DIRS list (something that you will unfortunately have to repeat after each SDK update).
I have a problem with my development workflow and Sphinx. I want to keep configuration file for Sphinx in version control so it's easier to manage. This means it's easier to link the file to code updates, etc ... However, the configuration file is stored in /usr/local/etc.
There are two solutions I can think of. Store the file in the repository and move it to the correct folder on deployment or recompile Sphinx to look for the file in my repository. I had a suggestion from someone to use a symlink, but that still requires a change on deployment.
Is there an elegant solution in Sphinx I'm missing?
perhaps have the /usr/local/etc/sphinx.conf file be a script that pulls the actual sphinx config from the file in your repo.
http://sphinxsearch.com/docs/current.html#rel098 scroll down to general and you'll see:
"added scripting (shebang syntax) support to config files (example: #!/usr/bin/php in the first line)"