I have a requirement to have a property configuration for different environment like dev, uat and production. For example a config.properties having and entry like environment=dev, this I need to change for staging branch as environment=uat and for master branch as environment=prd .
I tried to commit these files in each branch respectively and tried adding config.properties in gitignore so that it will not consider in next commits.
But git ignore not getting updated so I ran command
git rm -rf --cached src/config.properties
git add src/config.properties
git commit -m ".gitignore fix"
But this command is deleting the file from local repository itself and the proceeding commits also deleting from branches. I want to handle the branch as such so as Jenkins will do the deployment without editing config file manually. I am using fork for git UI. Is there any way to handle this kind of situation?
You should not version a config.properties (git rm is right), and ignore it indeed.
That way, it won't pose any issue during merge.
It is easier to have three separate files, one per environment:
config.properties.dev
config.properties.uat
config.properties.prd
In each branch, you would then generate config.properties, with the right value in it, from one of those files, depending on the current execution environment.
Since you have separate branches per environment, with the right file in it, you can have a generation script which will determine the name of the checked out branch with:
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
That means you could:
version only a template file config.properties.<env>
version value files named after the branches: config.properties.dev, config.properties.uat...: since they are different, there is no merge issue when merging or switching branches.
Finally, you would register (in a .gitattributes declaration) a content filter driver.
(image from "Customizing Git - Git Attributes", from "Pro Git book")
The smudge script, associated to the template file (package.json.tpl), would generate (automatically, on git checkout) the actual config.properties file by looking values in the right config.properties.<env> value file.
The generated actual config.properties file remains ignored (by the .gitignore).
See a complete example at "git smudge/clean filter between branches".
Related
I am trying to find out if I could get the value of a variable declared inside a Java program or maven-plugin and store it in a Jenkins environment variable.
This is because the Jenkins file has to create a new git branch from dev and call it Release-9.0.86 for example but the version number is inside a pom.xml.
I have already written a maven-plugin that retrieves the version from the pom.xml an writes it into another XML file, but I need to know if I could send the version to Jenkins to handle it.
You could perhaps create a properties file instead of a xml file with the needed information. Example contents of created branch-name.properties file:
NEW_BRANCH_NAME=Release-9.0.86
Then you can add a build step "Inject environment variables" after the one that produces the properties file, and configure that to read the properties file you just created.
Properties File Path: branch-name.properties
After that you can use the environment variables as usual in the jenkins build, for example a "Execute shell" build step that creates the branch:
git branch ${NEW_BRANCH_NAME}
To then push the newly created branch you could add a "Git Publisher" post-build action.
Branch to push: ${NEW_BRANCH_NAME}
Please note that it might be useful to configure Git Publisher to "Push Only If Build Succeeds" i.e. branch will not be created if the build fails for any reason.
I have created an Eclipse project from an existing Git repository.
It contains some sample documents and code, but i find it easier to delete them and start from scratch.
Will the old documents be deleted in the repository without any trouble the next time i do commit and push?
Follow the following steps :
NOTE : origin here refers to your remote project location.
Step 1 : From command line navigate to project directory where your working
Step 2 : In command line run the following commands
git pull origin master /* Just to make sure you will get all the latest files from remote repository where you have hosted your project */
git rm * /* To remove all the files from you current directory */
OR
git rm file1.txt file2.txt /* to remote specific files */
git add . /* Add the deleted files for staging */
git commit -m "Removed obsolate files" /* Commit the deleted files into your local repository */
git push origin master /* Now push to the remote repository all the changes that you have done, all the deleted files will be now removed from remote repository */
Step 3 : Now you can start working with your fresh files
If you want to delete a file, use git rm ${fileName} (in case you want to delete in only in git, but keep it locally, use the --cached flag. After that, once you commit and push, the changes will be available in the repo.
I am implementing a bot that performs scheduled backups.
from a front-end a user will be able to change the folder names the backups are stored in.
according to:
What's the purpose of git-mv?
mv oldname newname
git add newname
git rm oldname
is what I want to do when a folder or file name is to be changed.
so I move the files using Java FileUtils,
add the new file/folder and remove the old file/folder using:
git.add().addFilepattern(newName).call();
git.rm().addFilepattern(oldName).call();
git.commit().setAll(true).setMessage("Renamed group "+oldName+ " to " +newName).call();
The main goal being: to preserve the history of the files being moved.
Should I commit after adding the 'new' file before removing the 'old'?
Is my current order of operations fine and committing after both operations should preserve the change history?
I am still new to Git and how the logging works, in TortoiseGit it shows files added and removed, would it show up as a move in the log if the process worked?
Thank you for your time.
Git does not actually record history of individual files in the repository; it records the history of the entire repository as a single unit. There's nothing in a commit that explicitly says that the foo.txt in revision 2 is a continuation of the bar.txt in revision 1. Instead, renames are inferred by tools that examine the repository — after the changes have been committed — using the heuristic that if a commit removes a file and also creates another file with similar contents, the old file was renamed to the new one.
This heuristic only recognizes a rename if both changes occur in the same commit. If you remove a file, commit, then add the file back with a different name and commit again, Git will see that as separate deletion and addition of unrelated files.
Note that rename detection is optional and tools may not do it by default. With git log you need to use the -M option, for example, or do git config --bool diff.renames true.
I'm not familiar with JGit, but your Java code should probably mirror what Git is actually doing beneath the interface when you run your command. Since you are already doing this, I don't see any problem. I would make sure that the entire renaming operation appears in a single commit. There are several reasons for wanting to do this. You may want to revert the renaming at some point. If you have a single commit, it would be easy to do this via git revert.
With regard to preserving the history, renaming a file makes it harder to track the history, but not impossible, e.g.
git log --follow ./path/to/file
I have project in eclipse. I was developing it. Everything was fine. I use git to commit changes.
But starting from some point I noticed that not all files in git repository are committed.
When I do commit, git just do not show it under list of available files. I have tried to commit each file - no result, tried "add to index" - no result.
Does somebody know what can be the reason? I have such problem first time.
And no tracking symbol ">" appears.
In order to see if there is an issue with a .gitignore, switch back to the command line, and type:
git check-ignore -v -- yourFile
You will immediately see if one of the .gitignore rules applies to it or not.
One of the great things about using an IDE for Java is the automated refactorings you get. The problem I'm having is that after using Refactor > Move to move a class into a different package (which moves the file itself in the filesystem), git status shows that the file in the old location has been deleted, and the one in the new location has been added.
The workaround I've found is clunky:
mv src/com/example/newpackage/Foo.java src/com/example/oldpackage/Foo.java
git mv src/com/example/oldpackage/Foo.java src/com/example/newpackage/Foo.java
Is there any way (when using the Git plugin for Eclipse) to have the refactoring do a git mv instead of a naive filesystem move?
That's the way how Git works with renames/moves (delete old file and add new file). It then detects the contents of the file, and recognizes a rename based on an algorithm. So even it shows you delete and add, if you commit and then do a "git log --follow movedfilename", it should show you the whole history, even the history before the rename.