Tag Info

New answers tagged

1

Use a new branch. For naming, you could consider using an internal format that this_work is an extension or change to that_work For example you could name the second branch modeling-member--attributes with the -- signalling that the name name on the left is the original branch We tackle a somewhat similar problem as we use Jira ticket numbers for ...


0

If you want to save only commits from a merge on the master and you are using github, you could use "Fork" to every new feature and do a pull request and accept pull request after you get every new feature done. I don't recommend working on old branches, since you can get conflicts when you merge it to the head of master and of course it's not needed to do ...


8

Create a new branch, because: A brand new branch is less likely to have merge conflicts when you're done and want to merge it into master. Few things are more error-prone than fixing merge conflicts. The feature may have gone through several changes and updates since its original implementation, making the original branch totally obsolete. The only way to ...


3

The approach that I follow is based on the following premises: Developers are not to be bothered with production data. That's for the operations department to worry about. Configuration xml files, scripts, etc must be kept at a minimum. Everything must be in the source code repository. The source code repository is to contain only diff-able text files, ...


3

I propose looking into in code migrations for your language or technology. I have .NET stack and I can use Entity Framework Migrations where every schema change is single migration that can be automatically applied to database when needed. What is also possible is downgrading database, so pattern for db migration is that you have method for Up() and Down() ...


0

I don't think the projects in that question are the same as the ones in your case. The project's in that question are build projects - they are all different components of the same application, divided into projects for the ease of building and releasing. Such projects, even when placed in different repositories, should share the same project in the ALM, ...


4

Don't add any outside contributor right away - make them send pull requests instead. As you review these pull requests, you can: Assess the skill of the contributor from the quality of their code Verify that what they want to add to the project is compatible with your vision See how willing they are to conform to your rules and style Learn to know them a ...


2

Generally speaking, a software project is a collection of code, data and tests. Typically these should all live in the same repository. Using BDD or TDD means simply to check in (or at least develop) your tests before developing your code. It doesn't have to be any more complicated than that. So, the reason why no specialized workflow has been created is ...


1

Honestly, this doesn't sound like something your VCS should care about. Your VCS should only care about the storage of, revisions to and merging of changes to your source code. The idea of a wishlist of features doesn't fit with any of those things. A wishlist of features is the domain of a product backlog (or something similar). Stakeholders can file new ...


0

This is a common workflow; the Git team even added a command for it: git subtree will convert the directory into a submodule. See this StackOverflow answer for more details: Detach subdirectory into separate Git repository: The Easy Way™.


1

so your problem is that you're merging every hot fix two or three times? (First to master, then to develop, lastly from develop to master again)? yeah, that's it! Can't avoid that though, hotfixes have to be merged into develop Sure, but why merge from develop to master if nothing actually changed? Take a look at one of those ...


0

Hash is not the unique solution for distributed VCS. But when deal with a distributed system, only the partial ordering of events can be recorded. (For VCS, the event can be a commit.) That is why maintain a monotonically increasing revision number is impossible. Usually we adopt something like vector clock (or vector timestamp) to record such ...


2

Often you have files which appear in your project directory which you don't want to have in your git repository. For example files the software reads and writes in its own directory as part of its operation. That's why git doesn't blindly index everything in the project directory but instead asks you to add files manually. Also, any binary files should ...


0

Merging in SVN is no different to merging in git - if the computer can figure it out, it does it and all's good, if it needs manual attention it prompts you. (exception: SVN's handling of new/deleted/renamed files is poor, but git can have issues in this area too). So, that out of the way you can really think of SVN as a clone of a repo that you push to. ...


0

The hardest part about having a lot of projects and a lot of people often isn't about how to maintain the code, it's how to communicate, implement the process, and work together with good tools. To achieve that goal I'd recommend you use git for source control use jira, trello or privotal tracker for issue tracking use agile processes and look into using ...


1

You need to have some kind of version control system. You MUST have it. If git looks too complex try mercurial, even thought they are very similar. Set up a git repository server. My team uses gitlab and it works fine. You need to put some rules for the control versioning. Meaning, ideally not all cannot commit to the main branch for example. You should ...


1

Fogbugz + KilnHg have unlimited private repos in Git / Hg (Actually both at the same time) for free for 1-2 users. It also has good integration into Trello. You can organize repos under projects in it. https://www.fogcreek.com/kiln/try/?fccmp=_startup


2

The issue you are encountering is weird. You may check twice the way NuGet dependencies are stored in source control. What may help is: To use one solution instead of several ones. Unless there are multiple teams in different departments of your company working on completely independent projects with a dependency on a common project, one solution may make ...


1

Something to consider, are you using distributed version control or centralized? (Edit: I realize this was tagged as git, but I still feel there's relevant information about deciding when to commit in my post.) If it's on your local machine or your own personal branch then do what feel right, but I'd still lean towards to following below. At my job we use ...


1

It all depends on the meaning of "check in". With git, you can have a private repository, so checking in is nothing more than a personal backup. I make a small change, it works so far, I check it in. I do some experiment, it doesn't work, or the experiment tells me what I want to know, I cancel the checkout. That means I have to check in when there are ...


1

From what I've observed, different people vary greatly in their commit frequency. Some people make frequent tiny commits, and others make rare big commits. I've seen people not commit until they finished several weeks of work, resulting in one gigantic commit that touches hundreds of files. IMHO, huge commits are a bad idea. I like to think of commits as ...


10

Commit away. Commit as often as possible. Commit when its incomplete, commit when its finished. It really doesn't matter. I even will commit and push to remote when I get up for a 1 hour meeting or lunch even... The catch is you need to be in your own branch (one that no one else will be pulling from). This should be a part of your normal development cycle ...


5

I say that not only you may commit unfinished changes when you need to stop working on it - you probably should do it. When you have to leave a task for a long time, always assume that you are going to "context-switch" by the time you're back. Now, if you are just going to make a coffee - or even take a launch break - you should be fine, but if you leave the ...


4

Your question really depends on quite a few things: Code Base complexity, change complexity, people working on code base, people affected by your change, etc. I personally avoid committing unfinished business, even if that means not committing for a few days (Many people will disagree here). And it certainly is good to stay "connected". So in light of all ...


32

Committing code is cheap in git. You have several options: Commit and amend later $ git commit --all -m "WIP: half-implemented hack" ... time passes ... $ # back to work $ git commit --all --amend -m "Nice logical atomic commit" Use git stash Same as above, but using a stash: Commands are a little shorter to write A stash by nature ...


4

A local commit can always be safely amended if it hasn't yet been pushed upstream, so you could commit at the end of the day and take it up again the next. However, this is of limited utility as far as code sharing and redundancy are concerned, unless working on a branch that's yours alone. In that case, you've got the right to push one day and force an ...


5

The concept of committing the code when it reached a 'milestone' is mostly due to, other developers/testers should be able to checkout the latest version without fearing that they can't compile / debug the code because it's broken. When it comes to the distributed version control systems like Git, there is no such issue when checking in the code as it's ...



Top 50 recent answers are included