Hot answers tagged

26

I've simply committed unfinished (and messy) states of my code before (and pushed it) only for the purpose of pulling that in the other computer to continue the work. I am pretty sure this a bad practice. It's OK to commit messy unfinished work. Do your work in a topic branch. Commit early, and commit often. Read up on When to commit code? for some ...


17

"Local", "centralized" and "distributed" are synonymous with "here", "there" and "both", respectively. The only thing that is neither here nor there, is nowhere. So I guess the only other type of version control is "Non-Existent VCS" which, unfortunately, is still quite prevalent in the industry.


10

It's unsafe because it exposes your password a number of different ways. Any user can see it in the output of programs like top and ps aux -www. They don't need to be root for to see your processes. It gets logged into your shell history, so if you do something foolish like chmod 777 ~, anybody and everybody can cat ~user/.history and view the password. ...


8

Stashes are intended for local use, as a temporary place to put things while you mess around with branches. If you're the only one working on a branch, there's no problem with committing broken code. What I do when in similar situations is do a broken commit, then after pulling it at the other location, do a git reset HEAD~1 to undo it. Of course, this ...


2

Well, because git-flow defines it this way. There is really no other explanation that is not already written up in the definition of gitflow... If you don't like that definition, you can just opt to not do it... After all, you should think about what fits best to the way you develop your code. For some, git-flow is the way to go, because they need the fine-...


2

Local VCS, Centralized VCS and Distributed VCS are various ways to set up version control infrastructure. Git specifically is a distributed version control system where every client contains an entire history of the project. Team Foundation Server and Subversion are examples of a centralized version control system, where a central server contains the ...


1

For your applications, create one repository for each. This is so that your commits only relate to changes of that specific application. This will allow you to keep better track of your versions. For your Data Structures, perhaps you could create one repository for all of them (and consider that repository a "foundational component" library).


1

I can imagine a few reasons why merging and closing might be separate. Maybe your merge is part of a larger feature and you want to perform other merges before you close them all. Maybe there's a merge conflict, and you have to resolve it. There might be a dozen possible actions you could take before you close. A reject is a whole different story; ...


1

stash is not really satisfying for anything but cleaning your work directory to “unjam your branch”; if you don't immediately stash pop the state back then things will get very confusing. If there's actual work to be saved, even if it's not good for a permanent repo entry, it should still be a commit. In fact, I never leave my working directory in a state ...


1

Here is the workflow that I follow when I branch from a feature branch: Create feature-branch-B from feature-branch-A Work on feature-branch-B If more commits are added to feature-branch-A after branching, rebase feature-branch-B onto feature-branch-A Finish work on feature-branch-B and wait till feature-branch-A is merged into master. After feature-branch-...



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