I'm sure this is a stupid newbie question. I'm not sure why I'm finding all of this so confusing, but I am.
I managed to connect my local files to a bitbucket repo for a live website that I have using sourcetree. They are in the main branch of my repo. What I'm trying to understand now is how to setup my development files to be in a development branch of the repo, so I can work on changes without affecting the live site files. Where I'm getting confused is that I have one folder locally on my computer for the live site files, and another folder for the development files, and I can't figure out how to point the main branch to one directory and the development branch to the other directory (both already exist on my computer). So that my live site files are pushing from one folder to the main branch in bitbucket and the development files are pushing from another folder to the development branch in bitbucket. I hope I'm being clear about this.
Perhaps this is not the correct use of branches and I need separate repos for this, but then I don't know what the branches would be for. In the end, I want to merge the changes to the main branch once it's tested and ready to go live.
Any help on this would be appreciated.
I think I have figured this out.
I justed used my directory with the live site files as my base. Those are in my master branch, so I really don't need to worry about them anymore. I can use those same files locally to develop with, then push them to the develop branch in Bitbucket and they stay separated.
Thanks to everyone for trying to help!
this isn't how Git is supposed to work...fortunately! My first suggestion is to grasp the basic concepts about Git and DVCS in general. Take a look at this: http://sixrevisions.com/resources/git-tutorials-beginners/
The first link in that list (Pro Git) is one of the greatest intro to git, and I recommend following it from start to finish.
Once you have the basic concepts clear, your workflow can be simplified by using Git Flow, and this great tool is even integrated with SourceTree GUI. Take a look at this popular article explaining the workflow: http://nvie.com/posts/a-successful-git-branching-model/
The model proposed by git flow is exactly what you need: two "main" branches, develop and master, and some "on demand" branches (feature, release, hotfix).
In the future you can try more advanced workflows, like maintaining a base site where you do your main development (using git flow), and several "forks" one for each unique and deployed site, based on the main repo.
Hope this helps starting your "journey" into git!
Is there a reason you need to have a copy of the live site files accessible at all times? Some good reasons I can think of for this are:
1. The website is being hosted on this computer and needs to use those files.
2. You are making small changes to the "live" files at the same time you are making big changes to the development branch.
As long as the website isn't actually being hosted from the first folder you mentioned, the typical usage of Git would be to have just one folder that you work out of. A small, but significant, distinction is that the files you are editing are not any particular branch, they are your "working copy". Once you have a repository on your machine, you "checkout" a branch to your working copy, then make changes, then "commit" those changes to the branch.
If you are doing work on two different branches at the same time, the "right" way to do it is two just have one repository, and frequently checkout different branches.
For example, check out development, commit some progress on features, checkout the main branch (usually called master in Git), commit some minor changes and copy files to web server, checkout development, finish features, checkout master, merge development to master, commit and copy files to web server.
If it is important to keep a local copy of the main files at all times, you can have two copies of the same repository on your computer, with one specifying the other as the remote. This gives you the ability to use Git to merge branches, but will result in two copies of your repo history. I haven't been able to find a way to have two working copies for one repository.
The reason I have two separate directory locations is because I'm using a program that creates web servers locally so I can see and work with my sites on my Mac. This creates each one in a separate folder. I have one reproducing the live site and one reproducing the development site. I want to be able to see both to compare.
Perhaps I don't need to connect Sourcetree to the live site directory at all. I have the code from that directory in a Bitbucket repo. Should I just use the files from my development directory as my Working Copy and push changes from it to the development branch on the repo? Then, when they are ready, merge the development branch to the main?
I guess I was assuming that the main branch pointed to the live files and the development branch pointed to the dev files.
Yes, you should have only one repo per site.
Assuming a clean machine (for simplicity), and a repo on bitbucket with only a master branch, you can first clone your master branch locally on a directory that will become the local "test" of the live site.
Then you can create a branch named develop off the master one (you can do so directly on bitbucket), and clone the repo again with
git clone -b develop <remote_repo>
on another dir that will become the dev site.
You can also fetch the master branch in the dev clone, and do your merge work on master there before pushing online.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs