Skip to main content

Title: Demonstrating Version Control with Bitbucket

Title: Demonstrating Version Control with Bitbucket

Objective:

The objective of this experiment is to showcase the basic functionalities of version control using Bitbucket. We will create a simple project, set up a Bitbucket repository, and perform version control operations such as creating branches, making changes, committing changes, and merging branches.

Tools and Technologies:

  • Bitbucket (Cloud or Server)
  • Git (command-line or Git GUI client)
  • Web browser

Experiment Steps:

Step 1: Set Up Bitbucket Repository

  1. Create a Bitbucket account (if you don't have one) and log in.
  2. Create a new repository on Bitbucket with an appropriate name (e.g., "demo-project").
  3. Take note of the repository URL (HTTPS or SSH) provided by Bitbucket.

Step 2: Initialize the Project

  1. Create a new directory for the project on your local machine.
  2. Navigate to the project directory using the command-line.
  3. Initialize a Git repository in this directory using the command: git init.

Step 3: Configure Git Remote

  1. Set the Bitbucket repository as the remote for your local repository using the command:


git remote add origin <Bitbucket_Repository_URL>

Replace <Bitbucket_Repository_URL> with the URL obtained in Step 1.


Step 4: Create and Switch Branches

  1. Create a new branch called "feature-branch" using the command: git checkout -b feature-branch.
  2. Switch back to the main branch (usually "master" or "main") using: git checkout main.

Step 5: Make Changes and Commit

  1. Create a new file or modify an existing one in your project directory.
  2. Add the changes to the staging area using: git add <file_name>.
  3. Commit the changes with a descriptive message using: git commit -m "Your commit message".

Step 6: Push Changes to Bitbucket

  1. Push the committed changes to the Bitbucket repository using: git push origin <branch_name> (e.g., git push origin main).

Step 7: Merge Branches

  1. Switch to the main branch using: git checkout main.
  2. Merge the "feature-branch" into the main branch using: git merge feature-branch.
  3. Resolve any merge conflicts if they occur.
  4. Commit the merge changes and push them to the Bitbucket repository.

Step 8: Review History

  1. View the commit history using: git log.
  2. Use Bitbucket's web interface to visualize the commit history, branches, and pull requests.

Step 9: Optional - Collaborate with Others

  1. Invite collaborators to your Bitbucket repository.
  2. Ask collaborators to clone the repository, make changes, and push them to Bitbucket.
  3. Review and merge their changes using pull requests.

Conclusion:

This experiment demonstrates the fundamental version control operations using Bitbucket. By following these steps, you have gained an understanding of how to set up a repository, create branches, make changes, commit changes, merge branches, and collaborate with others using Bitbucket's version control capabilities. Version control is a critical aspect of modern software development, enabling teams to work together efficiently and maintain a history of changes to their projects.

Comments

Popular posts from this blog

Maven Create and Build Artifacts

In Maven, you can create and build artifacts using the package phase of the build lifecycle. The package phase is responsible for taking the compiled code and other project resources and packaging them into a distributable format, such as a JAR (Java Archive), WAR (Web Application Archive), or other custom formats. Here are the steps to create and build artifacts using Maven: Configure the Build Output: In your project's pom.xml file, you need to configure the output of the build. This includes specifying the type of artifact you want to create (e.g., JAR, WAR) and any additional resources to include. You do this in the <build> section of your pom.xml: <build>     <finalName>my-artifact</finalName> <!-- Name of the artifact without the extension -->     <plugins>         <!-- Plugin configurations for creating the artifact -->         <!-- For example, maven-jar-plugin or maven-war-plugin -->     </plugins> </build> Depend

Experiment No. 5 Title: Applying CI/CD Principles to Web Development Using Jenkins, Git, and Local HTTP Server

  Experiment No. 5 Title: Applying CI/CD Principles to Web Development Using Jenkins, Git, and Local HTTP Server  Objective: The objective of this experiment is to set up a CI/CD pipeline for a web development project using Jenkins, Git, and webhooks, without the need for a Jenkinsfile. You will learn how to automatically build and deploy a web application to a local HTTP server whenever changes are pushed to the Git repository, using Jenkins' "Execute Shell" build step. Introduction: Continuous Integration and Continuous Deployment (CI/CD) is a critical practice in modern software development, allowing teams to automate the building, testing, and deployment of applications. This process ensures that software updates are consistently and reliably delivered to end-users, leading to improved development efficiency and product quality. In this context, this introduction sets the stage for an exploration of how to apply CI/CD principles specifically to web development using J

Maven Repositories (local, central, global)

Maven relies on repositories to manage dependencies, plugins, and other artifacts required for a project. There are typically three types of repositories in Maven: local, central, and remote/global repositories. Local Repository: Location: The local repository is located on your local development machine. By default, it's in the .m2 directory within your user home directory (e.g., C:\Users\<username>\.m2\repository on Windows or /Users/<username>/.m2/repository on macOS and Linux). Purpose: The local repository is used to store artifacts (JARs, POMs, and other files) that your machine has downloaded or built during previous Maven builds. These artifacts are specific to your local development environment. Benefits: Using a local repository improves build performance since it caches dependencies locally, reducing the need to download them repeatedly. It also ensures reproducibility by maintaining a local copy of dependencies. Central Repository: Location: The central repo