2017-04-05 3:32 GMT+02:00 <bestbrightestandthens...@gmail.com>: > I have two directories. The one called bitbucket/source contains the > cloned repository which was set up by another developer and the other one > is called bitbucket/sourcecode which contains the same from my localhost so > some of the files in there have been modified due to code changes. So now > supposedly I create a branch and add those files from bitbucket/sourecode. > A ridiculous amount of work. I'm going to be spending 80% of my time on > overhead now that we have this new source control requirement. >
You are going to reduce the overhead by creating a workflow that enables you to do git "after" the fact and as a way to round up your day so to speak. There is no requirement to do git all the time as you are coding unless you want to constantly push changes to the shared repo. - I know it is attractive to commit often and then push straight away - you don't have to immediately push what you commit - you can wait out until you have done a lot of work and commit only then. I described the git stash and git checkout -p stash workflow in the other email. For example, if you have already made changes to your local "master" clone (master branch of your clone) you can now do the following: git stash -u git checkout -b my/branch1 git stash pop and (if I am correct about this) the changes will now be placed on top of your current new branch and they will have been removed from master, unless you already made some commits there. you can probably just reset the index of master (the timeline of master) using some git reset command after the fact also to remove these commits also from master (I'm not a git guru in this sense) remember that branches are just "trails" of commits leading up to a certain final commit. Some of these trails may split off at certain points and then you get branches. No branch is more authorative than another branch. They are all branches (trails). A branch is nothing but a reference to the latest commit part of that branch, in that sense. In any case: - git stash something to undo changes to the working directory and save it in a stash - always execute git commands in your working directory / tree, not outside of it - you can pop the stash at a later point to replay it on top of the current working directory (ie. another branch for example) - you can undo commits with git reset, they will still exist, but your branch goes back in time. - for that to work you need to specify the commit to reset to (git reset a3f21 or whatever) - resetting one branch will have no influence on the commits in another branch The workflow I described in the other mail was: - make a lot of coding changes - git stash -u - git checkout -p stash - say yes to every chunk you want, and no to every chunk you don't want (interactively) - commit these changes, write a nice commit message - git checkout -p stash again - say yes to every chunk you want, and no to every chunk you don't want (interactively). - rinse and repeat - if you have changes left in the stash you want to dump, you can do "git stash drop" and those changes will simply be gone now - if you have changes left in the stash you want to keep and reapply to your working directory, do "git stash pop" and they will be there again and your stash removed. The stash is for me really the secret to Git. That's all I can say really. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
