Tag Info

Hot answers tagged

53

One approach is feature flagging it. It can live in the code base but be disabled by configuration. Another option it to make a revert commit that reverts the feature merge so that it's not in develop any more. A new branch can be made which reverts the revert, and be left pending to merge later. If you're using Github pull requests, you can do this easily ...


43

I would be against doing this for the following reasons: Any time you set up an automated tool to change code on your behalf, there is the risk that it will get it wrong, or that a situation will arise where you need it to stop making that change (e.g., the latest version of Google Mock had a bug in it, so it's not your code failing) and you have to waste ...


22

Let's agree on terms first. I personally use the terms Continuous Build and Continuous Integration to distinguish two different scenarios: Continuous Build: a tool that checks periodically if the repository changed since the last build, and build/test if it did. Continuous Integration: a tool that takes Pull Requests and validate them against the latest ...


18

How could we have avoided this issue? From a process perspective, figure out: Who was the decision maker to start this work? Why did the decision to release this feature change? Missed expectations? Miscommunication? Inadequate business support? No customer involvement? More than likely there were drops in communication along the way. This is ...


10

Forget for a moment the issue with your management, and imagine you had the "automatic signup feature" already in your latest production release, deeply integrated into your codebase. Now you get the new requirement to add an "off-switch" for "automatic signup". How would you handle this in your Git workflow? I guess you would declare "disabling of ...


5

Is this a best practice or it may be more problematic than just leaving master broken until the developer fixes it? It is problematic. A person deciding "the master HEAD is broken; I will revert the top change" is completely different than the CI system doing the same. Here are a few disadvantages: Errors in the automated reversal process will screw ...


4

At my company, we have never really had problems with too many commits. The key to organizing is to create well named branches and do your work in them. That helps to organize not only commits, but the developing group as a whole. Yes, without branching, it could become a huge mess, but with them, your management can just browse the commits using them ...


3

Wow, that's a long question (and a complex problem). I'll try to have a go at it. I'm not sure I understand why each user has to have a full local history when using git? This is a central design decision with git. For the exact reasons you'd need to ask the author (Linus Torvalds), but as far as I know, the main reason is speed: Having everything ...


2

Instead of a single repository with a ton of branches and all code funneling into one place, consider many distinct repositories. And, use a CI build server to build from the repos. Last, output the build artifacts like WARs or MSIs or whatever to a company wide Nexus or Nuget server. This way, you can manage the life cycles of each little module separately. ...


1

The CI should never alter the commit history of the repo. The correct solution here is for no commits to be added to master branch if they haven't been tested and verified. Do you work on feature branches, have the CI run automatically on those, and if the builds fail, don't merge them into master. You can have an additional build that tests merges if ...


1

It's a joke, as confirmed by the author and Jörg W Mittag's answer explains in more detail. But truth can be stranger than fiction… There has been work of formalizing version control, in particular patch theory by David Roundy which is the basis of Darcs (a distributed version control system that preceded the more popular Bazaar, Git and Mercurial by a ...


1

it's another way to say "patches are welcome". instead of sending wishes and feature requests, people can send pull request where the original author review, validate and merge the pull request.


1

This is a common problems with all source control systems. It is a communication problem, perhaps made worse by the ease with which extensive changes can be made globally. You have outlined the most common solutions: Make the work done in a feature branch smaller, so that it is easier to integrate, and compare to the main branch. Make it a priority to ...


1

Most of the time, if you think you need submodules to keep dependent versions between your separate repos in sync, that's a sign you'd be better off with a single repository. Separate repos should usually be highly independent, and be able to be updated and released without worrying about the versions of other projects. Even with all the projects in one ...


1

I agree with Snowman, but as to not leave you empty handed, I will discuss a few possibilities. If by 'doing the front-end work', you have primarily been tasked with designing the project, then you can design the site according to your normal workflow and simply pass it off to him to integrate it. If you are responsible for everything client-side, then you ...


1

Its problematic if you already work with others, rebase/tidy up your history of a branch where other participants work with and push it afterwards to a public repository. Other participants of your project will have major problems. See -> this explanation But you work alone so far. There will be no problems if you publish your repository now. You will get ...


1

In any project where you share code you should be very hesitant to alter the history and force push. This is especially true for open source code. I didn't quite understand your question, but it sounds like when you try to fix something you end up breaking something, which is revealed by some sort of automated test suite. A good practice is to open a ...


1

Look into GCC mailing list. Migrating the GCC compiler's source tree from SVN to GIT is discussed right now (august & september 2015), while keeping GCC's history. See e.g. repository for the conversion machinery & Acceptance criteria for the git conversion mail threads; you'll find references to tools and procedures related to the conversion (which ...



Only top voted, non community-wiki answers of a minimum length are eligible