So, I have delved into BitBucket today. I have never really used SourceControl in earnest but after refactoring an app i’m working on and completely ballsing it up I thought, if only I could go back to where I was before I started refactoring.
So I’m hoping i’m using it right and hope someone can guide me a little and offer some advice.
I have created a repository and PUSHED my project to BitBucket (for safe keeping my intention). Now, I think I work on my local copy and if I mess up I can PULL (??) back from BitBucket. If I am happy with my local changes I can COMMIT to BitBucket and the changes will be updated there.
Now, why would I need to create a branch? Is this done locally or on BitBucket? By the way I am using SourceTree locally. It will only be me working on the app. Any tips/advice or explanations greatly appreciated.
Hi, Mike,
With BitBucket, are you using Git or Mercurial? I suspect you are using Git, based on your above post.
BitBucket is nothing more than a way to keep a remote copy of your Git repository. With older source code management systems such as SVN or shudder CVS, there was a central server that everyone had to check code into / out of. With the newer breed of source code management systems, the whole repository is copied over to everyone who wants to play with the code. For this reason, they are referred to as “Distributed Revision Control System”, or DRCS.
So, in general you’ll create a repository, add code changes to it, commit those changes (to create a revision) and then fork / branch / merge / etc to your heart’s content ALL ON YOUR LOCAL MACHINE. At any point during your development cycle, you can elect to synchronize all your local changes with the version of the repo that lives on BitBucket (called a push, generally) and if there are new changes on BitBucket that you want to access on your local repo, you’ll need to get those changes (usually via either a pull or a fetch and rebase).
The overall point of doing all this is to prevent exactly the issue you ran into today: “Oh crap! I’ve totally ruined something… How do I go back to before I screwed up?!!” With Git you have the full history with all revisions right on your local machine. With BitBucket, you have a second copy of the whole repo (assuming you push up changes in a timely manner) in case your laptop gets eaten by a wildebeest, stolen on the subway, or stolen on the subway by a wildebeest.
I’d recommend reading up on some Git tutorials to get a better handle on exactly what is going on, when you should branch, merge, fork, stash, etc, and how to best leverage the power of DRCS like Git.
Hope this is helpful!
Oh, I should add one other thought: I’ve not used BitBucket, but I do use GitHub. Hosted repository services like these offer some nicer ways to do certain things such as see the full history of a file, accept pull requests from other users, merge in patches, etc than the built-in command-line versions of Git or Hg do. But they are basically just lipstick on the command-line tools, and these days SourceTree and other desktop-based Git tools are VERY good at doing nearly all the same stuff.