Tag Info

New answers tagged

2

No, there is nothing you can do about this. Here's an article talking about this particular "problem" http://andrewwilkinson.wordpress.com/2010/01/27/where-github-possibly-went-wrong/ I am in a middle ground. I like that forks are easy to create and I think it allows people to easily play with and modify the code, and push back if they please. But, I think ...


1

What code review tool/system are you using? Because git does have ways to show the diff (or create a patch, I think) across multiple commits. So rebasing and squashing may be completely unnecessary. I also use a feature branch workflow, and I never bother with either. I just do a pull request (either in Github or Atlassian Stash) and it shows all the ...


2

First of all, since your specifications are rather unclear, I'm not sure how much of this really applies. But I'll give it a shot... If your project has one single release cycle, you only need one repository. If your three teams need to release new version independently, it gets a lot messier. But for that I'd need more specific input. At the moment, it ...


1

If dev-A and dev-B are different branches for different project then what @scaryrawr answered would be best. But if dev-A and dev-B is actually precisely the same code (same project) then an alternative would be that both work on one of the branches. For example you create a branch off master called 'devWork'. You both checkout devWork, work on it, commit ...


0

No, not necessarily. Usually one repo is used of one project with proper branch management. This separates the code life cycle into 'stages' which helps to keep unwanted changes being deployed to the wrong places. You could have a look at something like git-flow to help your code move from development to deployed on production, using one Repo. Git-flow can ...


0

Fixing the issue of the large pull request is one thing, and there are some good answers regarding that. But as for dealing with branches that get far out of date, you might want to revisit your processes for dealing with team work. If you're working within an Agile or SCRUM framework, the team should really be asking why the feature wasn't completed and ...


2

Let the guy who went for a couple of months without merging fix it. Maybe he can get one big chunk of code to merge, maybe he can get a bunch of little chunks to merge one at a time. In any case, he should be doing the legwork to fix the problem, since he caused it. What is the best way to deal with such a situation where one branch is really far ...


0

Here is a simple solution. Track the features that this person has implemented and go to each commit on that branch which was updated per feature. Take this commit and merge it with the master repo. Let me break this down in the form of an example. Let: Branch A be the branch from the master Branch A+ = Branch A + new feature 1 Branch A++ ...


0

First, see if there truly are separate commits that can be merged or cherry-picked, like suggest by @Maciej Chalpuk. If this is the case, then the situation really isn't that bad, and I wouldn't worry too much about it in the future. However, if the real situation is that multiple features have been developed concurrently in a single branch, within the same ...


5

Create a new development branch - let's call it "dev-with-dep". That branch will be rebased against master, and all the feature branches that depend on the new dependency will be rebased against dev-with-dep and merged into it when they're done. The dependency update branch itself will be rebased against dev-with-dep(after dev-with-dep is rebased against ...


1

If you have a commit that you know this and all previous commits is well tested and should be merged, then simply branch-out from this last good commit and merge the new branch with master. If you have some commits that you would like to merge, but they are interspersed with other commits that are not production-ready, then I see 2 possibilities: Create ...


3

To undo the merge, you can do git checkout master git revert -m 1 [SHA of the merge commit] git push This will create and push a new commit which reverts all changes that were merged in. It's also possible to alter master's history so that it appears as if the merge never happened, but I wouldn't recommend it. Your teammates would have trouble when they ...


1

I believe you're looking for the git reset command. If you run git log it will show you a commit history for your repo. Then run git reset --hard HEAD-number of commits you'd like to go back. Documentation here: http://git-scm.com/docs/git-reset


3

IMHO this decision should depend on the intended life cycle of your projects. If you are going to develop your "toy" project further, in parallel to your "real" project, and if you want to create a combined release of your both projects whenever you create a release of your "real" project, then one repository is better. But if you want to decouple the life ...


2

I start the new work based off branch X. As branch X changes from code reviews, continue to merge it into your new branch Y


0

Just a refresher, rebasing is mainly for when you want your commit history to appear linear if two branches have developed independently of one another, basically it rewrites commit history. the way I like to do it is git rebase --onto <target branch> <start branch> <end branch> where <target branch> is the branch you are rebasing ...


0

After spending the afternoon reading, it looks like git subtree is what I'm after. In this approach, I keep my library in version control with git, and each experiment goes into a separate repository. When I start an experiment, I pull the latest version of the library in in with a git subtree add. Each experiment has its own version of the library. If I ...


0

You could keep binaries for each library with a version name in each, e.g. mylib/thelibname-alpha.dll mylib/thelibname-beta.dll Your tests then reference the relevant version. If you need to patch a library, all tests using it will benefit, but other tests will be unaffected. The reason for doing this is the same as for embedding a version string in any ...


3

This is not so much a question of the version control system you are using, but more of your general configuration management strategy. First think about your strategy, then check how you map this to your VCS. Each version of your library you release into "production" should have a unique version number. You should keep track which of your "experiments" ...


1

I think what you need is somewhere to store and managed versioned artifacts. As you have noticed, this is slightly different from keeping the librar under source control. How to do this depends on the language: usually all language communities tend to reinvent this sort of thing. For instance I would use: SBT for Scala Maven for Java Bower for client-side ...


0

Keep your library in one git-repository and your experiments in an other. Use git submodules to keep track of versions of the library. It's actually built for this...


0

I quite like how http://cocoapods.org/ does it. It can be use publicly or privately. We have a similar issue where we a developing multiple objective-c controls that will be used in many applications. We couldn't make breaking changes as this would mean possibly breaking a project you know nothing about. This seriously hampers progress / innovation. So ...


1

Use an Adapter. An adapter is a class that converts from one version of an API to another. On one side of the adapter is the original API. On the other side is the API for the newest version of your library. You could, of course, simply make your library backwards-compatible, retaining the old API calls for the benefit of your existing experiments.


2

My advice is to get people skills up to date. I would push back against the assignment and say that adopting old work habits and patterns that don't match newer technology and processes is a bad decision for the future of the company and also for the future skills of the employees. Technology is a constantly and continually evolving and changing. When new ...


0

Most git clients I am aware of can do push on commit for the SVN-style workflow so you can keep git for the modern guys and let the dinosaurs keep their SVN-style workflow without rolling back to SVN. Having made the same transition myself I would try and fight the dinosaurs as one day git will dwan on them and all will be much better.


5

If you want just backups, I would recommend not to use git at all - that makes things unneccessarily complicated. Instead, backup your SVN server daily. Of course, if you don't just want backups, but also mobile access to the repo, you could choose an svn hoster. Maybe this site will help you to pick one.



Top 50 recent answers are included