Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

175

You can loosely replicate the role source control plays with three simple tools: Back-up software (Commits/Check-ins) Folders (Branches) Performing a directory merge between two directories using a tool like KDiff3 (Merging branches) Basically your workflow becomes: Create a new folder (new branch) Copy files to the new folder (new branch) from an ...


139

Although the consensus would certainly be to not work for this company I don't believe that really answers your question. You can't really replace SCM. You might not need the usual bells and whistles of a full-blown system. For example, the company may refuse a request for a server, but permit the use of a local SCM. They may dislike git, but permit ...


80

the question is should we use branches nowadays? Well about half year ago I was assigned to perform a study to answer that question. Here's the summary, based on references studied (listed below) there's no commonly agreed "best" branching strategy applicable to any project most resources seem to agree that choosing productive strategy depends on the ...


64

Unless you are all working out of the same working tree, you are using branches, whether you call them that or not. Every time a developer checks out into his working tree, he creates a separate local branch of development, and every time he checks in he does a merge. For most teams, the question isn't if you use branches, the questions are how many and ...


59

Some suggestions: There is nothing wrong in having a lot of feature or bugfix branches as long as the changes done in each branch are small enough you can still handle the resulting merge conflicts in an effective manner. That should be your criterion if your way of working is ok, not some MSDN article. Whenever a branch is merged into trunk, the trunk ...


52

To answer, you have to ask yourself how you expect to use the results of these commits in the future. The most common reasons are: To see what release a bug was introduced. To see why a certain line of code is present. To merge into another branch. To be able to check out a previous version for troubleshooting an issue a customer or tester is seeing in ...


39

I think whatever you do, try to avoid checking in code that you know won't compile. If you think your third option is feasible, that might be a good way to do it, as long as you can ensure that your sequence of commits won't create an uncompilable system. Otherwise, just do the one big commit. It's ugly, but it's simple, quick, and gets it done. Going ...


25

Basically, there is a management problem (your organization don't understand the basics of software development process, e.g. the V-model) condensing into the apparent inability of using minimal present-era workflow, methodology, and tools. This is common (read about Peter's principle). BTW, I guess that recent SNCF railway incident in Paris at end of 2017 ...


18

The most important reason to make frequent, small, and meaningful commits is to aid understanding of the history of the code. In particular, it's very difficult to understand how code has changed if it's difficult to generate understandable diffs. Option 1 obfuscates the history of changes you've made, but otherwise it won't cause any problems. Option 2 ...


17

The terms describe very similar concepts and responsibilities, and in general they are somewhat synonymous. The term "DevOps" is a relatively new one, popularized by the Devopsdays Ghent 2009 conference and subsequent Devopsdays events. It's best described in this diagram: On the other hand, Software Configuration Management is a far more established term ...


17

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'? Sounds like it. Are some of the problems we're seeing a result of this merge process? Definitely How can we improve this merge process without increasing the bottleneck on my boss? At my company, every dev has the ability to merge. We assign a Merge Request to ...


14

Here is a pretty decent timeline of the major players in video form (no sound). It suggests that SCCS was first, by a margin of about 9 years. There is a lot missing off there though, as evidenced by this blog and the resulting comments.


12

Although the only reasonable answer is to never break the trunk, some times it is not possible. For example, svn can break commit if you commit too much (maybe an option, or a feature, I am not sure). In such special cases, just check in in pieces. Since you are a single programmer it is not going to disturb anyone. Therefore, I would go for option 1. If ...


12

This is essentially how a lot of open source projects work, including most notably the Linux kernel, which has a lot more branches in flight than you do at any given time. The typical way to avoid big bang merges in these projects is to create another branch (or multiple branches) for continuous integration. This is the branch you use to make sure your ...


11

First thing I would do is identify specifically what the government agency (presumably the IT department) is objecting to. If they have storage space, but no way of hosting VMs for servers, then the problem may be that the IT department is saying no to the SVN or GIT server and that is a big distinction. If the problem is the country of origination--i.e. ...


9

Given the constraints you mention in the comments (e.g.: can't get to Git download page, Windows platform, and using Visual Studio 2005), I can see 2 options, both of which I have used before in a similar situation: Use Visual SourceSafe as Emerson suggests in a comment. I worked with a team using VS 2005 some years ago, while most of the rest of the ...


8

They have tons of storage space Are you allowed to use it at your on decision? If so you could create a file system remote repository which is better than nothing. The downside is that pushing becomes slow while the project is growing because git needs to download the whole repository to look for the changes... so far the computers behave like ordinary ...


7

If you have several teams working on different features at the same time, there's no way you can omit branching. You should share (partly implemented) code with team members, preventing other teams from getting your not-finished features. Branches are the easiest way to achieve that. Though it's good to shorten the branches lifecycle and avoid working on ...


7

SCCS is one of the oldest ones, dating back to 1972. It has been introduced to early versions of Unix and is now part of the Single Unix Specification.


7

Try to break it into smaller commits that likely won't compile, as files have multiple fixes, changes, additional method names, etc. When I've found myself in a similar situation I used the following technique: Add only the code that is relevant to a particular feature: git add --patch Stash all other changes: git stash save --keep-index Run tests/try ...


7

Your environment First of all, I would not be so pessimistic like shown in many comments and answers. Yes, this is "stone age", but there are much worse circumstances. If your overall work environment (colleagues, location, pay, interesting programming work etc.) is fine and to your taste, then by all means stick with it. Regarding IT, it is what it is. ...


7

I agree with both Doc Brown but I also see another antipattern: My boss, the sole authority on the trunk repository, will actually defer all of the reviews of branches until a single point in time where he will perform reviews on as much as he can, some branches will be thrown back for enhancements/fixes, some branches will merge right into trunk, some ...


6

I would advise against it. Database schemata change together with other related code or resources. To be able to track changes properly, you need to make cohesive changes link to each other, and a shared commit is the best way to go about it. Consider your suggestion of keeping the schema under a separate branch. First off, you keep branches so you can push ...


6

The first free source management system was RCS developed by Walter F Tichy in 1982. If you follow the references in his original 1982 paper, cited in the Wikipedia article, you will get answers to some of your other questions.


6

Personally being a Sr. Software Configuration Manager for many years (10+) I hear the terms mismatched in a variety of real life situations. It is not uncommon for non technical personnel due to the relative nature of the positions. They both have specific roles, needs and requirements that are similar but yet can be clearly divided in my opinion. I ...


6

It would be a poor version control system that didn't allow you to do this. A technical term for displaying the origin of lines by version is annotating a controlled file with its history. Recently, newer RCS like svn and git have switched to calling the action blame instead, but the functionality is the same. Searching for those two terms will tell you how ...


6

Unit tests are code as everything else. So if you merge your code, and your unit tests depend on the version or revision of the non-testing code (which is normally the case), you should always merge your tests together with everything else. This includes the resolving of any merge conflicts, if they occur. If the merge conflicts of your test suite are not ...


5

But recently I see more and more followers of idea to not make branches as it makes more difficult to practice continuous integration, continuous delivery, etc. Well does it make more difficult to practice continuous integration, continuous delivery, etc for you concretely? If not, I see no reason to change your way of working. Of course, it is good ...


5

Kind of putting out the obvious here, but maybe worth to mention it. Usually, git repos are tailored per lib/project because they tend to be independent. You update your project, and don't care about the rest. Other projects depending on it will simply update their lib whenever they see fit. However, your case seems highly dependent on correlated ...


5

I think a lot of people here are missing the "government institution" of this question. Some government networks have very strict regulations on software allowed onto them, and breaking those rules are a fireable offence, perhaps even criminal. I'd push it through management to see if you can get some APPROVED movement on getting the software installed. I ...


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