Hope you are all doing great :)
This is a simple question, that I found no answer to, online. Should .github/workflow actions (yml files) be added to gitignore?
.gitignore exists to avoid committing certain files to the repository.
.github/workflow files are usually used to tell GitHub to execute actions. GitHub only knows about files that are committed to your repository.
Hence, it makes no sense to add those files to your .gitignore since you specifically want them to be in your repository.
Related
Note: I am relatively new to Git / GitHub. I understand my way around, but I am confused with this corner case
Background
I created an IntelliJ color scheme git repo and pushed it to github online. The directory structure was ad hoc and made up of only output. This was actually fine and worked well.
I noticed that people would not get updates from me this way, and decided to create a JetBrain Repo plugin. This also works well; however, my github location and plugin location on my PC are different.
Issue
I looked over Change Git repository directory location. but was not sure if this fit my usecase.
Since my github is just output files and my plugin files are all input files, can I simply just copy over my .git files (along with README files and such) , and expect it to work correctly?
The linked SO question seems to relate to JUST moving the same directory structure and files over to another location. I am dealing with different directory structure, different files, and directory location; however, it IS the same project.
Update
Before, my workflow was:
Modify Color Scheme in IDE
Export settings from IntelliJ
Place in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
Now it is
Modify Color Scheme in IDE
Run project and autogenerate output in \IdeaProjects\ChroMATERIAL
Place output in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
What I want
Modify Color Scheme in IDE
Run project in \IdeaProjects\ChroMATERIAL
Windows GitHub Client: \IdeaProjects\ChroMATERIAL merge
GitHub
I'm assuming that the generated output matches the structure you need for your Github repository. If so you could easily move your .git folder from
\Documents\Github\ChroMATERIAL
to
\IdeaProjects\ChroMATERIAL
What you should check:
Will the generated output directory be cleared if you clean the project into Intellij? If so you should stick to your current workflow since you could easily delete your local copy.
The other thing which could be a problem is the Github Desktop Client since I don't know how it behaves nor how or if it must be configured in a special way to reflect your changes. (if you just call it from the inside of the repository it should not be a problem at all)
For your explanation:
Git uses relative paths. So it is irrelevant where the repository lives inside your system. The important part is the structure inside the repository since this will be cloned to the remote repository.
I recommend that you copy your .git folder rather than move it. If something goes wrong you can easily revert.
Apple has introduced a new project-related type of file in Xcode 5: "xccheckout".
This file is located in the ".xcodeproj/project.xcworkspace/xcshareddata/" directory, and it seems that it is related to the project's version control system.
An example file is here: http://pastebin.com/5EP63iRa
I suppose that this type of file should be ignored under VCS, but I'm not sure.
So here are the questions:
Should "xccheckout" be ignored?
What is its purpose?
You should check in an Xcode 5 .xccheckout file; in general, files in xcshareddata should be committed.
An .xccheckout file contains metadata about what repositories are used in a workspace. For a single project in a single repository that doesn't make much difference. But if you're using a workspace that has multiple projects from different repositories, the presence of an .xccheckout file in the workspace allows Xcode to know what all of the components that make up a workspace are and where to get them.
The *.xccheckout file contains VCS metadata, and should therefore not be checked into the VCS.
On the other hand: checking in this file will probably not create merge difficulties or other problems.
If you want to ignore this file (which I recommend) you should add this line to your project's .gitignore:
*.xccheckout
Abizern's solution will not work for projects inside a workspace. Because, when you use a workspace, the path to the *.xccheckout file will be: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. And it actually ignores more than you would want.
Edit:
This file exists for managing Xcode's knowledge of the possibly many VCS systems in your project, see Chris Hanson answer. For > 99% of the projects the .xccheckout file is configuration overkill.
It depends. The file contains references to the remote repository you are using. If you are using a centralized VCS such as Perforce or Subversion, everyone's remote repository will be the same and so you can and should check the file in.
If you are using a distributed VCS such as Mercurial or git, but using it as though it were a CVCS (in other words, everyone cloned from a shared repository directly to their personal workspace on their machine) then you still might want to check it in.
However, if you are using a DVCS with everyone having their own remote clone, for example using GitHub in it's standard usage pattern, you DO NOT want to check this file in. If you did then your Pull Requests will be asking for your repository settings to get copied into everyone else's xccheckout file, but your repository settings will be different from everyone else's because you are all using different remote repositories.
Yes, the Project.xccheckout file should be committed to your repository. Xcode uses this file to tell others who open the workspace the entire list of source control repositories used by the workspace and the location of the working copy relative to the workspace, whether those repositories are Git, SVN, or both.
When you open the workspace, Xcode uses the Project.xccheckout file to notify the user that there are other repositories forming part of the workspace, and asks which should be checked out. When checking out additional repositories, Xcode places the working copies in the same workspace-relative folder structure as they were when the Project.xccheckout file was generated.
As Chris Hanson said, it probably doesn't matter for a single-repository, one-project workspace, but for more complex affairs it'll be very handy indeed.
You can find out more about this in the WWDC 2013 session video Understanding Source Control in Xcode; the relevant portion starts at about 15 minutes.
This is what I have in my .gitignore for Xcode.
#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/
It keeps anything that relates to the local state of the way the projects looks for me out of the repository.
The xccheckout file is under here so it is not tracked on my system by default.
Xcode has gotten better and separating out what needs to be shared and what needs to be kept locally. For example; these lines will ignore the default build schemes, which is fine because you can mark specific build schemes as shared, and they are put in a directory that is not ignored.
Breakpoints are ignored, but you can mark specific breakpoints as being shared across projects and they are also placed in a directory that is not ignored.
I want to use Git for some personal projects I work on. I'm new to git and don't know how to start...
Should I first create the project (say an ASP.NET MVC application) in Visual Studio and then turn the folder that is created into a repository, or should I create a repository first and then create the project inside that folder?
Also, are there any best-practises for how to structure the folders inside the "repository root folder"?
These are my two questions right now, but any pointers to articles etc for best-practises using Git and Visual Studio are welcome!
Git repositories are so lightweight that it doesn't really matter whether you create the project and then create the repo or create the repo and add the folders. You will anyway be doing a git add and git commit after the folders have been created.
But, for me, I usually create the project from VS and restructure the folders so that at the root there is the src folder and the .sln and project files are within the src folder. VS would typically create the root folder with the project name which I rename to src. Then I create the repo, add the standard .gitignore and .gitattributes and commit the repo.
See my preferred structure here: https://github.com/manojlds/cmd
Of course, you can have whatever structure you want.
For using in VS you can use Git extensions. It integrates into the IDE and provides nice GUI over the basic Git operations.
As for the folder structure, it depends so much on the project, so no answer can be given here. There's no better practice than organizing based on the way you work!
As for the moment of repo creation, just create it as early as possible, so I'd say first create it and then add your project.
Organize your files and folders however makes since to your project and workflow, git doesn't care how the files are organized.
Since Visual Studio complains when I try to create a project in an existing folder, I follow the following steps.
Create a bare remote repository.
Clone empty repository locally.
add .gitignore, etc. and make initial commit.
Create VS project in a different folder.
Then I do one of the following.
copy the files from the .git repository into the VS solution folder -- which changes the location of the local repo.
close VS, copy solution files to local repository and then reopen VS.
I really should take the time to automate it, but I spend more time working on existing projects than starting anew so it hasn't been much of an annoyance yet.
I've tried all the visual git tools, including those that integrate with VS, but always end up using PowerShell instead -- just a matter of preference. Give them a try, they may work well with your workflow.
I'm going to start tracking a project I'm working on using TortoiseGit. I have a lot of .c and .h files, and then I also have .exe, .obj, .pdb, .ilk, suo, etc. I would like to create a snapshot of everything, all those files. So that I can roll back to a prior revision if necessary. However after a few weeks I want to upload all those revisions to github but I would like people to see only the .c and .h file changes and have only those files visible in the clean public version of the project. I'm new to git and not sure how best to go about this. The closest question I found (but don't understand really) is here:
Push a branch of a git repo to a new remote (github), hiding its history
Is that what I want to do? Can someone break it down for me with a step by step that I can do using gitk (Git GUI with msysgit) or tortoisegit? My experience level is I've read the GitBook but not the advanced section yet. Thanks
I think the link to the question and the answers given for it are the way to go for this.
Another way ( which many may frown upon ) is that you can put your git repo in a git repo. This way, commit the local binaries etc. in the outter repo, but ignore them in the inner one. Also ignore .git from the inner repo in the outter repo. This will enable you to go back to some older version of the binaries and corresponding version of the source.
So I'm having a bit of a structure problem with my repositories. I hope you guys can give me a few pointers on how to go forward with this.
Setup;
I have one large web project, with several opensource solutions integrated. I have it all in a Bazaar repository.
Problem;
I want two or more "configs" of this site now, meaning the database and css/templates must be different. How do I branch of this properly? I don't want my "base web project" in two or more repositories.
Putting another config database in another repo is fine, but problem arise when I'm moving out the .css from the base repo.
A quick search for ".css" finds around 200 files. I could clean this up, but then I will have a integration hell whenever I update my opensource directories.
Idea;
My current idea is to have one basesite-repo without the css files, and another config-repo with the database for the basesite-repo and all 200 .css files.
This works fine whenever I want to checkout the site and set it up, two checkouts in the same directory. Should work, right?
But how do I solve it when I work on the site(meaning base+config) locally? having two branches in the same directory? I foresee that releasing bug fixes will be a pain...if its even supported(?)
How my idea structure could look like;
//base repo
<base site repo>
-<admin>
-index.php
-<user>
-index.php
...
-<component>
-<helper_v1.43>
-index.php
//config 1 repo
<config1-repo>
-<database>
-<component>
-<helper_v1.43>
-<template>
-main.css
-<admin>
-admin.css
...
-<user>
-<timemodule>
-<template>
-time.css
This problem must have been solved several times over the last decade. But still I'm pretty lost, so any guidance would be appreciated.
Many source control systems support the idea of branches containing largely identical files. It might not be a problem for you to have the base files in one branched repository.
You can also create branches just for the config stuff in the second repo. switch between branches before you apply your fixes.
Another approach, if you have any sort of build or checkout process, check out the two branches (or two repositories) of the config stuff to separate directories, and then copy the correct one to the right place during your build.