Tag Info

New answers tagged

-3

The best source control system is one that I don't have to think about. TFS meets this requirement, GitHub does not. I have enough on my plate without having to worry about learning a bunch of cryptic command line syntax.


6

From my experience, feature branches are strictly more general-purpose and flexible. The advantage is that feature branches allow for a developer to work on multiple branches concurrently - and even for multiple developers to be working on the same branch, if needed, without confusion ("Why is Joe writing commits on the Bob branch...?"). Using ...


-3

An organization I contracted for in the past wanted to solve this same problem, and came up with a fairly good social solution: developers do not have their own computers. The development TEAM has computers, but any individual can be asked and expected to work on any development computer on any given day. So, checking in is the only way to make sure you ...


42

You're looking for a technical solution to a human problem. That rarely works. The reason for that is because if team members do not accept something (nor understand the implications), instead of following the rules, they'll attempt to circumvent them. That's exactly why, for example, developers should accept and understand style rules instead of just being ...


5

When used properly, VCS has too much detail. Every little change is recorded, when a changelog is generally for the big user-visible changes. In short, the target audience for a changelog is not the same as for the commit messages of the VCS. If you are disciplined, a changelog can be an auto-generated subset of what is in VCS, though in my experience most ...


2

What's the purpose of keeping a changelog if everyone uses their VCS properly? ... If this history is being properly kept, what is the purpose of manually keeping the same history in a regular file? Your question is a good one, but you're making two big assumptions. Given a team with a disciplined check-in history, you're assuming that the ...


5

Basically, you're completely right. All the information should be in the VCS as well, and as commenters said, changelogs are often generated out of VCS information. However, prepared changelogs come with some remarkable advantages: A changelog does not require to connect to the VCS, maybe install the proper VSC client before, scrolling through tons of ...


0

There are two main reasons to use branches in a VCS: To isolate unreleased features from each other and from released code. This is mainly what git flow is all about. To share unfinished code with other developers without impacting the whole team. This is exactly your use-case, where you can read "other developers" as "myself sitting behind different ...


0

This is perfectly acceptible for me. In fact I've probably done this since I started using version control as I found it the most convenient way.. Other options like dropbox etc work but then you still have to wait for the sync and it does lead to conflicts sometimes which are a mess. I've even known people emailing themselves the temporary work, even ...


2

I think this varies from project to project. Generally the advise by Bart is a valid one. If these assets are directly connected to the source-code and managed by the developer (best example are images statically linked/embedded in a template) it's a good practice to have them inside the repo. If this isn't the case, we have to ask some other questions. ...


1

If you really believe in code reviews, then coding isn't finished until the review-revise-repeat loop exits. Until then, the code is in a sequence of preliminary forms, not its final form. Your tester could test one or more preliminary versions of the code, but the tests ought to be repeated from the beginning on the final code. Good testing practice ...



Top 50 recent answers are included