Tag Info

New answers tagged

-1

Put your first 2 solutions together and you don't need a third. If you save your spreadsheets on disk as CSVs, Excel will still edit them and then git will be happy to merge them for you. Similarly, you can open, edit, and save your files in Word if they are HTML or (god help us) RTF. Word of course will add more bloat than useful text, but it's still ...


1

Seems very reasonable. We are using something very similar. My advise is just to keep the feature branches small. Maybe one days work. Longer brances means lower productivity due to a large number of merge conflicts. Mostly one feature branch equals one post it note on our scrum board. One note is you write "I start working on some feature. I create a ...


3

To upload into a git repository, at some level you have to use git. But, you don't have to expose git directly to the users. You can write your own code that handles the git operations behind the scenes and presents a simpler system to the users. See: https://libgit2.github.com/ for library that would let you make git calls. Of course, that means you'd ...


0

Your question is about code organization (as specified in the title) and many here seem to be talking about VCSs, that might not solve your problem at all. You do not seem to need version control, your problem seems to be something else. Basically what's been happening is we end up working on the exact same thing, or we write code for components that ...


29

It's a joke, that is based on the monad joke, but without actually getting the monad joke. The monad joke is funny on three levels: it tries to explain abstract mathematical jargon with even more mathematical jargon, which is even more abstract however, the explanation is actually correct and once you dive deeper into category theory, you will actually ...


0

There are a couple of things here that need to be addressed. First, there is the two code bases. You've got your code. Your friend has his code. Wen you do a merge (somehow) you're doing it without the ability to see the changes that did it before. You don't need github to do this. You could have a master git repo on a thumb drive, and then merge to ...


1

Do I need to use tags for every version? If by "version" you mean a set of files that make up a release or a release candidate, then I strongly recommend tagging every version. If you need to refer to version 1.2.7 down the road, do you want to hunt for a commit's hash or just use the version number? Also if you use git describe to record build ...


9

You should look at git-flow. It's an excellent (and popular) branching model. Git Flow Summary Branching The main trunks that stay around forever are develop and master. master holds your latest release and develop holds your latest "stable" development copy. Contributors create feature branches (prefixed with feature/ by convention) off of develop : ...


0

Scanning your list I see version as your focus, so... One way to maintain versions is with branches and merging (or rebasing). So you have: master then you create a branch v1 then you add more changes to master(diff1) then you create a branch v3 then you add more changes to master(diff2) Now: To update Version 2 you now do git checkout v2 ...


2

Do I need to use a tag for every version? No, you don't need to use tags at all. If you want to tag every release, that's fine, or if you want to tag every single time your CI system builds, you could do that too. Tags are essentially just giving a user friendly name to the commit, so that you can easily pull it up and view it later. Should I create ...


4

For this kind of work I suggest you to learn about Maven wich deal with dependency compatibility (among a lot of other things). With Maven you could for exemple use one of theses two ways : Either the "standard" way : by creating a Nexus repository which you will feed with a compiled jar of each version of your common package and to fully exploit ...


0

git stash is a tool. It in itself is not a pattern, nor an anti-pattern. It is a tool, much like a hammer is a tool. Using a hammer to drive nails is a pattern and using a hammer to drive screws is an anti pattern. Likewise, there are workflows and environments where git stash is the correct tool to use, and workflows and environments where it is wrong. ...


1

I think the part of your question that is an anti-pattern is the use of a single shared master branch. However, if you were to include a develop branch in addition to the master branch and then use stashes to deal with your own context switches in the develop branch, that would not be an anti-pattern, and it very closely mirrors some of the workflow ...


0

It really depends on the relationship between the original repository and this new repository. Is one a dependency of the other? Quoting from the git-submodule documentation: [...] submodules are meant for different projects you would like to make part of your source tree, while the history of the two projects still stays completely independent ...


7

I personally only use stash for short, unexpected interruptions, like someone asking a question that requires changing to a different branch. I do this because I have forgotten about stashes before, then they wouldn't apply cleanly. Regular commits on feature branches are much harder to forget about, and easier to merge, so now I tend to just make a broken ...


22

From the Git SCM Book: Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command. Stashing ...



Top 50 recent answers are included