I'm not new, but still struggling with git. in particular merge vs. rebase. the current result is that when i go to github.com to look at my feature branch (last commit) , it tells me that 152 files were changed, with 6,099 additions.... I'd estimate more like 30 files. And indeed, the changes shown are certainly not mine.
It has, admittedly, been a long-running branch (4 weeks or so) but I keep updating it with the develop branch that the team uses. Sometimes I need to make conflict commits, but not this many.
Before I do a pull request, any thoughts on what i did wrong would be appreciated.
I faced similar issues many times. I would suggest to raise a PR and in files changed tab it will only show your changes. I have had similar problem but it works perfect when you raise a PR.
I would git ignore all of the self generating files in the project. gitignore
Just make sure that all files you do this with can be deleted from the project and the project would just remake them without causing issues.
Related
I have a large repository (20000+ commits) that takes a while to do a one-time cutover from SVN to git. There is a tangled web of hundreds of branches, some of which are proper branches, others are more like developer sandboxes, some are partial branches, some are tags, some are unrelated repos which I will be extricating, etc. so I am familiar with the subgit configure feature and modified the config file in the subgit directory.
These branches create a lot of errors from subgit (I don't know why for most of them), and while I don't care about individual branches/errors, I don't want to exclude them all. There was an explosion of creating these branches around the 10000th commit, so I have to wade through the first half of the repo before any of these errors come up (about 4 hours).
So I'm wondering: Is there a way to restart the import after an error with a modified config file? It could either comb back through the commits it already did and make sure they look good or start at the problematic one, either way it would ideally succeed because I changed the branch mapping to exclude the problem. Thanks!
It is possible to restart the initial import with the same command used for the initial start, but the thing is that the mapping configuration change that affects branches mapping (means adds or removes branches to/from the configuration) requires the repository import restart from scratch as such the configuration changes usually affect the resulting Git objects.
I'm still getting the hang of VS Code.
I want to make a react app using 2 different GET API URL endpoints but the exact same UI. In essence, I want to change just the base URLs between the 2.
I've tried creating a new branch in VS code to make 2 separate files but once I make edits in the master branch, the changes reflect in the new branch also.
Is there a way of making a different stand-alone branch from the VS code?
I've searched through the forums to no precise avail and I'm not that good at git. Thanks.
It is likely that your changes are being shown when you switch branch because you haven't commited your changes to a branch before switching.
Let's say you are on the master branch and make some changes. You can create a new branch new-feature and change your current working branch to new-feature bringing your existing changes across. This is useful because sometimes you will start to carry out some work before realising the scope is a bit too big and should be it's own branch.
If you want to keep the changes you have made on your current branch, you need to "stage" your changes with git add your_filename.here (or git remove). Once you have added and removed all changed files you want to keep on that branch, you need to git commit them. This is the step that finally adds the changes to the version history.
Now when you change to new-feature branch, your changes on master will not be there.
There are a number of GUI applications that make the git model more intuitive such as SourceTree, Github Desktop, and SmartGit
I'm very new to version control and git, and I'm trying to learn how to use SourceTree. I have about a dozen commits already and I'm not sure why or how these .baml files were created, but they were not in any of my previous commits, and I'm wondering if can stop tracking and ignore them or not.
If I understand what I've read about baml files is that they are created at runtime so I would think they aren't necessary to track, right?
Wikipedia says they are binary files and it seems as though they are a byproduct of the actual coding work you're doing. In other words, as you say yourself, you didn't create them, so it'd be safe to ignore them (simply add the following line to the .gitignore file in the root of your repository *.baml).
In general, you should use git to keep track of text files you're actually changing. There are, of course, project-specific exceptions to this, but your case doesn't seem to be one.
We have constant problem with project XML file (*.sqlproj). If the files are added/renoved/changed location then it automatically adds/removes records in some unexpected places. After that we have big troubles by merging it when somebody changes that file also.
We came to conclusion that we might sort it before checkin. We would alphabetically sort it and in that case merge tool will understand it much better.
So, my questions would be:
Is it possible to re-arrange sqlproj file somehow before EVERY check-in? Maybe there are somekind of options/tools that doing that already?
Are there any other ways to make developers life easier?
UPDATE:
Once again I got the same problem. sqlproj file was modified 3 times and I want to merge to production only the last change, other 2 are not tested yet. in the merge tool I have the option to add all these 3 new objects or leave it without changes. I am not able to select only the last change ...
EXAMPLE:
developerA created tableA and checked in;
developerB got the latest version of dev branch, created tableB and checked in;
developerC got the latest version of dev branch, created tableC and checked in. DeveloperC tested the code and ready to go to production. He tries to merge his code to QA and get's the conflict where he has an option only to go with ALL changes.
I understand the scenario you are running into very well. This typically happens when you have multiple work streams happening in the context of a single repository and you don't have a common promotion schedule (as in all work will go to QA at the same time and PROD at the same time).
There's a few ways I can think to get around this problem and there are pros and cons to each option.
Lock each environment until everything can promote together. Not realistic in most cases.
When you are ready to promote, create a promotion branch from source environment and take things out of the promotion branch that aren't ready to promote to destination environment. This allows devs to keep working and be able to promote without freezing.
Hybrid approach... Don't source control anything in Dev until it's ready to promote to test. Then either do option #1 or 2 from there onward.
Create a more flexible ecosystem that can spin up an environment for each Feature branch in order to demo/test with others(or at least allocate/rotate enough between the developers to accomplish the same objective). Once it's accepted promote. This is what we are working towards currently but building out the infrastructure and process when you have a ton of interconnected databases and apps that share them is a bit challenging to say the least (especially in the Microsoft world).
Anyways hopes this helps...
1 - what source control are you using? No source control that I am aware of understands the context of sqlproj files but this isn't normally a problem.
2.a - This shouldn't be a problem you get constantly, are you checking in/out regularly? I would only expect to see issues if different developers are making large scale changes to the projects and not checking out / checking in before and after.
2.b - It is also possible you are not merging correctly, if you take both both sets of changes then it is normally fine.
ed
Lately I have been editing a single CSS file over and over, and it got me to thinking what files do you touch most within your project?
For me it would be the environment.rb, or the en.yml file if I was coding in Rails.
I would like to update a list here with the most frequent files over time.
Rails
environment.rb
en.yml
For me it's TODO.txt. Usually additions, unfortunately.
I edit en-US.yml all the time. I'll probably have to edit it before I finish this post. Yep, there I go.
The only file I keep on editing the same amount in all projects is build.xml if using Ant I think ;-)
Unless I've set up a script to extract revisions since the last tag from Mercurial, I usually update CHANGELOG or CHANGELOG.txt quite frequently for the benefit of those who downloaded a snapshot instead of cloning the repository.
No file in particular. I'll code a lot in one file for a day or two, hitting a couple of other related files as I do, then move on the the next.
If I'm spending the majority of my time in a single file, I usually figure that I'm doing something wrong.